AWS Budget Actionsで予算超過を自動制御する実践ガイド｜EC2停止・IAMポリシー制限・承認フローの設計と注意点

クラウドを使い始めると、必ず一度は直面するのが「月末の請求額が予算を大幅に超えていた」という経験です。EC2を止め忘れた、開発環境のRDSを本番サイズで動かしていた、テスト目的のS3バケットにデータが溜まり続けた――オンプレの感覚でいると、クラウドの従量課金は想定外の額になります。

AWS Budgetsで通知を設定している現場は多いですが、「通知が来ても誰も見ていなかった」「週末に閾値を超えて月曜に気づいた」というケースが後を絶ちません。

この記事では、AWS Budget Actionsを使って予算超過を検知したときに自動でEC2を停止したりIAMポリシーを制限したりする仕組みを、設定手順・承認フロー・注意点まで含めて解説します。

Budget Actionsとは何か――「通知で終わり」から「自動制御」へ

AWS Budget Actionsは、AWS Budgetsの予算閾値に到達したときに自動でAWS上のリソースや権限に対してアクションを実行できる機能です。2020年10月にGAとなり、現在では多くの本番環境で採用されています。

オンプレミスでは「ITコスト超過＝翌月の予算会議」で対処するのが普通でした。サーバーは買い切りで、電気代が多少かさんでも即座に止める仕組みはありません。クラウドでは逆に、リソースを動かしている限り秒単位で費用が発生するため、「気づいてから手動で止める」では数万円から数十万円の損失が発生することがあります。

Budget Actionsを使うと：
・予算の80%到達時点でIAMポリシーをアタッチし、新規リソース作成を制限する
・予算の100%到達時点でEC2/RDSを自動停止する
・承認フローを挟んで安全に制御する（自動実行と手動承認の二択）

といった対応が可能です。

Budget Actionsの3種類のアクションタイプ

Budget Actionsで実行できるアクションは現時点（2026年8月時点）で3種類です。

それぞれの使いどころを整理します。

1. IAM Policy アクション

最も柔軟性が高いアクションです。「予算超過したら開発者がEC2を新規作成できないようにする」「S3バケットへのPutObjectを禁止する」といった権限制限をIAMポリシーの形で定義しておき、閾値到達時にアタッチします。

制限ポリシーの例：

# EC2インスタンス新規起動を禁止するDenyポリシー例（IAM Policy JSON）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:StartInstances"
      ],
      "Resource": "*"
    }
  ]
}

ポイントは「Deny」ポリシーをアタッチする設計にすることです。AlloW権限を剥がすのではなく、Denyポリシーを追加することでIAMの明示的Denyが優先され、確実に制限がかかります。

アクション解除時にはこのDenyポリシーをデタッチするだけでよく、元の権限設定を変更しないため復元も安全です。

2. SCP アクション

AWS Organizationsを利用しているマルチアカウント構成向けのアクションです。AWS Organizationsで管理アカウントから特定のOUやメンバーアカウント全体にSCPを適用できます。

たとえば「開発アカウント全体の月次予算が80%に達したら、高コストインスタンスタイプの起動を禁止するSCPを適用する」という制御が可能です。SCPはルートや管理アカウントには効かないため、本番アカウントへの誤適用に注意が必要です。

マルチアカウント環境を持つ組織で特に効果を発揮しますが、単一アカウント構成ではIAM Policyアクションの方が適しています。

3. EC2/RDS Instances アクション

指定したEC2またはRDSインスタンスを停止します。最もシンプルかつインパクトが大きいアクションです。

注意点として、停止できるのは「特定インスタンスの指定」です。「すべてのEC2を止める」のような動的なターゲット指定はできません。事前に「このインスタンスを止める」と決めておく必要があります。

開発環境や検証環境のインスタンスを事前にリスト化しておき、それらをターゲットに設定しておくのが実務上の使い方です。本番インスタンスは誤って止めると業務影響が出るため、アクション対象から除外する設計が原則です。

実行モード：自動実行 vs 承認フロー

Budget Actionsには2つの実行モードがあります。

手動承認モードでは、SNS通知を受け取った担当者がAWSコンソールの「Budget Actions」画面で「Approve」ボタンを押すか、AWS CLIで `aws budgets execute-budget-action` を実行することでアクションが発動します。

実務では「開発環境は自動実行、ステージング以上は手動承認」という設計が多く見られます。自動実行で開発者のインスタンスが突然停止すると業務が止まる可能性があるため、事前に全員への周知と通知設定が必須です。

設定手順（AWSコンソール操作）

1. 前提となるIAMロールの作成

Budget ActionsがIAMポリシーのアタッチやEC2の停止を行うには、専用のIAMロールが必要です。このロールはBudget Actionsが引き受ける（AssumeRole）形で動作します。

AWSコンソールの「IAM」→「ロール」→「ロールを作成」で以下を設定します。

・信頼されたエンティティ: サービス `budgets.amazonaws.com`
・許可ポリシー: `AWSBudgetsActionsRolePolicyForResourceAdministrationWithSSM`（AWS管理ポリシー）または必要な権限を最小権限で手動定義

AWS管理ポリシーを使う場合、EC2停止・RDS停止・IAMポリシーのアタッチ/デタッチ・SSM操作が含まれます。不要な権限は除いたカスタムポリシーを推奨します。

2. Budgets画面でアクションを追加

AWSコンソールの「Billing and Cost Management」→「Budgets」から既存の予算を選択するか、新規予算を作成します。

予算の詳細画面で「アクションを追加」をクリックし、以下を設定します。

