導入
「動けばいい」設計と「動き続けて、かつ無駄がない」設計は違います。SAAはコストも設計の一部として問います。第1章のWell-Architected「コスト最適化」の柱を、具体的な打ち手に分解します。
説明
コスト最適化には、繰り返し出題される 4つの原則 があります。
| 原則 | やること | 主なサービス／機能 |
|---|---|---|
| 適正なサイズ（Right Sizing） | 使っていない・過剰なリソースを見直す | Compute Optimizer、CloudWatch使用率監視 |
| 購入オプションの活用 | 使い方に合った課金モデルを選ぶ | RI（リザーブドインスタンス）、Savings Plans、スポットインスタンス |
| 需要と供給を合わせる | 使う分だけ確保し、余らせない | Auto Scaling、サーバーレス |
| マネージド／サーバーレスの活用 | 運用の人的コストを削る | Lambda、Fargate、RDS、S3 |
購入オプションはSAA頻出です。使い方で使い分けます。
| オプション | 割引率の目安 | 向いている用途 |
|---|---|---|
| オンデマンド | 割引なし | 短期・予測不能な負荷 |
| リザーブドインスタンス（RI） | 最大72% | 1〜3年動かし続ける安定稼働ワークロード |
| Savings Plans | 最大72% | RIより柔軟（インスタンスタイプ変更OK）、Compute/EC2 Instance Savings Plansがある |
| スポットインスタンス | 最大90% | 中断されても困らないバッチ処理、CI、ビッグデータ処理 |
flowchart TD
Q["ワークロードの性質は？"] --> A["中断されても<br/>問題ない"]
Q --> B["1〜3年<br/>動かし続ける"]
Q --> C["短期・予測不能"]
A --> SPOT["スポットインスタンス<br/>最大90%割引"]
B --> RI["RI / Savings Plans<br/>最大72%割引"]
C --> OD["オンデマンド"]
ストレージも「アクセス頻度に応じて」最適化します（第6章参照）。アクセスの少ないデータをS3標準に置き続けるのはコストの無駄で、S3 Lifecycleで自動的にIA・Glacierへ移すのがSAA的な正解です。
具体例
動画配信スタートアップの月額請求を、4つの原則で削っていきます。
- 適正なサイズ … Compute Optimizerが「本番のEC2はCPU5%、2段階小さくできる」と提案。→ 縮小して性能そのまま料金減。
- 購入オプション … 24時間動く配信サーバーはRI/Savings Plans（最大72%引き）。深夜に走る動画エンコードの大量バッチは「中断されても再実行すればよい」のでスポット（最大90%引き）。
- 需要と供給を合わせる … 昼夜でアクセス差が大きいWeb層はAuto Scalingで台数を自動増減、夜間の無駄をカット。
- マネージド／サーバーレス … サムネ生成をEC2常駐からLambdaへ。使った分だけ課金で待機コストゼロ、運用の人件費も削減。
古い動画はS3 LifecycleでIA→Glacierへ自動降格。SAAの鉄則は「中断されても問題ない＝スポット」「常時稼働・予測可能＝RI/Savings Plans」「スパイクする・読めない＝Auto Scaling＋オンデマンド/サーバーレス」の3択を機械的に振り分けること。特にエンコードバッチのような「中断可」キーワードはスポットのサインです。
読んでみよう
「中断されても問題ない」というキーワードを見たら、ほぼ確実にスポットインスタンスが正解です。逆に「常時稼働・予測可能」ならRI/Savings Plans、「使うかどうか分からない・スパイクする」ならAuto Scaling＋オンデマンド／サーバーレス、と3択を機械的に振り分けられるようにしておきましょう。