RI vs Savings Plans — AWS コミットメント割引の選択基準

インフラ AWS コスト
読了 6分

このシリーズで EC2、RDS、コンテナ、ストレージを選ぶ基準を扱うたび、最後に同じ文が出てきました。「長期実行が確定なら、コミットメント割引を検討します」です。今回はそのコミットメントを選ぶ基準です。結論を先に書くと、EC2 中心の新規コミットは Savings Plans がデフォルトで、RI(リザーブドインスタンス)がいまも必要な場面は、RDS のような EC2 以外のサービスとキャパシティ予約です。 割引率が同じなら、柔軟なほうを選ぶのが原則です。料金と割引率は us-east-1、オンデマンド比の基準です。

ひと目でわかる比較 #

区分Standard RIConvertible RIEC2 Instance SPCompute SP
最大割引率 (3 年全額前払い)約 72%約 66%約 72%約 66%
適用範囲インスタンスファミリー・リージョン交換で変更可能ファミリー・リージョン固定EC2 全体 + Fargate + Lambda
ファミリー変更不可交換手続きで可能不可自動適用
サイズ・OS 変更条件付き (リージョン・Linux など)交換手続きで可能自動適用自動適用
再販Marketplace で可能不可不可不可

構造の違い — 属性を買うのか、金額を買うのか #

RI はインスタンスの属性を買うコミットです。「m5.xlarge、us-east-1、Linux を 1 年」のように属性の組み合わせを指定し、実行中のインスタンスがその属性と一致すれば割引が適用されます。属性がずれると割引は遊んだままオンデマンド料金がかかります。リージョン単位の Linux RI は同じファミリー内ならサイズが違っても柔軟に適用されますが、ファミリーをまたぐ変更は Standard RI では不可能で、Convertible RI の交換手続きを踏む必要があります。

Savings Plans は時間あたりの金額を買うコミットです。「時間あたり $10 を 1 年」のように約束すると、その金額までの使用量に割引単価が適用され、超過分だけがオンデマンドになります。何に適用するかは、割引効果の大きい順に AWS が自動で割り当てます。インスタンスを m5 から c7g に替えても、EC2 を減らして Fargate を増やしても(Compute SP の場合)、コミットは消化され続けます。EC2 インスタンスファミリーを替えながら最適化するチームなら、この違いが決定的です。

管理の負担も構造どおりに分かれます。RI は「どの属性を何個買って、いま何個がマッチしているか」を追いかける必要がありますが、SP は時間あたりのコミット額と実使用のカバレッジだけを見れば済みます。

割引率 — 最大値ではなく、同じ条件同士で比べます #

数字だけ見ると、Standard RI と EC2 Instance SP が最大約 72% で同じ、Convertible RI と Compute SP が約 66% で同じです。ここから出てくる実務上の結論はシンプルです。

  • EC2 Instance SP vs Standard RI: 割引率が実質同じなのに、SP のほうがサイズ・OS の自動適用で柔軟です。キャパシティ予約と再販(後述します)が不要なら SP が優先です。
  • Compute SP vs Convertible RI: こちらも割引率はほぼ同じですが、Convertible RI の交換は手動の手続きで、Compute SP の適用は自動です。新規なら Compute SP です。
  • 最大値は 3 年全額前払いの場合です。1 年・前払いなしなら割引率は下がりますが(Compute SP でおおよそ 20〜30% 台)、負担も小さくなります。前払いの有無は割引率よりキャッシュフローの問題なので、財務側と決める項目です。

RI が残る場面 — SP がカバーできないところ #

SP の適用範囲は EC2、Fargate、Lambda です(SageMaker は別枠の SageMaker Savings Plans)。裏返すと、それ以外のサービスはいまも RI(リザーブド)の仕組みだということです。

  • RDS リザーブドインスタンス: RDS インスタンスクラスと Aurora で扱ったデータベースは SP の対象外です。安定して稼働するプロダクション DB は RDS RI が唯一のコミット手段で、削減幅も大きいです。
  • ElastiCache、OpenSearch、Redshift、DynamoDB: それぞれリザーブドノード・リザーブドキャパシティの仕組みを別に持っています。名前は違っても構造は RI と同じです。
  • キャパシティ予約: SP とリージョン単位の RI は料金割引にすぎず、キャパシティを保証しません。特定の AZ でインスタンスを必ず起動できる必要があるなら、ゾーン単位の RI かオンデマンドキャパシティ予約(ODCR)で解決すべきで、ODCR は Compute SP と組み合わせられます。
  • 再販: コミットを途中で手放せるのは Standard RI(Marketplace)だけです。SP はキャンセルも譲渡もできません。

コミット額 — 請求書の安定した下限までにします #

コミットの唯一のリスクは過剰コミットです。SP は使用量がコミット額に届かなくても時間あたりのコミット額が全額請求されるため、使わなかったコミットはそのまま損失です。額の決め方は次の順序が安全です。

  1. ベースラインを測ります: Cost Explorer の直近数か月の使用量から、夜間・週末でも維持される常時使用分を見つけます。これがコミットできる下限です。
  2. 下限の一部だけを先にコミットします: Cost Explorer の SP 推奨が計算してくれる推奨額から出発しつつ、最初のコミットは 1 年・前払いなしで保守的に取るほうが安全です。
  3. レイヤーで積み上げます: コミットは何枚も重ねられます。四半期ごとにカバレッジと使用率の指標を見て、不足分だけ追加購入する方式のほうが、一度に大きくコミットするよりリスクが小さくなります。
  4. 減る予定の使用量は入れません: 移行予定のワークロードや、Lambda vs Fargate で扱った移動計画のあるサービスはコミットの計算から外します。コミットの前に常時点検リストで無駄を消しておくのも同じ理由です。無駄をコミットしても、割引価格で無駄遣いするだけです。

選択の手順 #

  1. サービスの範囲から確認します: EC2・Fargate・Lambda なら SP、RDS をはじめとするデータベース・分析系なら、そのサービスの RI(リザーブド)です。
  2. ファミリーへの確信度で SP の種類を選びます: ファミリー・リージョンが数年間固定だと確信できるなら EC2 Instance SP(最大 72%)、変わる可能性があるなら Compute SP(最大 66%)です。確信がないのに 6 ポイントを惜しんで固定のコミットを取るのが、典型的な後悔のパターンです。
  3. キャパシティ保証の要件を確認します: 特定 AZ のキャパシティが必須なら、ゾーン単位の RI か ODCR を別途計画します。
  4. 額は安定した下限以下にします: 常時使用分だけをコミットし、変動分はオンデマンドのまま残します。
  5. 四半期ごとに見直します: カバレッジ・使用率の指標を見てレイヤーを追加します。コミットは一度きりの決定ではなく、繰り返しの運用です。

まとめ #

  • EC2 中心の新規コミットは Savings Plans がデフォルトです。同じ割引率なら、自動で適用されるほうが勝ちます。
  • ファミリーまで確信できるなら EC2 Instance SP(最大 72%)、そうでなければ Compute SP(最大 66%)です。6 ポイントの差は柔軟性の価格です。
  • RDS、ElastiCache、OpenSearch、Redshift は SP の対象外で、それぞれのリザーブドの仕組みを使います。プロダクション DB のコミットはいまも RI の領域です。
  • SP とリージョン RI は料金割引にすぎません。キャパシティ保証はゾーン単位の RI か ODCR で別に解決します。
  • コミット額は請求書の安定した下限までにして、何枚かに分けてレイヤーで積みます。使わなかったコミットは損失で、無駄をコミットしても割引された無駄遣いにしかなりません。
X