AWSで"請求が怖い"を卒業する — Budgets・請求アラート・無料枠の落とし穴
AWS コスト管理 基本の第一歩を、請求アラート・AWS Budgets 設定・AWS 無料枠の落とし穴回避の3手で整理します。請求の安全網の張り方と、通知が検知であって予防ではないという限界まで、現行の公式仕様にそって解説します。
- #AWS
- #コスト管理
- #Budgets
- #無料枠
- #請求アラート
AWSは使った分だけ課金される従量制です。便利な反面、請求は事後にしか確定せず「今いくら使っているのか」が読みにくいため、漠然とした不安につながりがちです。本記事では、その不安を3つの具体的なアクション——請求アラート、AWS Budgets、無料枠の落とし穴回避——に置き換え、最初の「請求の安全網」を張る手順を整理します。あわせて、これらの設定が「課金を検知する」仕組みであって「課金そのものを止める」ものではない、という限界も正直にお伝えします。なお料金や無料枠の具体的な金額・条件は変動するため、本文では金額を示しません。最新の値は公式のページでご確認いただく前提で読み進めてください。
なぜ”請求が怖い”が起きるのか
請求への不安には、はっきりした理由があります。従量課金は使ったあとに金額が分かるため、リソースを消し忘れたり想定より多く動かしたりしても、その場では気づけません。さらに「無料枠があるから大丈夫」という思い込みも、無料枠の対象や上限を外れた瞬間に裏切られます。つまり、AWSのコストは事前に上限を意識し、超えそうになったら早く気づく仕組みを自分で用意しないと読めないのです。
この仕組みが「請求の安全網」です。やることは多くありません。無料枠の中身を正しく理解したうえで、Budgetsで予算を決め、請求アラートで超過を通知させる。この3手がそろえば、最初の安全網になります。
まず請求アラートを張る
最初に張るのは、請求額が一定の金額を超えたらメールで知らせてくれる請求アラートです。CloudWatch（AWSの監視サービス）の請求メトリクスを使いますが、手順の順番に2つの落とし穴があります。
- 請求アラートの受信を有効化する：Billing and Cost Managementコンソールの Billing Preferences で「請求アラートの受信」を有効にします。一度有効にするとオフには戻せません（アラーム自体の削除は可能です）。有効化から反映まで少し時間がかかります。
- リージョンをus-east-1（バージニア北部）に切り替える：請求メトリクスは全世界の課金をまとめてバージニア北部だけに保存されます。東京リージョンのまま探しても請求メトリクスは見つかりません。ここが最初のつまずきどころです。
- アラームを作る：CloudWatch のメトリクスから Billing の
EstimatedCharges（推定請求額）を選び、統計は最大値、期間を区切って、閾値を設定します。金額は自分の利用規模に合わせて決めます。通知先には SNS（通知サービス）のトピックを指定し、受信用のメールアドレスを登録します。
注意点として、AWS Partner Network（APN）に紐づくアカウントでは請求メトリクスが発行されません。また組織（一括請求）構成では、支払い側のアカウントで有効化しないとメンバーアカウントのメトリクスが取れません。EstimatedCharges はUSD建てでのみ扱われる点も押さえておきます。
そしてここが大切な前提です。このアラームは**「現在の請求額が閾値を超えたとき」だけ発火し、将来の使用量を予測はしません**。作成した時点ですでに閾値を超えていれば、即座にアラーム状態になります。言い換えれば、通知が鳴った時点で、その課金は既に発生しています。
AWS Budgetsで予算を決める
請求アラートが「超えたら知らせる」のに対し、AWS Budgets は「いくらまでと先に決める」道具です。コストや使用量に予算を設定し、閾値（たとえば予算の半分や8割）に達したらメールで通知できます。予算を作って閾値で通知させるところまでは無料で、誰でも安全網として張れます。
予算超過時に自動でアクション（対象の停止など）を実行する機能もありますが、こちらは無料で使える数に上限があり、それを超えると課金条件が分かれます。まずは「予算＋通知」から始め、自動アクションは必要になってから検討するのが無理のない順番です。具体的な料金は公式の料金ページでご確認ください。
請求アラート・Budgets・Cost Explorer は役割が混同されがちなので、整理しておきます。
| 機能 | 役割 | タイミング | 通知 |
|---|---|---|---|
| 請求アラート（CloudWatch） | 請求額が閾値を超えたら検知 | ほぼ随時（1日に複数回更新） | SNSでメール |
| AWS Budgets | 予算を先に決めて閾値で知らせる | 日次など | メール／自動アクション |
| Cost Explorer | 請求の内訳を後から可視化する | 反映に時間差あり | 通知ではなく可視化 |
Cost Explorer はコンソールで初めて開いて起動します（APIからは有効化できません）。当月分が見えるようになるまでに時間がかかり、更新も随時ではないため、即時の事故防止ではなく「あとから内訳を見る」道具と捉えます。有効化すると異常検知（Cost Anomaly Detection）も自動で構成され、想定を一定割合超える支出を知らせてくれます（しきい値などの条件は公式でご確認ください）。
無料枠の落とし穴 — 2025年7月15日に別物へ変わった
「無料枠があるから安心」がもっとも事故りやすい部分です。そして見落とされがちなのが、無料枠（Free Tier）は2025年7月15日を境に、新旧でまったく別の制度になったという事実です。自分のアカウントをいつ作ったかで中身が変わります。
アカウントの作成時期で「無料枠」は別物
2025年7月15日以降に作成した新しいアカウントでは、サインアップ時に Free plan か Paid plan を選びます。新規利用者にはクレジットが付与され、常時無料（always free）の多数のサービスはどちらのプランでも使えます。
- Free plan：付与されたクレジットの範囲で課金がゼロになります。ただしクレジットを使い切るか所定の期間が過ぎるとアカウントが自動的にクローズされ、一定の保持期間の後にデータが削除される設計です。期間内に Paid plan へ切り替えれば維持できます。Savings PlansやReserved Instancesなど一部のサービスはクレジットの対象外で、課金され得ます。また、組織への参加など特定の条件を満たすと自動的に Paid plan へ移行します。
- Paid plan：すべてのサービスをすぐに使えます。クレジットの対象外や超過分は標準の従量課金になります。
2025年7月15日より前に作成した既存アカウントは、従来どおりの仕組み——12か月の無料利用枠／常時無料／短期トライアル——が継続します。
このように「無料枠」と一括りにできないため、自分のアカウントがどちらに当たるかをまず確認してください。クレジットの金額・有効期間・対象サービス・自動クローズの条件などは変わり得る時点の仕様です。最新の内容は必ず公式の Free Tier ページでご確認ください。とくに**新しい Free plan は「無料のつもりが、放置するとアカウントごと消える」**という、従来とは別種の落とし穴がある点に注意が要ります。
設定しても防ぎきれないこと
ここが本記事の山場です。安全網を張っても、課金そのものを止められるわけではありません。「これで絶対に課金されない」とは言えない理由を、正直に押さえます。
通知は検知であって予防ではありません。 請求アラートもBudgetsも、閾値の超過を事後に知らせる仕組みです。請求メトリクスの更新は1日に数回、Cost Explorerの反映には時間差があります。つまりアラートが鳴った時点で、その課金は既に発生しています。通知は「事故を早く知る」ためのもので、「事故を起こさない」ためのものではありません。
無料枠の中なら絶対に無料、でもありません。 無料枠はサービスごとに対象・上限・期間が決まっており、それを外れた分は課金されます。新しい Free plan でも、クレジットの対象外サービスや超過分は課金され得ます。そして前述のとおり、Free plan は放置するとアカウントが自動クローズされ、データが失われる可能性があります。「安いつもり」が手痛い結果になる典型です。
だからこそ、3手は**「課金事故を早く知り、上限を意識する」ための安全網**と位置づけるのが正確です。完全に止めたいリソースは、使い終わったら確実に削除する、という基本動作と組み合わせて初めて効きます。仕様値（手順・リージョン制約・無料枠の区分など）は現行（2026年6月時点）のもので、金額を含む詳細は公式で最新をご確認ください。
まとめ — 3手＋限界の理解
AWSの「請求が怖い」は、次の3手と1つの理解で卒業できます。
- 請求アラートを張る：us-east-1で
EstimatedChargesを監視し、超過をメールで受け取る。 - Budgetsで予算を決める：予算＋閾値通知までは無料で誰でも張れる。
- 無料枠を正しく理解する：2025年7月15日以降の新制度（クレジット制・自動クローズ）か、それ以前の従来枠かを確認する。
そのうえで、通知は検知であって予防ではないという限界を忘れないことです。
最初の安全網を張れたら、次は「請求の中身を見て、絞る」段階です。請求の内訳を深く分析するなら Cost Explorer × Amazon Q、無駄を継続的に絞るなら AWS FinOps Agent が次の一手になります。さらに、そもそもデータを安く置く具体策（S3のストレージクラスとライフサイクル設計）は別記事で扱います。まずは本記事の3手で、最初の安全網を張るところから始めてみてください。