「クラウド破産」をIaCで防ぐ：AWS Budgetsによる料金アラート自動化とマルチアカウント運用のベストプラクティス

みなさん、こんにちは。

AWS（Amazon Web Services）を活用した開発や運用は非常に便利ですが、エンジニアやマネージャーが常に恐怖を抱くポイントがあります。それが「予期せぬ費用の高騰（通称：クラウド破産）」です。

「テスト用の巨大なインスタンスを消し忘れた」「検証用に動かしたAI・データ分析スクリプトがループして、一晩で数十万円の請求が来た」といった悲劇は、今も昔も絶えません。こうしたリスクを未然に防ぐための強力な武器が「AWS Budgets（予算管理機能）」です。

今回は、お渡しいただいた実務資料をベースに、AWS Budgetsをコンソールから手動で設定するだけでなく、「Terraform（コード）による自動化」や「マルチアカウント環境（AWS Organizations）での一元管理」という一歩進んだベストプラクティスを解説します。

1. なぜ「料金アラート」を手動ではなくコード（IaC）で管理すべきなのか？

初めてAWSを触る際、多くのチュートリアルでは「マネジメントコンソール（Web画面）を開いて、AWS Budgetsのメニューから予算を入力し、通知先メールアドレスを設定しましょう」と案内されます。

確かに個人開発や単一のアカウントであればそれで十分かもしれません。しかし、エンタープライズ（企業運用）や複数のプロジェクトを並行して動かす現場では、手動設定には大きなリスクが伴います。

設定漏れのリスク：新しくAWSアカウントを払い出すたびに手動でアラートを作っていると、いつか必ず設定を忘れるアカウントが出てきます。
通知変更のブラックボックス化：異動や退職で「誰のメールアドレスに通知が飛ぶのか」の変更が管理されなくなり、アラートが機能しなくなります。

これらを解決するのが、インフラをコードで定義する「IaC（Infrastructure as Code）」です。アカウント作成と同時に自動的に一律の料金アラートがデプロイされる仕組みを作ることで、人間の不注意によるクラウド破産を根絶することができます。

2. TerraformによるAWS Budgetsのコード定義例

具体的に、Terraformを使って「月額予算の80%（予測）または100%（実績）に達した際にSlackやメールに通知する」ためのコードの基本構造を見てみましょう。

resource "aws_budgets_budget" "monthly_cost_budget" {
  name              = "monthly-total-cost-budget"
  budget_type       = "COST"
  limit_amount      = "100" # 予算を100USDに設定
  limit_unit        = "USD"
  time_period_start = "2026-05-01_00:00"
  time_unit         = "MONTHLY"

  # 1つ目のアラート：予測コストが予算の80%を超えそうな場合
  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED" # 予測（重要！）
    subscriber_email_addresses = ["admin-alerts@example.com"]
  }

  # 2つ目のアラート：実際の請求額が予算の100%に達した場合
  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL" # 実績
    subscriber_email_addresses = ["admin-alerts@example.com"]
  }
}

【解説と補足】通知タイプ「FORECASTED（予測）」の重要性

AWS Budgetsを設定する上で最も重要な補足ポイントは、「実績（ACTUAL）」だけでなく必ず「予測（FORECASTED）」のアラートを仕込んでおくことです。
実績が100%を超えた段階で通知を受け取っても、その時点で既に予算をオーバーしています。一方、AWSの過去の利用動向から計算された「月末の着地予測」ベースのアラート（80%等）を設定しておけば、「このままのペースで使うと数日後に予算が尽きます」という段階で先手を打ってリソースを停止させることができます。

3. マルチアカウント（Organizations）環境での一元管理戦略

企業で複数のAWSアカウント（開発環境、ステージング環境、本番環境など）を運用している場合、アカウントごとに上記のコードをデプロイするのは非効率です。

ソース元の組織設計思想（GCPのFolder/Project構造とも対比される概念）をAWSに適用する場合、「AWS Organizations（またはControl Tower）」を用いた一元管理がベストプラクティスとなります。

管理（Management）アカウントでの集約管理
個々の子アカウントに予算アラートを個別に仕込むのではなく、親である「管理アカウント」側でAWS Budgetsを一元定義します。
コストカテゴリとタグの強制
各リソースに Project=AI-Agent-System や Owner=Taro といった「コスト配分タグ（Cost Allocation Tags）」の付与を組織ポリシー（SCP）で義務付けます。
フィルタリング機能の活用
AWS Budgetsのコード内で cost_filters を指定し、「特定のアカウントID」や「特定のタグ」ごとに自動で予算枠を切り出すように設計します。これにより、インフラ担当者が一元的にすべてのプロジェクトの請求リスクを監視できるようになります。

4. さらに踏み込んだ自動化：アラート検知時の「自動リソース停止」

「メールでアラートを受け取っても、週末で誰も気づかなければ意味がないのでは？」

その懸念は極めてもっともです。現在のFinOps（クラウド財務管理）のトレンドでは、通知だけにとどまらず、「予算上限に達したら自動で開発環境をシャットダウンする」という自動アクションの実装が進んでいます。

AWS Budgetsには、アラート発火時に「AWS Budgets Actions」という機能を通じて、IAMポリシーの適用やEC2/RDSインスタンスの自動停止、あるいはLambda関数をキックする仕組みが統合されています。
例えば、「開発用アカウントで予算の150%を突破した場合、開発メンバーのEC2起動権限を一時的に剥奪するポリシーを自動でアタッチする」といったガードレールを敷くことで、組織全体の財務安全性をより強固にすることが可能です。

まとめ：クラウドの利便性を「安心」に変えるインフラ設計

クラウドは「使った分だけ支払う」という従量課金システムだからこそ、イノベーションを加速させることができます。しかし、裏を返せば「対策を怠ると無限に請求が膨らむ」というリスクと隣り合わせです。

今回ご紹介したAWS Budgetsの仕組みは、以下のようなステップで導入・スケールさせていくのがおすすめです。

ステップ1：まずは手動または単一のTerraformコードで、メールでの「予測アラート」を設定する。
ステップ2：Slackなどのチャットツールへの通知を統合し、開発チーム全体でコスト意識（FinOps）を共有する。
ステップ3：マルチアカウント環境へ横断展開し、予算超過時の自動リソース停止（アクション）を組み込む。

インフラを構築する際は、「動くものを作る」ことと同じくらい「お財布を守るガードレールを最初に敷く」ことが重要です。ぜひ、この機会にご自身のAWS環境の設定を見直してみてはいかがでしょうか。