AWS SAA(Solutions Architect - Associate)対策
RIとSavings Plans
このレッスンでできるようになること。長期に動かし続けるワークロードに対して、リザーブドインスタンス (RI) と Savings Plans のどちらをコミット割引の答えにするかを、要件文だけで判断できるようになります。
要件の文から入る
ある会社が、24 時間 365 日止めない基幹アプリを EC2 で 3 年動かす計画を立てました。ただし来年には一部を Fargate へ、さらに一部を Lambda へ寄せる方針が決まっています。移行の時期も、そのときに使うインスタンスタイプも、まだ確定していません。稼働量そのものはほぼ変わりません。オンデマンドより安く抑えたいという要件です。何にコミットしますか。
答えは Compute Savings Plans です。ここで効いている要件語は「インスタンスタイプが確定していない」と「Fargate と Lambda も含めたい」の 2 つです。この 2 つが出た瞬間に、EC2 のインスタンスタイプを指定して買う RI は候補から外れます。
何にコミットするのかが違う
どちらも「一定期間、一定量を使い続けます」と約束して、その代わりにオンデマンドより低い単価を得る仕組みです。違いは約束の単位にあります。
| リザーブドインスタンス (RI) | Compute Savings Plans | EC2 Instance Savings Plans | |
|---|---|---|---|
| 約束する対象 | インスタンスの構成 (タイプ・OS など) | 一定の利用量 (時間あたりの支出) | 特定リージョンの特定インスタンスファミリー |
| インスタンスタイプの変更 | 原則しばられる | 自由 | ファミリー内なら自由 |
| リージョンをまたぐ | しばられる | またげる | またげない |
| Fargate に効くか | 効かない | 効く | 効かない |
| Lambda に効くか | 効かない | 効く | 効かない |
| 割引の深さ | 深い側 | 3 つの中では浅い側 | 深い側 |
| キャパシティ予約 | ゾーン指定の RI なら確保できる | 確保しない | 確保しない |
表の最後の行は見落とされがちです。Savings Plans はキャパシティを予約しません。 「特定の AZ でインスタンスの起動枠を必ず確保したい」という要件が文中にあるなら、答えは Savings Plans ではなく、ゾーン指定のリザーブドインスタンス、またはオンデマンドキャパシティ予約です。ここは割引の話と可用性の話が交差する場所なので、本番でよく狙われます。
選び方の順番
迷ったら次の順で読みます。
- そもそも長期に動かし続けるか。止まったり消えたりしてよいなら、コミット割引ではなくスポットの話です
- Fargate や Lambda を含めたいか。含めたいなら Compute Savings Plans しかありません
- インスタンスタイプやリージョンが動くか。動くなら Compute Savings Plans です
- 構成が完全に固まっていて動かないか。固まっているなら RI か EC2 Instance Savings Plans で、より深い割引を取りに行きます
- 起動枠そのものを確保したいか。確保したいならゾーン指定の RI かキャパシティ予約です
RDS や ElastiCache、Redshift、OpenSearch のようなデータベース側のコミット割引は RI 系だけで、Savings Plans は使えません。「RDS を 3 年動かすので安くしたい」と書かれていたら、答えはリザーブドインスタンスです。ここも定番の分岐です。
要件語から構成への対応表
| 要件文の言い回し | 選ぶもの |
|---|---|
| 3 年間ずっと稼働、構成は変えない | リザーブドインスタンス、または EC2 Instance Savings Plans |
| インスタンスタイプを今後見直す予定がある | Compute Savings Plans |
| Fargate や Lambda にも割引を効かせたい | Compute Savings Plans |
| リージョンをまたいで移す可能性がある | Compute Savings Plans |
| 特定 AZ で起動枠を必ず確保したい | ゾーン指定の RI、またはオンデマンドキャパシティ予約 |
| RDS や ElastiCache を長期に動かす | それぞれのリザーブドインスタンス / リザーブドノード |
| 中断されても構わないバッチ | スポットインスタンス (コミット割引の話ではない) |
よくある引っ掛け
1 つめは、割引が深いほうを無条件に正解にしてしまうものです。RI のほうが割引は深い側ですが、来年タイプを変える予定がある構成に RI を当てると、変えた瞬間に割引が効かなくなります。要件文に将来の変更が書かれていたら、深さより柔軟さが正解です。
2 つめは、Savings Plans を買えば起動枠まで確保されると読んでしまうものです。確保されるのは価格であって、容量ではありません。「イベント当日に必ず起動できること」のような文が混ざっていたら、割引の商品では答えになりません。
まとめ
- RI はインスタンスの構成に、Savings Plans は利用量にコミットします
- Fargate と Lambda まで含めたいなら Compute Savings Plans の一択です
- タイプやリージョンが動くなら柔軟な Compute Savings Plans、固まっているなら深い RI 側です
- Savings Plans はキャパシティを予約しません。起動枠の確保は別の仕組みです
- RDS や ElastiCache などのコミット割引は RI 系だけです
復習ミニクイズ
ある企業が EC2 上の基幹アプリを 3 年間止めずに稼働させます。稼働量はほぼ一定ですが、来年度に一部のコンポーネントを Fargate と Lambda へ移す計画があり、その際に使うインスタンスタイプもリージョンも確定していません。オンデマンドより低い単価にしたいという要件を、最も適切に満たすのはどれですか。