AWS Budgetsで個人開発の課金事故を防ぐ

AWS個人開発で最初に設定すべきサービスの1つがAWS Budgetsです。機能実装より先に、課金事故を検知できる状態を作ります。

結論

AWS Budgetsは、AWS利用料が設定した金額や割合に近づいたときに通知するサービスです。個人開発では低めの月額予算を設定し、実績50%、実績80%、実績100%、予測100%で通知する運用が安全です。

なぜ最初に設定するのか

AWSは従量課金です。小さな検証でも、作ったサービスを放置すると料金が増えることがあります。

特に NAT Gateway、RDS、ALB、EC2、OpenSearch などは、リソースが存在する時間そのものに課金される型です。アクセスがゼロでも請求が積み上がるため、個人MVPでは想定外コストにつながりやすいサービスです。Budgetsを設定していれば、異常に気づくきっかけになります。

予算の種類

AWS Budgets では、目的に応じて複数の種類の予算を作れます。個人開発でまず使うのはコスト予算ですが、種類を知っておくと使い分けができます。

設定手順

コンソールから作る場合の流れは次の通りです。Billing and Cost Management のコンソールから操作します。

1. AWS マネジメントコンソールで「Billing and Cost Management」を開く
2. 左メニューの「Budgets」から「Create budget」を選ぶ
3. 予算タイプで「Cost budget」を選ぶ
4. 期間を Monthly、予算額を固定額（Fixed）で入力する
5. アラートのしきい値を追加する。1つの予算に複数のしきい値を設定できる
6. 通知先メールアドレス、または SNS トピックの ARN を指定する
7. 内容を確認して作成する

作成後は、テストのために意図的に超過させるのではなく、通知先メールが実際に受信できるアドレスかどうかを先に確認しておきます。届かない通知は設定していないのと同じです。

しきい値の設計

しきい値は「実績（Actual）」と「予測（Forecasted）」の2種類を組み合わせます。

予測アラートは、月初に高額なリソースを作ってしまったケースで特に有効です。実績が予算に届く前に通知されるため、対応の猶予が生まれます。

通知が遅れることを前提にする

Budgets は請求データを基に評価するため、リアルタイムではありません。AWS のドキュメントでは、Budgets の情報は1日に最大3回更新され、更新の間隔はおおむね 8〜12 時間とされています。

つまり「リソースを作った瞬間に通知が飛ぶ」仕組みではありません。高額なリソースを作った直後の数時間は、通知に頼らず自分で確認する必要があります。Budgets は最後の砦であって、最初の防波堤ではありません。

SNS 経由で通知する

通知先はメールアドレスだけでなく、Amazon SNS トピックも指定できます。SNS を挟むと、メール以外の経路（HTTPS エンドポイント経由でのチャット通知など）にも配信できます。

SNS を使う場合、Budgets がそのトピックに発行できるようにトピックのアクセスポリシーを設定する必要があります。ポリシーを設定していないと通知が届かないため、作成後に必ずテスト発行で確認します。

無料枠アラートとの違い

Billing の設定には、無料利用枠の使用量が一定割合を超えたときに知らせる「無料利用枠の使用アラート」もあります。Budgets とは目的が異なります。

無料枠アラートは「枠を使い切りそう」を教えてくれますが、枠の対象外サービスで発生した金額は捉えません。両方を設定しておくと死角が減ります。

なお、AWS Budgets 自体にも料金体系があり、一定数までの予算は無償で作成できますが、それを超える数の予算には少額の課金が発生します。個人開発で数個作る範囲であれば問題になりにくいものの、正確な条件はAWS公式の料金ページで確認してください。

Cost Explorer との違い

Budgets は「予算を超えそうか」を通知するサービスです。Cost Explorer は「どのサービスにいくら使ったか」を分析するサービスです。

課金通知が来たら、Cost Explorer でサービス別、リージョン別、使用タイプ別に費用を確認します。特に「使用タイプ（Usage Type）」でグループ化すると、APN1-NatGateway-Hours のような粒度まで分解でき、どのメーターが回っているかが特定できます。

このプロジェクトでの使い方

このサイトでは、S3、CloudFront、API Gateway、Lambda、DynamoDB、CloudWatch Logs を使います。アクセスが少ない段階では低コストを狙いますが、完全な永続ゼロ円は保証しません。

そのため、Budgets を必須にして、想定外の料金を早期に検知する設計にします。

実務での注意点

Budgets は課金を止める魔法ではありません。通知を受け取ったら、すぐに Billing Dashboard、Cost Explorer、作成済みリソースを確認します。

止める仕組みが必要な場合は、Budget Actions を使って、しきい値を超えたときに IAM ポリシーや SCP を適用し、追加のリソース作成を拒否する構成が取れます。ただし、これは適用範囲を誤ると自分の作業も止まるため、個人開発でいきなり有効にするより、まず通知だけで運用を回すほうが安全です。

不要な検証リソースは削除し、CloudWatch Logs のロググループは保持期間を設定して無期限にしないほうが安全です。ログは静かに増え続けるため、通知が鳴ってから気づくと保存量が膨らんでいることがあります。

関連用語

• AWS Budgets
• Cost Explorer
• Amazon CloudWatch

次に読む記事

• AWS料金の基本をCloud Practitioner向けに整理する
• AWSポートフォリオでサーバーレス構成を選ぶ理由