Spend limitsは、プロジェクトの月間支出上限を設定し、その上限に達するとAWSがプロジェクトを停止する機能です。AWS Budgetsは、コストと使用量を追跡する予算管理ツールです。どちらの名前にも「制限」という言葉が含まれていますが、予算に関するメールを受け取ることと、実行中のプロジェクトが停止することは異なります。
質問への答えは、条件付きで「はい」です。新しいAWSサインアップ環境には、プロジェクト単位のSpend limitsがあります。ただし、これは既存のAWSアカウント全体に費用遮断スイッチが追加されたという意味ではありません。この記事では、まず適用対象を確認し、停止と再開の条件、既存のBudgetsの通知とActionsを順に比較します。これは実際のAWSアカウントで実行した使用レビューではなく、2026年10月21日にAWS公式ドキュメントを確認した説明です。 サインアップ方法の比較

1. まず確認すべきはサインアップ環境です
AWSドキュメントでは、サインアップパスをSign up for AWS (new)とSign up for AWS (advanced)に分けています。新しい環境では、AWS Builder IDに基づいてプロジェクトと事前設定された設定が提供されます。ここでいうプロジェクトは、コストタグやフォルダを意味しません。プロジェクト内には、AWSアカウントであるproject accountとコラボレーション設定が含まれています。 サインアップ方法とプロジェクト構造
公式比較表では、Spend limitの作成はnew側ではサポート、advanced側では未サポートと表示されています。ドキュメントの上部には、現在一部のお客様に新しいエクスペリエンスを提供しており、まだアクセスできない場合がありますという警告もあります。したがって、サインアップ日だけで利用可能かどうかを判断したり、既存の一般アカウントのBudgetsメニューで同じ機能を探したりすると、混乱しやすいです。既存アカウント全体に遡及適用されるという案内は確認されていません。 公式比較表

図1. 公式ドキュメントに基づいて再構成。 サインアップ方法の比較、 有料プランへの移行、 advanced機能の有効化。
もう一つ区別すべきは、有料プランへの移行とadvanced機能の有効化です。新しい環境で有料プランにアップグレードすると、プロジェクトにSpend limitを作成できます。このアップグレードは、advanced環境に切り替える手順ではありません。プロジェクトごとに有料に切り替える方式でもなく、アップグレードするとすべてのプロジェクトが一緒に移行されます。 有料プラン移行時の考慮事項
2. Spend limitは何を基準に停止するのか
Spend limitは、有料プランでプロジェクト所有者が管理します。月間の税引き前費用が基準となり、クレジットは除外されます。設定金額自体が利用料ではありません。最小値は、20ドルとAWSの保守的な予想支出のうち大きい方です。予想には、当月の累積使用量、実行中のリソース、前月の活動が反映されます。再開時には、当月の支出と未請求の使用量も考慮されます。したがって、40ドルを希望しても、現在の状態によっては設定が拒否される場合があります。 制限計算条件
上限に達すると、プロジェクトとすべてのリソースが停止されます。データは保持されますが、停止後90日間何も操作しないと、プロジェクトデータは永久に削除されます。一部のリソースは、再開後に手動で再起動する必要があります。一般的なリソースの停止動作と、この管理されたプロジェクトの停止を同じものとして説明すべきではありません。 停止とデータ保持の条件
再開するには、AWS Settingsで上限を引き上げます。所有者はBillingのCost by projectで上限を修正でき、変更は即座に適用されます。ドキュメントが案内する復旧は、「翌月まで待てば自動再開」ではありません。 上限変更と再開
3. 月額40ドルの実験プロジェクトを仮定してみよう
以下は、動作を理解するための仮想設計です。実際の請求書、実際の実行ログ、製品性能測定値ではありません。新しい環境の有料プランで、40ドルの設定が許可されるプロジェクトを1つ仮定します。税金まで含めたカード決済額を正確に40ドルに合わせるという例ではありません。
Spend limitは、実際の費用の50%・75%・90%で通知を送信し、今後10日以内に上限に達するか超過すると予想される場合にも通知します。40ドルに比率を掛けると、20ドル・30ドル・36ドルになります。この金額は仮想計算であり、実際の通知記録ではありません。選択式の早期制御も提供されるため、自動停止の範囲を確認して選択します。 通知と選択式制御

