コストの可視化・分析ができたら、次は「予算内に収める仕組み」と「無駄なリソースを削る仕組み」を自動化する段階に進みます。本記事ではAWS BudgetsとAWS Compute Optimizerを解説します。

SAA レベル：基礎概念

AWS Budgetsの基本

コスト・使用量・RI/Savings Plansのカバレッジ/利用率など、複数の指標に対して予算のしきい値を設定できる
しきい値を超えた（または超えそうな）場合に、SNSやメールで通知する

SAA 試験のポイント

AWS Budgetsはあくまで通知・アラートの仕組みであり、予算超過時にリソースを自動的に停止させる機能はデフォルトでは持ちません。自動アクションを行いたい場合は、後述するようにLambda等と組み合わせる必要があります。

Compute Optimizerの基本

CloudWatchメトリクス（CPU使用率、メモリ使用率等）を機械学習で分析し、EC2・EBS・Lambda・Auto Scalingグループのサイズ適正化（Right Sizing）を推奨する
「オーバープロビジョニング（過剰スペック）」「アンダープロビジョニング（スペック不足）」の両方を検出する

SAP レベル：高度な設計シナリオ

予算超過アラート設計の高度化

SAP 試験のポイント

単純な「予算の80%に到達したらメール通知」という設計だけでなく、SAPレベルでは**予測ベースのアラート（Budgetsの予測機能を使い、月末時点で予算超過が見込まれる時点で早期に警告する）**や、EventBridge経由でLambdaをトリガーし、特定の条件下では自動的にリソースを停止・スケールダウンするアクションまで組み込む設計が問われます。

Compute Optimizerによるサイズ適正化のワークフロー

SAP 試験のポイント

Compute Optimizerの推奨事項をそのまま鵜呑みにして機械的にリサイズするのではなく、SAPレベルでは推奨事項をレビューし、ワークロードの季節性やピーク特性を踏まえた上で適用する運用フローを構築することが求められます。特にSavings Plans/RIでコミットしているインスタンスをリサイズする場合、コミットメントとの整合性（EC2 Instance Savings Plansはファミリー固定のため、ファミリーを跨ぐリサイズで割引が適用外になる可能性がある）も考慮が必要です。

検出パターン	推奨アクション
CPU使用率が恒常的に低い（オーバープロビジョニング）	インスタンスサイズのダウングレード
CPU使用率が恒常的に高い（アンダープロビジョニング）	インスタンスサイズのアップグレードまたはAuto Scaling強化
世代の古いインスタンスタイプを使用	新世代インスタンスタイプへの移行（同等以上の性能でコスト減）

設計上の落とし穴

「Compute Optimizerの推奨に従って機械的に全インスタンスをダウンサイズする」という運用は、突発的なトラフィック増加への耐性を損なうリスクがあります。SAPレベルでは、ビジネス上のピーク特性（セール時期等）を考慮せずにサイズ適正化を進めることの危険性が問われることがあり、単純なコスト削減と可用性のバランスを取った判断が重要です。

Trusted Advisorとの連携

Trusted Advisorのコスト最適化カテゴリでは、アイドル状態のリソース（未使用のEIP、低使用率のEC2等）を検出できる
Compute Optimizerがサイズの適正化に特化しているのに対し、Trusted Advisorはより広範な「そもそも不要なリソース」の検出に強みがあるという役割の違いを理解しておく

まとめ

SAA: AWS Budgetsが予算のアラート機能であり、自動停止機能はデフォルトでは持たないこと、Compute Optimizerがサイズ適正化を機械学習で提案する仕組みであることを理解する。
SAP: 予測ベースのアラートとLambda連携による自動アクション、Savings Plansとの整合性を踏まえたリサイズ判断、ビジネス特性を考慮した適正化運用ができる。

ここまでで 1-5 コスト最適化と可視化戦略 の全5記事、そして ドメイン1：組織の複雑性に対応するソリューション設計 の全体（32記事）が完了しました。次は ドメイン2：新規ソリューションの設計 に進みましょうか？