[EC2] キャパシティ予約の種類と SP / RI の関係について整理する

AWS運用自動化サービス「Cloud Automator」

CS課佐竹です。
花粉症ですね。

はじめに

Savings Plan(SP) はオンデマンドキャパシティ予約に「キャパシティ予約の機能」が切り出されたと過去にブログで記載しました。このオンデマンドキャパシティ予約と Savings Plan(SP) 及び Reserved Instance(RI) について整理します。

用語について

  • キャパシティ予約
    • そのInstance TypeのEC2 Instanceが起動可能であるという確保権のこと。「InsufficientInstanceCapacity」エラーが発生した場合に困ることになるが、予めキャパシティを確保しておくことでこのエラーを回避可能となる
  • オンデマンドキャパシティ予約
    • RIのように1年縛りや3年縛りではなく、必要な期間中のみオンデマンド(通常)の利用料でキャパシティが予約できる機能。最も新しいキャパシティ予約の機能
  • ゾーンリザーブドインスタンス
    • 指定したアベイラビリティーゾーン(AZ)内でキャパシティの予約を提供する。最も古いRIの形
  • リージョンリザーブドインスタンス
    • キャパシティの予約が提供されない代わりに、どちらのAZにも割引効果が発揮されるようになった新しいRIのScope

これらの詳細な比較は「キャパシティーの予約、リザーブドインスタンス、および Savings Plans の違い」に詳しく記載がありますが、そのエッセンスを利用し以下に独自の表としてまとめてみました。

比較表

項目 [A]オンデマンドキャパシティ予約 [B]ゾーン RI [C]リージョン RI [D]Savings Plans
1.キャパシティ予約の機能提供 × ×
 1-1.特定のEC2 Instanceへのキャパシティ提供 × × ×
 1-2.EC2 Instance無停止でのキャパシティ提供 × ×
2.オンデマンド利用料の割引 ×
3.オンデマンドキャパシティ予約への割引の適用 ×

これらの特徴を文章でまとめてみます。

  • [A]オンデマンドキャパシティ予約:狙った EC2 Instance へのキャパシティ適用が可能。割引はなし。キャパシティ予約が割り当てられずに既に起動している「None」設定の EC2 Instance にキャパシティを割り当てるには、一度 EC2 Instance を停止する必要がある。「Open」設定の場合はRIと同様の動作となる(デフォルトOpen)
  • [B]ゾーン RI:対象となる EC2 Instance は狙えないが EC2 Instance の停止を経ずに特定の  Instance Type をAZ単位で予約できる(ただし、狙った Instance Type の EC2 Instance がそのAZ内で1台しかない場合など、AZ単位で一意に特定可能な場合は除く)。オンデマンドキャパシティ予約への割引の適用が無い点は注意
  • [C]リージョン RI:キャパシティ予約はなく純粋な値引きとして動作する
  • [D]Savings Plans:同様にキャパシティ予約はなく純粋な値引きとして動作する

オンデマンドキャパシティ予約への割引の適用?

「オンデマンドキャパシティ予約への割引の適用」とは、SPもしくはRIのコスト削減効果が「オンデマンドキャパシティ予約」にも有効かどうかを示します。ゾーンRIでは「オンデマンドキャパシティ予約への割引の適用」がない(×)と一覧表に記載しました。これは以下のドキュメントから一部抜粋してご紹介します。

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/capacity-reservations-pricing-biling.html
Savings Plans とリージョンリザーブドインスタンスの請求割引がキャパシティーの予約に適用されます。【中略】
ゾーンリザーブドインスタンスの請求割引はキャパシティーの予約には適用されません

Unused Capacity Reservation

確保したものの使用されなかったオンデマンドキャパシティ予約は「Unused Capacity Reservation」とドキュメントに表記されておりますが、実際に東京リージョンではm4.largeの場合に「APN1-UnusedBox:m4.large」と料金明細に表示されます。ドキュメントには「Detailed Billing Reports」に記載があります。この利用料は(未使用であったとしても)オンデマンド利用料になりますので、RIもしくはSPにて割引の対象になります。「3.オンデマンドキャパシティ予約への割引の適用」と記載があるのはこの点も含んで記載しておりますためご留意ください。
※実際に Savings Plan の割引適用対象になったことは社内環境で確認済です

シナリオ別:利用料とキャパシティ予約

ここから先は、それぞれの機能を掛け合わせて使用した場合について考えてみましょう。

シナリオ1:[A]オンデマンドキャパシティ予約 のみを使用

利用料はオンデマンドの利用料のみとして請求され、キャパシティ予約は狙ったEC2 Instanceにも適用することができます(※Targeted or Openで動作は異なります)。

シナリオ2:[B]ゾーン RI のみを使用

利用料はRIが適用された割引後の額で請求され、キャパシティ予約は狙ったAZのみで確保されます。

シナリオ3:[C]リージョン RI のみを使用

利用料はRIが適用された割引後の額で請求され、キャパシティ予約は実施されません。

シナリオ4:[D]Savings Plans のみを使用

利用料はSPが適用された割引後の額で請求され、キャパシティ予約は実施されません。

シナリオ5:[A]×[D] を合わせて使用【おすすめ】

利用料はSPが適用された割引後の額で請求され、キャパシティ予約は狙ったEC2 Instanceにも適用することができます。この組み合わせは非常に効果的であり、よく機能すると考えております。

シナリオ6:[A]×[C] を合わせて使用

利用料はRIが適用された割引後の額で請求され、キャパシティ予約は狙ったEC2 Instanceにも適用することができます。この組み合わせはシナリオ5とおおよそ同等です。

シナリオ7:[A]×[B] を合わせて使用

混ぜるな危険、という組み合わせになります。利用料は[A]の分がオンデマンドの利用料のみとして請求され、キャパシティ予約は狙ったEC2 Instanceにも適用することができます。またゾーンリザーブドインスタンスの請求割引はキャパシティーの予約には適用されませんため、オンデマンドの利用料とRIの利用料が同時に発生してしまう状況になります。つまり、定価と値引き後の額を二重に支払っている状況です。この状況になった場合は、ゾーンRIをModifyし、リージョンRIに交換してください。それにより「シナリオ6」に移行できます。

シナリオ8:[A]×[C]×[D] を合わせて使用

SPとRIではRIが先に適用されるという仕様となっているため、利用料はRIが適用された割引後の額で請求され、キャパシティ予約は狙ったEC2 Instanceに適用することができます。SPは他に適用されるリソースがあればそちらに自動的に適用されますが、対象リソースが無い場合SPの利用料はそのまま請求されます。

シナリオ9:[A]×[B]×[D] を合わせて使用

このシナリオでも「オンデマンドの利用料とRIの利用料が同時に発生してしまう状況になります」が、[D]が[A]をカバーするため「SPが適用された割引後の額とRIの利用料が同時に発生する」という少しはマシな状況になります。BをCに変えることで「シナリオ8」に移行できます。

まとめ

最終的な推奨シナリオとしては「Savings Plan と Reserved Instance の比較」でも記載している「シナリオ5」の [A]オンデマンドキャパシティ予約×[D]Savings Plans となります。ですが、オンデマンドキャパシティ予約への切り替えが難しい等の背景があり、シナリオ2の [B]ゾーン RI のみを使用 も検討されるケースもまだありそうです。

キャパシティ予約1つとっても、なかなか理解が難しいですが、このブログで少しでも理解が深まると幸いです。
ではまたお会いしましょう。

AWS運用自動化サービス「Cloud Automator」