SAA コスト最適化設計パターン4選｜Reserved/Savings Plans・Spot・S3ライフサイクル・右サイジングの要件別選択基準
AWS SAA-C03 のコスト最適化ドメイン（配点20%）を攻略する設計パターン4選。EC2 購入オプション（On-Demand / Reserved Instances / Savings Plans / Spot）の使い分け、S3 ストレージクラスとライフサイクル、Compute Optimizer による右サイジング、サーバーレス移行を要件キーワードから即断できる粒度で解説。「コストを下げたい」問題はこの4パターンで完全網羅できる。
「コストを下げるには何を使えばいい？」という問いに、SAA-C03 は4パターンしか答えを持っていない。 コスト最適化ドメインは配点20%と軽く見られがちだが、実は他のドメインにもコスト視点の問題が散在する。攻略の核心は**「どの使用パターンにどの購入オプションを組み合わせるか（EC2コスト）」「どのストレージクラスへいつ移行するか（S3コスト）」「リソースが適切なサイズか（右サイジング）」「サーバーレスに移行すべきか（構造コスト）」の4軸**で要件を振り分けることだ。本記事では、SAA-C03 の「コストを下げる」問題を即断できる4設計パターンを、要件キーワードから逆引きできる粒度で解説する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：コスト最適化は「EC2購入オプション・S3階層・右サイジング・サーバーレス」の4軸で決まる
- EC2 購入オプションの全体像（On-Demand / RI / SP / Spot）
- Savings Plans と Reserved Instances の違い（SAA 最頻出比較）
- S3 ストレージクラスとライフサイクルポリシー
- 右サイジング（Compute Optimizer / Trusted Advisor）
- パターン1：EC2 購入オプション組み合わせ（RI/SP + Spot + On-Demand 3層構造）
- パターン2：S3 ライフサイクルによるストレージコスト最適化
- パターン3：Compute Optimizer による右サイジング
- パターン4：サーバーレス移行（Lambda / Fargate）でインフラコストをゼロに近づける
- 要件キーワード早見表
- 頻出ひっかけパターンと正しい打ち手
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：コスト最適化は4軸で決まる
SAA-C03 のコスト最適化問題を最短で解く骨格は、「何のコストを、どのアプローチで下げるか」を4軸で独立して判断することだ。
| 軸 | 問いかけ | 判断のキーワード |
|---|---|---|
| EC2 購入オプション | どの購入形態が最安か？ | 「安定した負荷」→ RI/SP、「スパイク・バースト」→ Spot |
| S3 コスト | どのストレージクラスに移行すべきか？ | 「アクセス頻度が下がる」→ ライフサイクル、「不定期」→ Intelligent-Tiering |
| 右サイジング | リソースが過剰ではないか？ | 「使用率が低い」「最適化したい」→ Compute Optimizer |
| サーバーレス移行 | EC2 を使わなくていいか？ | 「散発的なリクエスト」「イベント駆動」→ Lambda/Fargate |
4軸を整理するだけで、SAA のコスト問題は4パターンに絞れる。「とにかく安くしろ」という問いに1つのサービスで答えようとせず、4軸のどれが効くかを先に判断することが正解への近道だ。
2. EC2 購入オプションの全体像
SAA で最頻出なのが EC2 の4種類の購入オプションの使い分けだ。
| 購入オプション | 割引率 | コミット | 中断リスク | 主なユースケース |
|---|---|---|---|---|
| On-Demand | 基準（割引なし） | なし | なし | 短期・不定期・予測困難 |
| Reserved Instances (RI) | 最大72% | 1年 or 3年（特定インスタンス） | なし | 定常・予測可能な長期ワークロード |
| Savings Plans (SP) | 最大66% | 1年 or 3年（$/時の支出額） | なし | 柔軟なコミット（サービス横断） |
| Spot Instance | 最大90% | なし | あり（AWS が中断する） | バッチ・CI/CD・耐障害性ワークロード |
3. Savings Plans と Reserved Instances の違い
SAA で最も混同されるのが Savings Plans（SP）と Reserved Instances（RI）の違いだ。
Savings Plans の特徴
Savings Plans は「時間あたりの支出額（$/時）」をコミットする購入形態だ。コミットした金額の範囲は割引が適用され、超過分は On-Demand 料金となる。
- Compute Savings Plans：EC2・Lambda・Fargate に横断適用。インスタンスタイプ・サイズ・リージョン・OS を問わない最大66%割引。最も柔軟。
- EC2 Instance Savings Plans：特定のインスタンスファミリー（例：m5）とリージョンをコミット。最大72%割引。RI に近い柔軟性の低さ。
- SageMaker Savings Plans：SageMaker 専用。
Reserved Instances の特徴
Reserved Instances は「特定のインスタンスタイプ・リージョン・AZ・OS・テナンシー」を1年または3年コミットする購入形態だ。
- Standard RI：特定のインスタンスタイプに固定。最大72%割引。変更は不可（Marketplace で売却は可能）。
- Convertible RI：インスタンスタイプを変更可能。最大66%割引。Standard より柔軟だが割引は低い。
- Scheduled RI：特定の時間帯（例：平日9〜18時）のみコミット。毎日・毎週・毎月の定期パターンに対応。
| 評価項目 | Savings Plans | Reserved Instances |
|---|---|---|
| コミット単位 | $/時の支出額 | 特定インスタンスタイプ・AZ・OS |
| 柔軟性 | 高（サービス横断・サイズ変更自由） | 低（Standard）〜中（Convertible） |
| 割引率 | 最大66%（Compute SP） | 最大72%（Standard RI） |
| 対象サービス | EC2 + Lambda + Fargate（Compute SP） | EC2 のみ |
| 向いているケース | インスタンスタイプ変更可能性がある場合 | 長期間同じ構成を確実に使う場合 |
4. S3 ストレージクラスとライフサイクルポリシー
S3 ストレージクラスのコスト階層
| ストレージクラス | 特徴 | ストレージ費用 | 取り出し費用 |
|---|---|---|---|
| S3 Standard | 高頻度アクセス向け。可用性99.99% | 高 | なし |
| S3 Intelligent-Tiering | アクセスパターン不明時に自動最適化 | 中（監視費用あり） | なし |
| S3 Standard-IA | 月1回未満の低頻度アクセス | 低 | あり |
| S3 One Zone-IA | 単一AZ格納。再現可能なデータ向け | より低 | あり |
| S3 Glacier Instant Retrieval | 数ミリ秒で取り出し可能なアーカイブ | 非常に低 | あり |
| S3 Glacier Flexible Retrieval | 1〜12時間で取り出し（急ぎ不要なアーカイブ） | 最安クラス | あり |
| S3 Glacier Deep Archive | 最安。取り出しに12〜48時間 | 最安 | あり（高め） |
ライフサイクルポリシーの設計原則
ライフサイクルポリシーは「経過日数」に応じてオブジェクトを上位クラスから下位クラスへ自動移行するルールだ。上から下への一方向移行のみ可能（Standard → IA → Glacier は OK、逆は不可）。
例：ログデータの自動階層移行
作成直後 → S3 Standard（0〜30日）
30日経過 → S3 Standard-IA（アクセス頻度低下）
90日経過 → S3 Glacier Flexible Retrieval（ほぼ参照なし）
365日経過 → 削除（保存義務期間終了）5. 右サイジング（Compute Optimizer / Trusted Advisor）
右サイジングとは、現在のリソースが実際のワークロードに対して過大・過小でないか調整することだ。SAA では主に2つのサービスが問われる。
AWS Compute Optimizer
機械学習を使って EC2・Lambda・EBS・ECS on Fargate の使用率データを分析し、最適なリソースサイズを推奨するサービスだ。
- 直近14日間の CloudWatch メトリクスを分析
- CPU・メモリ・ネットワーク・ディスク I/O の使用率パターンを評価
- 現在のインスタンスタイプと推奨サイズ・見込みコスト削減額を表示
- EC2 を正しいサイズに変えるだけで20〜40%のコスト削減になるケースがある
AWS Trusted Advisor
AWS のベストプラクティスに基づいて、コスト最適化・セキュリティ・耐障害性・パフォーマンス・サービス制限の5カテゴリでアドバイスを提供するサービスだ。
| 機能 | Trusted Advisor | Compute Optimizer |
|---|---|---|
| 分析対象 | EC2・RDS・EBS・ELB・S3 など広範 | EC2・Lambda・EBS・ECS on Fargate |
| 推奨の根拠 | AWS ベストプラクティスルール | 機械学習（実際の使用率パターン） |
| サポートプラン | 一部機能は Business/Enterprise 以上 | 無料（一定条件あり） |
| 得意な問題 | アイドル状態の検出・未使用RI の特定 | 最適なインスタンスタイプの提案 |
6. パターン1：EC2 購入オプション組み合わせ（RI/SP + Spot + On-Demand 3層構造）
要件のキーワード
- 「EC2 コストを最大限削減したい。ベースの負荷は一定で、スパイクが週次で発生する」
- 「耐障害性のあるバッチ処理を最安で実行したい」
- 「インスタンスタイプを将来変える可能性があるが、長期間 EC2 を使う」
アーキテクチャ：3層構造
ベースライン負荷（定常・予測可能）
→ Savings Plans / Standard RI で最大72%削減
バースト（スパイク・予測困難）
→ On-Demand で柔軟に対応
バッチ・耐障害性ジョブ（中断可能）
→ Spot Instance で最大90%削減
※ Spot Fleet / EC2 Auto Scaling + Spot で中断対策試験での正解条件
- 「ベースは安く、ピークは柔軟に」→ RI/SP + On-Demand 組み合わせ
- 「バッチ処理を最安にしたい」→ Spot Instance（中断許容が前提）
- 「インスタンスタイプを変える可能性がある」→ Savings Plans（Standard RI は不可）
7. パターン2：S3 ライフサイクルによるストレージコスト最適化
要件のキーワード
- 「ログデータが蓄積し続けており、古いデータのストレージコストを下げたい」
- 「アクセス頻度が不明な大量の画像データを保存しているが、コストを最適化したい」
- 「90日以上アクセスされていないデータを自動的にアーカイブしたい」
アーキテクチャ
新規オブジェクト（作成〜30日）
→ S3 Standard（高頻度アクセス想定）
30日経過
→ S3 Standard-IA（ライフサイクルルールで自動移行）
90日経過
→ S3 Glacier Flexible Retrieval（アーカイブ、取り出しは数時間）
365日経過
→ 削除（コンプライアンス保持期間終了後）試験での正解条件
- 「アクセスパターンが不明・予測困難」→ Intelligent-Tiering
- 「特定日数後に確実にアーカイブ」→ ライフサイクルポリシー + Glacier
- 「すぐ取り出せるアーカイブが必要（数ミリ秒）」→ Glacier Instant Retrieval
- 「再生成できるデータで1 AZ で十分」→ One Zone-IA
8. パターン3：Compute Optimizer による右サイジング
要件のキーワード
- 「EC2 の CPU 使用率が常に10%以下で推移しているが、コストを下げたい」
- 「適切なインスタンスタイプを推奨してほしい。機械学習ベースで分析してほしい」
- 「アイドル状態のインスタンスや EBS ボリュームを検出したい」
Compute Optimizer の推奨フロー
1. Compute Optimizer を有効化
→ CloudWatch メトリクス（直近14日分）を自動分析
2. 推奨レポートの確認
→ 現インスタンス vs 推奨インスタンスの性能・コスト比較
→ 「Over-provisioned」「Under-provisioned」「Optimized」の3区分
3. 推奨に基づいてインスタンスタイプを変更
→ 右サイジングで20〜40%のコスト削減Trusted Advisor の活用場面
- 「使用されていない（idle）EC2 インスタンス」→ Trusted Advisor の「コスト最適化」チェック
- 「購入した Reserved Instance の未使用率が高い」→ Trusted Advisor がアラート
- 「開放されていない EIP（未接続のElastic IP）」→ Trusted Advisor が検出
9. パターン4：サーバーレス移行（Lambda / Fargate）でインフラコストをゼロに近づける
要件のキーワード
- 「散発的なリクエスト（数時間に1回）を処理しているが、EC2 を24時間起動しているのでコストが高い」
- 「イベント駆動型のバックエンド処理をコスト効率よく実行したい」
- 「EC2 をコンテナ化しているが、クラスター管理コストも削減したい」
Lambda への移行
Lambda はリクエスト数と実行時間に対して課金される完全サーバーレスの関数実行サービスだ。
EC2 の問題点（散発的なリクエストの場合）：
→ アイドル時間も24時間分の料金が発生
Lambda なら：
→ リクエストがない時間のコストはゼロ
→ 100万リクエストまで無料枠（毎月）
→ 1リクエスト＝$0.0000002 + 100ミリ秒単位の実行時間Fargate への移行
Fargate はコンテナの CPU/メモリ使用量に対してのみ課金される、クラスター管理不要のサーバーレスコンテナサービスだ。EC2 起動タイプに比べてインフラ管理コスト（人的コスト）を削減でき、使った分だけ支払うモデルになる。
10. 要件キーワード早見表
| 要件キーワード | 正解パターン | 選んではいけない |
|---|---|---|
| 「ベースの負荷は一定・長期間使用」 | Reserved Instances / Savings Plans | On-Demand（割高） |
| 「将来インスタンスタイプを変える可能性あり」 | Savings Plans | Standard RI（変更不可） |
| 「バッチ処理・中断可能・最安で」 | Spot Instance | On-Demand（過剰コスト） |
| 「本番 Web / DB サーバーを安く」 | Savings Plans / Standard RI | Spot（中断リスク） |
| 「古いログを自動アーカイブしたい」 | S3 ライフサイクル + Glacier | S3 Standard のまま |
| 「アクセスパターン不明な大量データ」 | S3 Intelligent-Tiering | S3 Standard（コスト高） |
| 「再生成できるデータを安く保存」 | S3 One Zone-IA | S3 Standard-IA（AZ 冗長不要） |
| 「散発的なリクエストで EC2 が無駄」 | Lambda（サーバーレス化） | EC2 のまま（アイドル課金） |
| 「CPU 使用率10%のインスタンスを最適化」 | Compute Optimizer で右サイジング | そのまま放置 |
| 「アイドル状態リソース・未使用 EIP を検出」 | Trusted Advisor | Compute Optimizer（対象外） |
11. 頻出ひっかけパターンと正しい打ち手
ひっかけ1：Spot Instance を全ワークロードに適用する
誤り： 「最もコストが低いので本番の EC2 クラスター全体を Spot にすれば良い」
正解： Spot は AWS が中断できる。本番 Web サーバー・DB には使えない。バッチ・CI/CD・機械学習の学習ジョブに限定する。
ひっかけ2：S3 Standard から Glacier に直接移行できると思う
誤り： 「コストを下げるため、今すぐ S3 Standard から Glacier Deep Archive に移行する」
正解： ライフサイクルルールで日数ベースの移行は可能。ただし、S3 Standard-IA から Standard へ「戻す」ライフサイクルルールは設定できない。頻繁に取り出すデータに Glacier を使うと取り出し費用が割高になる。
ひっかけ3：Savings Plans と Reserved Instances を同一視する
誤り： 「Savings Plans も RI も同じ。どちらでも EC2 コストが下がる」
正解： Compute Savings Plans は EC2・Lambda・Fargate に横断適用可能。Standard RI は特定インスタンスタイプに固定。「将来 Lambda に移行するかもしれない」場合は Savings Plans が正解、RI は誤答になる。
ひっかけ4：Compute Optimizer は全サービスに対応すると思う
誤り： 「Compute Optimizer でコスト最適化できる。RDS・S3 のサイジングも提案してくれる」
正解： Compute Optimizer の対象は EC2・Lambda・EBS・ECS on Fargate のみ。RDS・S3 のアドバイスは Trusted Advisor や AWS Cost Explorer が担う。
12. 次のアクション チェックリスト
- EC2 の4購入オプション（On-Demand / RI / SP / Spot）の割引率・コミット・中断リスクを暗記した
- Savings Plans と Standard RI の適用範囲の違い（サービス横断 vs EC2 固定）を説明できる
- S3 のストレージクラス7種を費用・取り出し費用・アクセス頻度で整理した
- Intelligent-Tiering を選ぶ判断条件（アクセスパターン不明）を即答できる
- S3 ライフサイクルポリシーが「一方向のみ移行」であることを理解した
- Compute Optimizer と Trusted Advisor の対象範囲の違いを区別できる
- Lambda が向くワークロード（散発的・短時間）と向かないワークロード（長時間・ステートフル）を言える
- 「本番サーバーに Spot は使えない」を即答できる
- ドメイン4（コスト最適化）の試験範囲 で全体像を確認した
13. 関連記事
- SAA-C03 試験完全ガイド｜試験概要・ドメイン・合格戦略
- SAA ドメイン4：コスト最適化アーキテクチャ 完全解説
- SAA Lambda/サーバーレス設計パターン
- SAA S3 設計パターン10選
- SAA Auto Scaling / ELB 設計パターン