・アクションタイプ: IAM Policy / SCP / EC2 or RDS Instances から選択
・トリガー閾値: 予算額のX%、または実際のコスト・予測コストが閾値に達したとき
・実行モード: 自動実行 / 手動承認
・SNS通知: アクション発動時と解除時の通知先を指定
・IAMロール: 前のステップで作成したロールを指定

# AWS CLIでBudget Actionを作成する例（IAMポリシーアタッチ）
aws budgets create-budget-action \
  --account-id 123456789012 \
  --budget-name "dev-monthly-budget" \
  --notification-type ACTUAL \
  --action-type APPLY_IAM_POLICY \
  --action-threshold ActionThresholdValue=80,ActionThresholdType=PERCENTAGE \
  --definition '{"IamActionDefinition":{"PolicyArn":"arn:aws:iam::123456789012:policy/DenyEC2RunInstances","Groups":["dev-engineers"]}}' \
  --execution-role-arn arn:aws:iam::123456789012:role/BudgetActionsRole \
  --approval-model MANUAL \
  --subscribers '[{"SubscriptionType":"SNS","Address":"arn:aws:sns:ap-northeast-1:123456789012:budget-alert"}]'

3. アクションの確認とリバート設計

アクションが実行された後、月が変わる・予算が追加されるなどで制限を解除したい場合はリバート（元に戻す）が必要です。

IAM Policyアクションの場合、AWSコンソールの「Budget Actions」画面で該当アクションを選択し「Revert」を実行するとDenyポリシーがデタッチされます。EC2停止アクションのリバートはインスタンスを起動し直しますが、IAMロールには起動権限も含まれている必要があります。

リバートを忘れると翌月も制限が継続します。リバートの実行タイミングと担当者を事前にルール化しておくことが重要です。

実践シナリオ：開発アカウントの月次コスト超過防止

典型的な構成例を示します。

シナリオ: 開発チーム用AWSアカウントの月次予算を50,000円に設定し、超過を自動制御する。

90%段階で手動承認モードにしているのは、月末にまとめて実行したい作業が残っている場合に担当者が判断できるようにするためです。110%まで達した場合は深刻なオーバーランなので自動実行で損失を止めます。

AWS Cost Anomaly Detectionと組み合わせると、予算超過前に異常なコスト急増を検知できます。Budget Actionsが「月次の累積超過防止」であるのに対し、Cost Anomaly Detectionは「日次の異常値検知」という役割分担で補完関係になります。

よくある落とし穴と対処法

【落とし穴1】IAMポリシーのアタッチ上限に引っかかる

IAMユーザーにアタッチできるポリシー数は1エンティティあたり最大10件（管理ポリシー）です。すでに10件アタッチされている状態でBudget Actionsがポリシーをアタッチしようとすると失敗します。

対処: 事前にIAMエンティティのポリシー数を確認し、余裕を持たせておく。またはIAM設計でポリシーを統合してアタッチ数を削減しておく。

【落とし穴2】予測コストの閾値は精度に注意

Budget Actionsのトリガーは「実際のコスト（Actual）」と「予測コスト（Forecasted）」の2種類から選べます。予測コストで設定すると月初に「このペースだと予算超過する」という段階でアクションが発動しますが、予測精度が低い場合に誤発動することがあります。

対処: 重要なアクション（インスタンス停止など）のトリガーは「実際のコスト」を推奨。通知目的のアクションには「予測コスト」を使うのがバランスの取れた設計です。

【落とし穴3】アクション実行後のリバートを忘れる

月次予算は毎月リセットされますが、Budget Actionsで適用したIAMポリシーは自動でリバートされません。月が変わっても制限が残り続け、翌月も開発者が新規リソースを作れない状態が続いた事例があります。

対処: 月初のリバートをカレンダー登録し、担当者を決める。または月次でリバートを自動実行するLambda関数を用意する運用が考えられます。

【落とし穴4】本番インスタンスを停止対象に含めてしまう

EC2 Instancesアクションで停止対象を設定する際、インスタンスIDを手動で入力します。設定ミスで本番インスタンスのIDを誤って入力してしまうと、予算超過時に本番が停止します。

対処: コスト配分タグで環境（`Environment: dev/stg/prod`）を明確に分類し、停止対象は `dev` タグのインスタンスのみと明文化したドキュメントを整備する。設定後は必ずレビューを行う。

Budget Actionsを最大限に活かす設計Tips

・テスト実行を必ずやる: `aws budgets execute-budget-action` コマンドを使えばアクションを手動でテスト発動できます。本番運用前に動作確認を行うこと
・通知はSlackへ転送する: SNS → Lambda → Slack Webhookのパターンでアクション発動をSlackに通知すると見逃しが減ります
・複数のアクションを組み合わせる: 1つの予算に対して複数のアクションを設定できます。閾値ごとに段階的な制御ができるため、単一の「停止」ではなく「制限→通知→停止」の多段設計が有効です
・AWS Cost Optimization Hubで削減候補を把握しておくと、Budget Actionsで止める前に事前削減できるリソースが見つかることがあります

本記事のまとめ

AWS Budget Actionsは、予算超過を「通知して終わり」から「自動制御」に格上げするための機能です。

・3種類のアクション: IAM Policy / SCP / EC2・RDS停止
・2つの実行モード: 自動実行（開発環境向け）/ 手動承認（本番隣接環境向け）
・段階的な閾値設計: 70%通知 → 90%制限 → 110%停止のような多段制御が効果的
・落とし穴: ポリシー数上限・リバート忘れ・本番インスタンスの誤設定に注意

月末の請求書を見てから慌てる運用から脱却し、Budget Actionsで「コストが一定額を超えたら自動で止まる」仕組みを作ることがFinOps成熟への第一歩です。