変更要約: in-scope サービス網羅: コンピュート配置(Elastic Beanstalk/Outposts/VMware Cloud on AWS/Wavelength/Serverless Application Repository/ECS Anywhere/EKS Anywhere/EKS Distro)・コスト可視化(Cost and Usage Report/Compute Optimizer/License Manager)・管理とガバナンス(CloudFormation/Service Catalog/Control Tower/Systems Manager/CloudWatch/X-Ray/Managed Grafana/Managed Service for Prometheus/Health Dashboard/Well-Architected Tool/Management Console)を各節に追加
4.1コンピュートの料金モデル
オンデマンド・Savings Plans/リザーブドインスタンス・スポットインスタンスという EC2 の料金モデルと、ワークロードに応じた使い分けでコストを最適化する考え方を理解します。
コスト最適化の第一歩は、ワークロードに合った料金モデルを選ぶことです。EC2 には用途別に複数の購入オプションがあります。
4.1.1EC2 の料金モデル
- オンデマンド：使った分だけ支払い、コミットなし。短期・予測困難なワークロードや開発/検証向け。最も柔軟だが単価は高め。
- Savings Plans / リザーブドインスタンス（RI）：1〜3 年のコミットで大幅割引（最大〜70%）。定常的なベースラインの稼働向け。
- スポットインスタンス：余剰キャパで最安（最大〜90% 割引）だが、中断され得る。耐障害性・ステートレスなバッチ/ビッグデータ向き。
- 専有（Dedicated）：物理サーバーを専有（ライセンス/コンプラ要件向け、割高）。
コスト最適化の第一歩は「ワークロードの性質に料金モデルを合わせる」ことです。判断軸は「コミットできるか／中断に耐えられるか」。常に動くベースライン分は Savings Plans/RI で長期コミットして割引を得る、急増や読めない分は オンデマンドで柔軟に、中断されても再実行できるステートレスなバッチは スポットで最安に——というように組み合わせるのが定石です。たとえば Web 層のベースは Savings Plans、ピーク超過分はオンデマンド、夜間の大規模バッチはスポット、と層別に最適化します。
| モデル | コスト | 向くワークロード |
|---|---|---|
| オンデマンド | 高め・コミットなし | 短期・予測困難・開発 |
| Savings Plans / RI | 割引（〜70%）・要コミット | 定常的なベースライン |
| スポット | 最安（〜90%）・中断あり | 耐障害性のあるバッチ |
シナリオ：3層 Web ＋夜間バッチ。 常時稼働の Web/アプリ層のベースライン分は Savings Plans でコミットして割引、急なアクセス増の超過分は オンデマンドで吸収。夜間の大規模データ処理は中断に強く作って スポットで最安に実行。重要な常時稼働をスポットだけに頼らないのがポイントです。
混同に注意：
①定常＝Savings Plans/RI（コミットで割引）／短期・不定＝オンデマンド／中断可＝スポット（最安）。
②スポットは中断され得るので重要な常時稼働には単独で使わない。
③Savings Plans は柔軟（コンピュート全般）、RI は特定インスタンス条件への割引、という違いも押さえる。
Q. Savings Plans とスポットの違いは？ Savings Plans は長期コミットで割引（中断なし・定常向け）、スポットは余剰キャパで最安だが中断あり（耐障害バッチ向け）。Q. スポットはどんな処理に使う？ ステートレスで中断・再実行に耐える処理（バッチ・ビッグデータ・CI 等）。Q. 複数モデルは併用できる？ はい、ベース＝Savings Plans、超過＝オンデマンド、バッチ＝スポット、と層別に最適化します。
「定常稼働＝Savings Plans/RI で節約」「中断に強いバッチ＝スポットで最安」「短期/不定＝オンデマンド」の使い分けは SAA で頻出です。スポットは中断され得るので重要な常時稼働には単独で使わない。
4.1.2その他の主要 in-scope サービス（コンピュートのプラットフォームと配置）
料金最適化の前提として、ワークロードをどのプラットフォーム/場所で動かすかの選択肢を押さえます。AWS Elastic Beanstalk はアプリのコードを上げるだけで EC2/ELB/Auto Scaling を自動構成する PaaS で、インフラ管理を最小化したいときに選びます。AWS のハードウェア/ロケーションを延伸する系統では、AWS Outposts がAWS のラックをオンプレに設置（低遅延/データ所在地要件）、VMware Cloud on AWS が既存の VMware 環境を AWS 上でそのまま運用、AWS Wavelength が通信事業者の 5G エッジに配置して超低遅延を実現します。サーバーレスのひな形を共有/再利用したいときは AWS Serverless Application Repository。
コンテナをオンプレや他環境でも同じ運用で動かすには、Amazon ECS Anywhere と Amazon EKS Anywhere があります。前者はECS の管理面でオンプレのサーバー上のコンテナを運用、後者はEKS（Kubernetes）をオンプレで実行するためのものです。さらに Amazon EKS Distro はEKS が用いる Kubernetes ディストリビューションそのもので、独自環境で同一の Kubernetes を動かしたいときに使います。
| やりたいこと | サービス |
|---|---|
| コードを上げるだけで自動構成（PaaS） | AWS Elastic Beanstalk |
| AWS をオンプレに設置（低遅延/所在地） | AWS Outposts |
| 既存 VMware を AWS 上で運用（2024/4 末に AWS からの販売は終了し Broadcom 経由） | VMware Cloud on AWS |
| 5G エッジで超低遅延 | AWS Wavelength |
| サーバーレスのひな形を共有/再利用 | AWS Serverless Application Repository |
| オンプレで ECS / EKS を運用 | Amazon ECS Anywhere / Amazon EKS Anywhere |
| EKS と同一の Kubernetes 配布 | Amazon EKS Distro |
4.1.3この節のまとめ
- オンデマンド（短期/不定）／Savings Plans・RI（定常で割引）／スポット（最安・中断あり）
- 判断軸は「コミットできるか／中断に耐えられるか」。層別に組み合わせて最適化
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 1〜3 年の利用コミットと引き換えに大幅割引を受けられる EC2 の料金モデルはどれですか？
Q2. 中断され得るが最も安価で、耐障害性のあるバッチ処理に向く EC2 の料金モデルはどれですか？
Q3. 短期間で予測困難なワークロードに最も柔軟に対応できる料金モデルはどれですか？