導入
「動けばいい」設計と「動き続けて、かつ無駄がない」設計は違います。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的な正解です。
読んでみよう
「中断されても問題ない」というキーワードを見たら、ほぼ確実にスポットインスタンスが正解です。逆に「常時稼働・予測可能」ならRI/Savings Plans、「使うかどうか分からない・スパイクする」ならAuto Scaling＋オンデマンド／サーバーレス、と3択を機械的に振り分けられるようにしておきましょう。