「AWSを試しに使ってみたら、翌月に想定外の請求が来た」という話を見聞きして、不安になっている方は多いのではないでしょうか。無料枠のつもりで触っていたサービスが実は課金対象だったり、検証用に立てたインスタンスを消し忘れたりするだけで、数万円単位の請求が発生することがあります。実際、SNSや掲示板には「一晩放置しただけで数万円」「退職金の一部が飛んだ」といった投稿も見られ、他人事ではないと感じる人も少なくありません。本記事では、こうした「課金事故」を未然に防ぐためのAWS請求アラート設定を、具体的な手順と数値を交えて解説します。読み終える頃には、自分のアカウントに安全装置を仕込める状態になっているはずです。
AWSで課金事故が起こる典型パターン
AWSの課金事故は、派手な不正利用だけが原因ではありません。むしろ個人利用者に多いのは、検証後の「後片付け忘れ」です。例えば、EC2インスタンスを起動したまま放置すると、t3.microクラスでも1ヶ月で1,000〜2,000円程度の費用が発生します。さらにEBS(ストレージ)やElastic IP、NATゲートウェイは「起動していなくても」課金され続けることがあり、NATゲートウェイは1時間あたり約0.062ドル(月額換算で6,000円前後)というケースも珍しくありません。同様に、ALB(Application Load Balancer)も時間課金のため使っていない検証環境に置きっぱなしにすると静かにコストが積み上がります。また、S3へのリクエスト課金やデータ転送量(特にリージョン間・インターネットへの送信)は見落とされやすく、CloudFrontと組み合わせた構成では想定以上にアクセスが集中した際に転送量課金が跳ね上がることもあります。さらに無料枠は「12ヶ月間、一定量まで無料」というサービスと「常時無料だが上限あり」のサービスが混在しており、この違いを理解していないと想定外の課金につながります。まずは自分がどのサービスをどの無料枠条件で使っているかを、AWSの「無料利用枠」ページやCost Explorerで把握することが、事故防止の第一歩です。
AWS Budgetsで予算アラートを設定する
最も確実な防止策は「AWS Budgets」を使った予算アラートの設定です。AWSマネジメントコンソールにログインし、「Billing and Cost Management」から「Budgets」を選択、「Budgetを作成」をクリックします。予算タイプは「コスト予算」を選び、月間の上限額(例えば個人検証用途なら1,000円や3,000円など)を入力します。次に通知のしきい値を設定します。推奨は「予算の50%」「80%」「100%」の3段階でメール通知を受け取る設定です。これにより、使いすぎに気づく前に複数回の警告を受けられます。さらに重要なのが「予測コストに基づく通知」です。これは現在の使用傾向から月末時点の予測コストを算出し、予算を超えそうな段階で早期に知らせてくれる機能で、実際の課金が発生する前に対処できる点が大きなメリットです。設定自体は5分程度で完了し、無料で利用できます。なお、コスト予算以外にも「使用量予算」を設定すれば、特定サービスの利用時間や容量そのものに対してアラートを出すことも可能です。例えば「EC2の稼働時間が月720時間を超えたら通知」といった運用をしておくと、インスタンスの放置にいち早く気づけます。用途別に複数の予算を作成し、プロジェクトやサービスごとにタグで分けて管理するのも実務ではよく使われる手法です。
CloudWatchアラームと請求通知の併用
AWS Budgetsだけでなく、「CloudWatch」のビリングアラーム機能を併用すると、より多層的な防御になります。まずIAMの「Billingの表示を有効化」(ルートユーザーのアカウント設定内)をオンにしておく必要があります。その上で、米国東部(バージニア北部)リージョンでCloudWatchの「請求」メトリクスから「EstimatedCharges」を選び、しきい値(例:5,000円)を超えたらSNS経由でメール通知するアラームを作成します。具体的には、SNSトピックを作成してメールアドレスをサブスクライブし、そのトピックをアラームのアクション先に指定するだけなので、設定にかかる時間は10分程度です。AWS Budgetsとの違いは、CloudWatchアラームはより即時性の高い監視が可能で、Lambda関数と連携させて「予算超過時に自動でインスタンスを停止する」といった自動対応の仕組みも構築できる点です。例えば、アラームの発火をトリガーにLambdaを起動し、稼働中のEC2インスタンスを一覧取得してすべて停止するスクリプトを実行する、といった構成は個人開発者の間でもよく紹介されています。初心者はまずBudgetsの通知設定だけで十分ですが、本格的に検証を続ける場合はCloudWatchによる自動停止の仕組みまで用意しておくと、寝ている間の課金事故も防げます。
AWS Cost Anomaly Detectionで異常な支出を検知する
予算アラートと合わせて検討したいのが「AWS Cost Anomaly Detection」です。これは過去の利用パターンを機械学習で分析し、通常とは異なる支出の増加を自動的に検知してくれる無料のサービスです。固定の予算額を設定するBudgetsとは異なり、「普段は月500円程度のサービスが、ある日突然急増した」といった相対的な異常を捉えられるため、まだ利用額が小さいうちは気づきにくいリスクを早期に発見できます。設定は「Cost Management」内の「Cost Anomaly Detection」からモニターを作成し、サービス単位・アカウント単位・コストカテゴリ単位など監視対象を選ぶだけです。検知の感度(アラートしきい値)はドル単位で指定でき、小額の異常でも通知を受け取りたい場合は低めに設定しておくとよいでしょう。BudgetsとCloudWatchアラームが「決めた上限を超えたか」を見るのに対し、Cost Anomaly Detectionは「いつもと違う動きがあるか」を見る仕組みなので、両方を併用することで検知の抜け漏れを減らせます。
実践例:個人開発者Aさんのケース
副業でWebアプリを開発しているAさんは、学習のためにEC2とRDSを使った検証環境を構築していました。無料枠の範囲内だと思い込んでいましたが、実際にはRDSのインスタンスタイプが無料枠対象外のもので、1ヶ月放置した結果、約8,500円の請求が発生してしまいました。この経験を踏まえ、Aさんは翌月からAWS Budgetsで月間上限2,000円・通知しきい値50%/80%/100%の予算アラートを設定しました。さらに検証が終わったリソースは必ず「削除」ではなく、まず「停止」してから1週間様子を見て不要と判断したら削除する運用に変更。加えて、重要なリソースには「project:検証用」といったタグを付け、Cost Explorerでタグ別のコストを毎週確認する習慣も取り入れました。結果として、その後半年間は想定外の課金が1円も発生しなくなったといいます。このケースからわかるように、アラート設定と運用ルールの両方を整えることが、課金事故防止の鍵になります。
よくある質問
Q1. 請求アラートを設定しても、自動でサービスは停止されませんか?
A1. AWS Budgetsの標準機能は「通知」のみで、自動停止は行われません。自動停止を実現するには、CloudWatchアラームとLambda関数、SNSを組み合わせた仕組みを別途構築する必要があります。まずは通知を受け取り、手動で対処する運用から始めるのがおすすめです。
Q2. 無料枠を使っているだけなら請求アラートは不要ですか?
A2. 不要ではありません。無料枠には利用量や期間の上限があり、知らないうちに超過すると課金が発生します。無料枠内での利用を想定している場合でも、低めの金額(例:500円)で予算アラートを設定しておくと、超過の兆候にすぐ気づけます。
Q3. 複数のAWSアカウントを使っている場合、アラートはどう設定すればよいですか?
A3. AWS Organizationsで複数アカウントを管理している場合は、管理アカウント側で統合請求を確認した上で、アカウントごとに個別のBudgetsを設定するのが基本です。アカウント単位だけでなく、リンクされたアカウント全体を対象にした予算も作成できるため、個人の検証用アカウントと本番用アカウントを分けている場合は、それぞれに適した上限額としきい値を設定しましょう。
まとめ
AWSの課金事故は、不正利用よりも「使い忘れ」や「無料枠の誤解」から起こることがほとんどです。AWS Budgetsでの予算アラート設定、CloudWatchによる監視の併用、Cost Anomaly Detectionによる異常検知、そして検証後のリソース整理というシンプルな対策を組み合わせるだけで、事故のリスクは大幅に下げられます。どれも無料で使える仕組みなので、コストをかけずに安全性を高められる点も安心材料です。まだ請求アラートを設定していない方は、この記事を読み終えたその場で、まずは月間上限を決めてAWS Budgetsを設定してみましょう。数分の作業が、将来の予期せぬ出費を防ぐ安心材料になります。