図2. 公式ドキュメントに基づいて再構成した仮想40ドル事例。金額は比率計算であり、実際の発生記録ではありません。 Spend limitの動作、 再開手順。
この仮想プロジェクトで決めるべきは金額だけではありません。「実験が停止してもよいか」「停止通知を誰が確認するか」「データを別途保管したか」も設計に含まれます。コスト管理の成功と実験データの安全性はそれぞれ確認する必要があります。特に長期放置する実験であれば、上限設定だけで運用計画が終わるわけではありません。
4. Budgetsのメールはどのタイミングで通知されるのか
既存のAWS Budgetsでは、月間の費用目標を設定し、実際の費用または予想費用がしきい値を超えたときに、EメールまたはAmazon SNSで通知を受け取ることができます。予算金額を入力したり、Eメールを登録しただけでは、リソースが自動的に停止されるわけではありません。Spend limits自体もドキュメント上はAWS Budgetsの一種ですが、一般的な予算の通知設定と提供される制御動作が異なります。 Budgetsの概要、 Spend limitsの位置
Budgetsの主要な制約は、コストデータがリアルタイムの制御信号ではないという点です。概要ドキュメントでは、予算情報が1日最大3回更新され、通常は前回の更新から8〜12時間後に更新されると説明されています。使用発生と請求反映の間にも遅延があり、通知前にすでにしきい値を超える費用が発生する可能性があり、通知後も費用値は変動する可能性があります。これを「8時間以内に必ず遮断する」という約束として解釈すべきではありません。 更新頻度と遅延警告
ベストプラクティスドキュメントでは、基盤となる請求データが少なくとも1日1回更新されると説明されています。両方の説明を合わせると、通知は請求データの更新に依存しており、最大3回という数字はリアルタイム性を保証するものではないという意味になります。予想費用通知には、約5週間の使用履歴も必要です。新しいプロジェクトでは、予測通知だけを信頼するよりも、実際の費用しきい値も一緒に検討する方が合理的です。最後の文はこの記事の運用提案です。 Budgetsのベストプラクティス
仮想的にBudgetsの予算も40ドル、実際の費用通知を50%と75%に設定したとしましょう。計算上の基準は20ドルと30ドルですが、20ドルが発生したその瞬間にメールボックスに届くという意味ではありません。この数字は通知の判断基準であり、通信・集計の遅延をなくす装置ではありません。中断が許されないサービスであれば、通知を受け取って対応する余裕まで計画する必要があります。
5. Budgets Actionsを適用すれば同じ上限になるのか
AWS Budgets Actionsは、しきい値を超えたときに指定されたアクションを実行する機能です。自動実行と手動承認後の実行を選択できます。IAMポリシーやSCPを適用したり、特定のEC2・RDSインスタンスをターゲットにしたりできます。この際、必要な実行ロールと権限を設定する必要があります。 Actionsの設定、 権限設定の注意点
しかし、「新しいリソースの作成禁止」は「現在のリソースの費用すべてを停止」とは異なります。ポリシーの対象、すでに実行中のサービス、残っている他のリソースを個別に考慮する必要があります。公式のベストプラクティスでは、Auto Scalingグループのインスタンスを停止しても、再起動されたり、代替インスタンスが作成されたりする可能性があると警告しています。これが、停止ボタン一つを全体的な費用上限として扱うのが難しい理由です。 Auto Scalingと予算アクション
Actionsも予算情報に基づいて動作します。通知の遅延とアクションの対象範囲を合わせて考慮すると、指定した40ドルで全てのサービス費用を正確に停止するグローバルな遮断器として説明することはできません。これは公式ドキュメントの遅延・対象説明を総合した判断であり、別途の実測結果ではありません。 予算の遅延、 Actionsの対象
WRIMO-MD-TABLE-0]表の根拠: [Spend limits, Budgets, Actions.
料金も分けて考える必要があります。Budgetsのモニタリングと通知は無料です。アクションが有効化された予算は、毎月最初の2つが無料で、それ以降の追加予算ごとに1日あたり0.10ドルです。これは、1つの予算内のアクションの数とは別の基準です。Eメールで受け取るBudgets Reportsは、配信レポートごとに0.01ドルで、一般的なしきい値通知とは異なります。接続サービス料金まで全て無料という意味ではありません。 AWS Budgets公式料金
6. advancedへの移行前にコスト管理を再設計する
advanced機能を有効化すると、既存のSpend limitは削除され、停止されていたプロジェクトは再アクティブ化されます。その後、その環境ではSpend limitを作成することはできません。有効化は元に戻せないため、単により多くのサービスやリージョンを使用するために移行する場合でも、コスト管理の変化まで考慮する必要があります。 advanced機能有効化による変更
AWSは、移行前に現在のプロジェクト費用を確認し、アイドル状態のリソースを削除または停止することを推奨しています。移行後には、Budgets、Cost Explorer、Cost Anomaly Detectionなどのコスト管理ツールを使用できます。これらのツールが利用できることと、以前のプロジェクト上限が引き続き残っていることは別問題です。 移行準備事項
既存アカウントで実験を運用する場合、Budgetsの実際の費用通知、必要なActions、サービスごとの使用制限と整理手順を組み合わせた設計が現実的です。新しい環境でSpend limitsを使用できる場合は、中断の許容可否とデータ復旧計画まで含めて選択します。この記事の40ドルは機能を比較するための基準であり、ワークロードに合った費用見積もりや実際に設定可能な金額を代用するものではありません。
「AWSにも費用上限ができたのか」という質問では、金額よりもまず適用環境を確認する必要があります。次に、Eメール通知なのか、指定されたアクションなのか、プロジェクト停止まで含むのかを区別することで、自身の実験に合ったコスト管理を選択できます。
公式参考資料と確認範囲
- Spend limitの作成・計算・停止・90日データ削除
- 新規・advancedサインアップ方法の比較
- 有料プランへのアップグレード
- Spend limitの変更・再開
- advanced機能の有効化・上限の削除
- AWS Budgetsの管理・更新・遅延
- Budgetsのベストプラクティス・予測履歴・Auto Scaling
- Budget Actions
- AWS Budgetsの料金
確認日: 2026-10-21。公式ドキュメントに基づいた説明であり、ログイン画面、実際のAWSアカウントでの利用可能性、課金・通知配信時間・停止・再開・削除動作は実測していません。制限された配布範囲と実際の適用画面は異なる場合があります。
コメントを残す