AWS Budgetsは、月の予算額を決めておき、実績や予測がしきい値を超えたらメールやSNSで知らせるサービスです。予算の作成と通知だけなら料金はかかりません。ただし「設定したのに通知が来ない」「来たときには超過していた」という声も多く、原因の大半は更新間隔と通知の仕様にあります。この記事では、AWS Budgetsの予算タイプと料金、実績アラートと予測アラートの違い、SNSへの通知、超過時に権限を絞る予算アクションまでを、2026年10月時点の公式ドキュメントとAWS CLI 2.37系のリファレンスに沿ってコマンド付きで整理します。
まとめ:AWS Budgetsで請求の想定外を防ぐために決めておく5項目
先に結論です。AWS Budgetsを設定する前に、次の5点を決めておくと通知の取りこぼしが減ります。
- 予算はアカウント全体の月次コスト予算を1本目にし、サービス別やタグ別の予算はその後に足す
- 通知は実績80%と予測100%の2本を組み合わせる。実績アラートは1期間に1回しか届かない
- データの更新は1日最大3回で、通知は使った瞬間には来ない。日次の上限管理には向かない
- Slackや運用ツールへ流すならSNSトピックを使い、トピックポリシーで
budgets.amazonaws.comに発行を許可する - 止める仕組みが要るなら予算アクションを使う。3本目以降のアクション付き予算は1日0.10ドルかかる
通知だけで足りるのか、権限の剥奪まで自動化するのかで構成が変わります。以降で順に手順へ落とします。
AWS Budgetsの予算タイプ6種類と無料で使える範囲・料金の決まり方
最初に、何を予算として監視できるのかと、どこから料金が発生するのかを確認します。
コスト・使用量・RI・Savings Plansを監視する6つの予算タイプ
AWS Budgetsのユーザーガイドに載っている予算タイプは、コスト予算、使用量予算、RI使用率予算、RIカバレッジ予算、Savings Plans使用率予算、Savings Plansカバレッジ予算の6種類です。
| 予算タイプ | CLIの値 | 通知が出る条件 |
|---|---|---|
| コスト予算 | COST | 金額が予算を超えた・超える見込み |
| 使用量予算 | USAGE | 使用量が上限を超えた・超える見込み |
| RI使用率 | RI_UTILIZATION | 購入済みRIの使用率が目標を下回った |
| RIカバレッジ | RI_COVERAGE | RIで賄えた時間の割合が目標を下回った |
| SP使用率 | SAVINGS_PLANS_UTILIZATION | Savings Plansの使用率が目標を下回った |
| SPカバレッジ | SAVINGS_PLANS_COVERAGE | Savings Plansで賄えた割合が目標未満 |
実務でまず作るのはコスト予算です。RIとSavings Plansの4種類は、購入したコミットメントを使い切れているかを見るためのもので、購入後に追加します。Savings Plansの購入額の決め方はAWS Savings Plansの選び方と購入手順|東京の実割引率とコミット額の決め方で扱っています。
予算は無料・アクション付き3本目から1日0.10ドルかかる料金体系
AWS Budgetsの料金ページによると、予算の作成と監視、アラートの送信は無料です。料金が発生するのは2つだけです。
- 予算アクションを設定した予算:毎月最初の2本は無料(1本に付けるアクション数は問わない)。3本目以降は1予算あたり1日0.10ドル
- Budgets Reports(予算の状況を定期的にメール配信する機能):1回の配信につき0.01ドル
アクション付き予算を5本置くと、有料になる3本×0.10ドル×30日で月9ドル前後です。通知だけの予算は何本作っても請求に乗らないため、まず通知で運用し、止める必要がある予算だけにアクションを付ける順番で十分です。
1日最大3回のデータ更新間隔と予算アラートが届かない・遅れる仕組み
AWS Budgetsでいちばん誤解されているのが通知のタイミングです。ここを知らないと、予算を設定したことで安心してしまいます。
更新は1日最大3回・前回から8〜12時間後になるデータ反映の間隔
ユーザーガイドには、AWS Budgetsの情報は1日最大3回更新され、更新は通常前回から8〜12時間後と書かれています。さらに、リソースを使った時点と請求データに反映される時点にも差があります。
つまり、夜中にGPUインスタンスを大量に起動しても、通知が届くのは数時間から半日後です。その間に課金は進みます。AWS Budgetsは「月の予算を超えそうだと早めに気づく」ための仕組みであって、「使いすぎた瞬間に止める」ブレーカーではありません。漏えいしたアクセスキーによる不正利用のように数時間で金額が跳ねる事故は、予算アラートより先に、IAMの権限設計とGuardDutyなどの検知で防ぐ領域です。
実績アラートは1期間1回・予測アラートは約5週間のデータが必要
ベストプラクティスのページに、通知の挙動が細かく書かれています。
- 実績(ACTUAL)のアラートは、予算期間ごとに、しきい値に初めて達したときの1回だけ送られる
- 予測(FORECASTED)のアラートは、予測値がしきい値を上下するたびに、同じ期間内で複数回届くことがある
- 予測を出すには約5週間分の使用データが必要で、新しいアカウントでは予測アラートがしばらく発火しない
- 1つのアラートに設定できる通知先は、メールアドレス10件とSNSトピック1つまで
開設直後のアカウントで予測100%だけを設定すると、最初の1か月は何も届きません。立ち上げ期は実績ベースのしきい値を50%・80%・100%と刻み、データが溜まってから予測アラートを足す構成にします。新規アカウントの無料プランの期限と合わせて確認したい場合は、AWSを無料で使える範囲と6か月の期限|無料プランとAlways Freeの境界をCLIで確認する手順が前提になります。
AWS CLIで月次コスト予算と実績・予測の2段階アラートを作成する手順
ここからはコマンドで予算を作ります。AWS CLI v2の導入と認証はAWS CLIの導入と運用|v2の設定・SSO認証・v1サポート終了への移行手順を済ませた状態から始めます。
budget.jsonと通知定義を書いてcreate-budgetで作成するコマンド
create-budgetのリファレンスでは、必須の引数は--account-idと--budgetの2つで、通知は--notifications-with-subscribersで同時に登録できます。アカウント全体で月300ドルの予算を作り、実績80%と予測100%で通知する例です。
# budget.json:アカウント全体の月次コスト予算(300 USD)
cat > budget.json <<'EOF'
{
"BudgetName": "monthly-total",
"BudgetType": "COST",
"TimeUnit": "MONTHLY",
"BudgetLimit": { "Amount": "300", "Unit": "USD" }
}
EOF
# notifications.json:実績80%と予測100%の2段階
cat > notifications.json <<'EOF'
[
{
"Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80,
"ThresholdType": "PERCENTAGE"
},
"Subscribers": [
{ "SubscriptionType": "EMAIL", "Address": "[email protected]" }
]
},
{
"Notification": {
"NotificationType": "FORECASTED",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 100,
"ThresholdType": "PERCENTAGE"
},
"Subscribers": [
{ "SubscriptionType": "EMAIL", "Address": "[email protected]" }
]
}
]
EOF
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
aws budgets create-budget \
--account-id "$ACCOUNT_ID" \
--budget file://budget.json \
--notifications-with-subscribers file://notifications.json
成功しても何も表示されません。作成結果は次の2つのコマンドで確かめます。
# 予算の設定値と当月の実績・予測を確認
aws budgets describe-budget --account-id "$ACCOUNT_ID" --budget-name monthly-total
# 登録された通知の一覧を確認
aws budgets describe-notifications-for-budget --account-id "$ACCOUNT_ID" --budget-name monthly-total
describe-budgetの出力にCalculatedSpendが入り、ActualSpendとForecastedSpendが見えれば監視が動いています。予測値は前の章で触れた5週間のデータが溜まるまで空のことがあります。
TimeUnitのCUSTOMとAutoAdjustDataで予算期間と金額を決める方法
同じリファレンスでは、TimeUnitにDAILY・MONTHLY・QUARTERLY・ANNUALLY・CUSTOMの5つを指定できます。CUSTOMは会計年度やプロジェクト期間に合わせた予算で、ベストプラクティスのページによると終了日は開始日から3年以内です。開始日は計算に含まれ、終了日は含まれません。
注意したいのは、カスタム期間の予算は自動で更新されず、終了日で失効する点です。3か月の検証プロジェクト用に作った予算が切れたまま、本番移行後の費用を誰も見ていなかった、という状態が起こりえます。継続して監視する予算はMONTHLYで作り、CUSTOMはプロジェクト単位の追加予算に限定します。
金額を固定せず、過去の実績から毎期自動で決める場合はAutoAdjustDataを使います。AutoAdjustTypeにHISTORICALを指定すると過去の期間の実績から、FORECASTを指定すると予測から予算額が決まります。費用が毎月伸びていくサービスでは、固定額だと毎月アラートが鳴り続けて誰も見なくなるため、自動で予算額を調整するこちらの方式が向いている構成です。
FilterExpressionでサービス別・タグ別・アカウント別に予算を分ける
アカウント全体の予算を作った後、次に追加するのはサービスやタグ単位で監視するための予算です。リファレンスでは、従来のCostFiltersより柔軟なFilterExpressionが推奨されており、AND・OR・NOTを組み合わせられます。キーにはSERVICE、REGION、LINKED_ACCOUNT、TAG_KEY、COST_CATEGORY_NAMEなどが使えます。
タグで分ける場合は、対象のタグが請求側でコスト配分タグとして有効になっている必要があります。予算そのものにもタグを付けられますが、ベストプラクティスのページにある通り、予算に付けたタグはアクセス制御用で、コスト配分には使われません。部署別やプロジェクト別に費用の内訳を分析したいなら、AWS Cost Explorerとは?コスト可視化・分析の仕組みと料金・使いどころを実装者目線で解説のフィルタで同じ切り口を先に確認し、予算はその結果に合わせて作ると数字が食い違いません。
SNSトピックで予算アラートをSlackや運用ツールへ流すためのポリシー設定
メールだけでは見落とすので、運用チームのチャンネルやチケットシステムに流したくなります。その入口になるのがSNSトピックです。
budgets.amazonaws.comに発行を許可するトピックポリシーの書き方
SNSトピックの設定ページでは、トピックのアクセスポリシーにbudgets.amazonaws.comからのSNS:Publishを許可する文を足すよう書かれています。条件のaws:SourceAccountとaws:SourceArnで、自分のアカウントの予算からの発行だけに絞ります。
TOPIC_ARN=$(aws sns create-topic --name budget-alerts --query TopicArn --output text)
cat > topic-policy.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSBudgetsSNSPublishingPermissions",
"Effect": "Allow",
"Principal": { "Service": "budgets.amazonaws.com" },
"Action": "SNS:Publish",
"Resource": "${TOPIC_ARN}",
"Condition": {
"StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" },
"ArnLike": { "aws:SourceArn": "arn:aws:budgets::${ACCOUNT_ID}:*" }
}
}
]
}
EOF
aws sns set-topic-attributes --topic-arn "$TOPIC_ARN" \
--attribute-name Policy --attribute-value file://topic-policy.json
# 既存予算の実績80%通知にSNSの通知先を追加する
aws budgets create-subscriber --account-id "$ACCOUNT_ID" --budget-name monthly-total \
--notification NotificationType=ACTUAL,ComparisonOperator=GREATER_THAN,Threshold=80,ThresholdType=PERCENTAGE \
--subscriber SubscriptionType=SNS,Address="$TOPIC_ARN"
このポリシーを入れると、トピックの既定ポリシーは置き換わります。ほかのサービスからも同じトピックへ発行しているなら、既存の文を残したうえで追記してください。SNSの配信先やフィルタの考え方はAmazon SNSとは|Pub/Sub通知の仕組み・配信先・FIFO/フィルタリングと採用判断を実装者目線で解説にまとめています。
同一アカウント限定・暗号化トピック・購読未承認で通知が止まる3つの原因
同じページの注意書きから、通知が届かない原因を重い順に挙げます。
- トピックが予算と別アカウントにある。予算とSNSトピックは同じアカウントに置く必要があり、クロスアカウントのSNSは使えない
- トピックがKMSで暗号化されている。暗号化したトピックは、KMSキーのポリシーでAWS Budgetsに権限を渡さない限り使えず、画面には「The SNS topic is encrypted」と出る
- 購読を承認していない。SNSコンソールのサブスクリプション一覧で
budgetと絞り込み、状態がPendingConfirmationのままなら確認メールを再送する
3つ目はメールで受け取る構成でよく起きます。設定直後に届いた確認メールを迷惑メールに振り分けられ、誰も承認していなかった、というケースです。
予算アクションでIAMポリシー・SCP・EC2停止を超過時に自動実行する設定
通知を受けても人が動けない時間帯がある場合は、予算アクションで「これ以上リソースを作らせない」操作まで自動化できます。
予算アクションの実行ロールに付けるマネージドポリシーと信頼ポリシーの例
予算アクションのページで選べる操作は、IAMポリシーの適用、SCPの適用、EC2インスタンスとRDSインスタンスの停止の3系統です。AWS Budgetsはこれを、利用者が用意したサービスロールを引き受けて実行します。
権限のリファレンスにあるマネージドポリシーは役割が2つに分かれています。設定する人にはAWSBudgetsActionsWithAWSResourceControlAccessを付けます。budgets:*のほか、budgets.amazonaws.comへロールを渡すiam:PassRoleを含むポリシーです。実行ロールのほうには、EC2とRDSを停止するならAWSBudgetsActions_RolePolicyForResourceAdministrationWithSSMを付けます。こちらはSystems Managerのオートメーション経由で停止と起動を行う権限で、2026年4月7日にも更新されています。
# 実行ロールの信頼ポリシー(AWS Budgetsだけが引き受けられる)
cat > trust.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": { "Service": "budgets.amazonaws.com" },
"Action": "sts:AssumeRole",
"Condition": { "StringEquals": { "aws:SourceAccount": "${ACCOUNT_ID}" } }
}
]
}
EOF
aws iam create-role --role-name BudgetActionRole \
--assume-role-policy-document file://trust.json
aws iam attach-role-policy --role-name BudgetActionRole \
--policy-arn arn:aws:iam::aws:policy/AWSBudgetsActions_RolePolicyForResourceAdministrationWithSSM
IAMポリシーやSCPを付け外しするアクションでは、上の停止用ポリシーとは別に、ロールへポリシーを付与する権限が要ります。実行ロールに渡す例文は予算アクションのページから辿れる例示ポリシーにあるので、そこから必要な範囲だけを付けてください。ロールとポリシーの関係はAWS IAMとは?仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説が前提知識になります。
MANUAL承認で開発ロールに拒否ポリシーを適用するコマンドの設定例
create-budget-actionのリファレンスでは、--action-typeにAPPLY_IAM_POLICY・APPLY_SCP_POLICY・RUN_SSM_DOCUMENTSを、--approval-modelにAUTOMATICかMANUALを指定します。実績100%で、開発用ロールにEC2の新規起動を拒否するポリシーを当てる例です。
cat > action-definition.json <<EOF
{
"IamActionDefinition": {
"PolicyArn": "arn:aws:iam::${ACCOUNT_ID}:policy/DenyEc2RunInstances",
"Roles": ["DevelopersRole"]
}
}
EOF
aws budgets create-budget-action \
--account-id "$ACCOUNT_ID" \
--budget-name monthly-total \
--notification-type ACTUAL \
--action-type APPLY_IAM_POLICY \
--action-threshold ActionThresholdValue=100,ActionThresholdType=PERCENTAGE \
--definition file://action-definition.json \
--execution-role-arn "arn:aws:iam::${ACCOUNT_ID}:role/BudgetActionRole" \
--approval-model MANUAL \
--subscribers SubscriptionType=EMAIL,[email protected]
DenyEc2RunInstancesは、ec2:RunInstancesをDenyする顧客管理ポリシーとして先に作っておきます。MANUALにすると、しきい値に達した時点でアクションは承認待ちになり、担当者がコンソールで承認してから実行されます。最初はMANUALで運用し、誤発火が無いことを1〜2期間確かめてからAUTOMATICへ切り替える順番が安全です。
Auto Scalingで停止が無効になる場面とクロスアカウントの制約
ベストプラクティスのページには、Auto Scalingグループ配下のEC2を予算アクションで停止しても、Auto Scalingがインスタンスを再起動するか、代わりのインスタンスを起動すると書かれています。停止だけでは止まらないため、起動テンプレートが使うロールの権限を外す2本目のアクションと組み合わせる必要があります。
もう1つの制約は範囲です。管理アカウントからほかのアカウントへSCPを当てることはできますが、ほかのアカウントのEC2やRDSを停止の対象にはできません。マルチアカウント構成で「超過したメンバーアカウントで新しいリソースを作らせない」を実現するなら、SCPのアクションを使います。SCPの設計はAWS Organizationsとは?マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説を参照してください。
予算の上限監視・費用の異常検知・原因分析の使い分けと予算アクションの採用判断
最後に、AWS BudgetsとCost Anomaly Detection・Cost Explorerの使い分けを、予算の上限監視・費用の異常検知・原因分析という役割から整理し、予算アクションまで入れるべきかを判断します。
しきい値による予算上限の監視と機械学習による費用急増の検知の違い
Cost Anomaly Detectionのページによると、こちらは機械学習で費用の異常なパターンを検知するサービスで、請求データの処理後に1日約3回、割引適用後の正味コストを監視します。新しく使い始めたサービスは、異常を検知できるまでに10日分の利用データが必要です。
役割は補完関係です。AWS Budgetsは「月300ドルを超えそう」という人が決めた上限を見張り、Cost Anomaly Detectionは「先週より特定サービスが急に増えた」という変化を拾います。月の総額が予算内でも、特定のサービスが数倍に跳ねている場合に先に気づくのは、Cost Anomaly Detectionのほうです。同じページには、AWS Marketplaceのサードパーティ製品(Amazon Bedrockのサードパーティ基盤モデルを除く)は監視しないので、その費用の通知にはAWS Budgetsを使うよう書かれています。原因の深掘りはCost Explorer、明細レベルの集計はAWS CURとは:CUR 2.0をData Exportsで出力しAthenaで集計する手順の役割です。
通知だけで十分な条件と予算アクションまで入れるべき3つの場面
判断を言い切ります。本番ワークロードだけを動かすアカウントには、予算アクションを入れません。予算超過でIAMポリシーが当たり、障害対応のためのスケールアウトまで止まれば、費用の超過より大きな損失になります。本番は通知とCost Anomaly Detectionで人が判断し、止めるかどうかは人が決めます。
予算アクションを入れるべき場面は3つです。1つ目は、開発者が自由にリソースを作れる検証用アカウントで、消し忘れが積み上がる場合。2つ目は、研修やハッカソンのように参加者ごとのアカウントを配り、上限額を契約で決めている場合。3つ目は、補助金や受託案件の費用枠が決まっていて、枠を超えると自社負担になる場合です。いずれも「止めても業務が止まらない」ことが条件です。
予算を設定したら、次は費用そのものを下げる工程です。インスタンスサイズの見直しはAWS Compute Optimizerとは?仕組み・レコメンデーションの読み方と料金・採用判断を実装者目線で解説のレコメンデーションから始められます。マルチアカウントの予算設計やコスト監視の仕組みをまとめて整えたい場合は、インフラ構築(AWS・Google Cloud・Azure)で要件整理から対応しています。
よくある質問
AWS Budgetsについて検索されている質問に、公式ドキュメントの記載をもとに答えます。
AWS Budgetsは無料で使えますか?
予算の作成、監視、アラートの送信は無料です。料金がかかるのは、予算アクションを設定した予算の3本目以降(1予算あたり1日0.10ドル)と、Budgets Reportsの配信(1回0.01ドル)の2つです。通知だけの予算は本数に関係なく請求に乗りません。
AWS Budgetsのアラートが届かないのはなぜですか?
多い原因は4つです。データの更新が1日最大3回で、しきい値を超えても数時間遅れること。実績アラートは1期間に1回しか送られないこと。予測アラートは約5週間分のデータが溜まるまで発火しないこと。SNSを使う場合は、トピックポリシーの不足、KMS暗号化、購読の未承認のいずれかで止まっていることです。
AWS Budgetsで予算を超えたら自動でサービスを止められますか?
予算アクションで、IAMポリシーやSCPを当てて新規作成を拒否したり、指定したEC2・RDSインスタンスを停止したりできます。ただし更新間隔のぶん反応は遅れ、Auto Scaling配下のインスタンスは再起動されます。課金を確実にゼロにする仕組みではなく、追加の作成を止める仕組みと考えてください。
AWS Budgetsで1日あたりの利用料を監視できますか?
TimeUnitにDAILYを指定すれば日次の予算を作れます。ただしデータの更新は1日最大3回で、前回から8〜12時間空くことがあるため、当日の超過に当日中に気づける保証はありません。日次予算は「昨日いくら使ったか」を毎日確かめる用途と割り切り、急な増加の検知はCost Anomaly Detectionと組み合わせてください。
組織のメンバーアカウントごとに予算を作るにはどうすればよいですか?
管理アカウントで、フィルタにメンバーアカウントを指定した予算を作ります。メンバーアカウントの利用者は、管理アカウントへのアクセス権が無い限りその予算を見られません。また、メンバーアカウントが組織を離れると、離脱後の費用だけを追う挙動に変わり、その変化は通知されないとベストプラクティスのページに書かれています。組織変更のたびに予算を見直してください。
関連記事
- AWS Cost Explorerとは?コスト可視化・分析の仕組みと料金・使いどころを実装者目線で解説:予算アラートの原因をサービス別・期間別に掘り下げる分析側の手順。
- AWS CURとは:CUR 2.0をData Exportsで出力しAthenaで集計する手順:明細データを出力して独自の集計をする方法。
- AWS Organizationsとは?マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説:予算アクションで当てるSCPと一括請求の前提。
- AWSを無料で使える範囲と6か月の期限|無料プランとAlways Freeの境界をCLIで確認する手順:開設直後のアカウントで先に確認したい無料プランの期限。
- AWS Savings Plansの選び方と購入手順|東京の実割引率とコミット額の決め方:Savings Plans使用率予算の対象になる購入の判断。