Azure・AWS・GCP・AlibabaCloudのリザーブドインスタンスサービス比較

リザーブドインスタンスとは

Azureでは仮想マシン、AWSでは EC2、GCPでは Compute Engine、AlibabaCloudでは ECSといったように、各社名称は違いますが IaaS型仮想マシンサービスを提供しています。
では仮想マシンサービス、そしてリザーブドインスタンスとは一体どのようなものなのでしょうか。 ホテルを例に説明してみようと思います。

仮想マシンサービスとキャパシティ

ホテルには、シングルやツイン、スイートなど客室のグレードが複数用意されており、当然のことですが、例えばシングル 40室、スイート 2室などのように物理的なキャパシティがあります。
満室となってしまった場合には、それ以上の宿泊客は断らなければいけません。
聞くところによると、設備不良などがあった場合の緊急措置として部屋変更可能なように、完全な満室にはしないという方針を取っているホテルも多いそうです。

実は仮想マシンサービスも非常によく似た仕組みになっています。
例えば AWS EC2の場合 M5(汎用)、R5(メモリ偏重)、C5(CPU偏重)、T3(バースト)などのラインナップごとに、実際に稼働している物理ハードウェアとしてのサーバが存在しています。
AWSの場合だと、Dedicated Instanceサービスを利用することで 1台の物理ハードウェアに各サイズの仮想マシンがどの程度立ち上げ可能かを、利用者がある程度推測可能だったりもしますが、本稿では蛇足になってしまいますのでまたの機会にお話ししましょう。

ホテルと同様に、設備不良時(物理 H/W障害時)の緊急避難用に実は完全な満室にはしないなど、実際のところはそういった仕組みが存在しているようですが、今回は便宜上下図のように完全な満室として表現してみました。
各フロアが物理ハードウェア実体であると考えてください。

さて、この状況で新たに T3の EC2インスタンスを立ち上げようとすると何が起きるでしょうか？
実際に遭遇したことがある方、割と多くいらっしゃるかもしれませんが、当然立ち上がりません。
具体的にAWS EC2の場合「InsufficientInstanceCapacity」というエラーが発生します。
参考: AWS社ユーザーガイド
引用可能な公式ユーザーガイドがあったので、AWS社を例にしましたが、当然この問題は、どのパブリッククラウドでも起こり得ます。

キャパシティ不足をどう回避するか

では、この問題をどのように回避すればよいでしょうか。
根本的にはパブリッククラウド事業者側のリソース増強を期待したいところですが、サービスやシステム稼働を守るための自衛策も必要です。
ここでは3つの選択肢を検討します。

1つ目の選択肢は「別のインスタンスタイプを利用する」ことです。
例示したケースだと、T3以外のインスタンスタイプにはどうやら空きがあるようですので、一時的に M5インスタンスタイプなどを変更することでキャパシティ不足を回避することが出来そうです。

一方手動で起動オペレーションをしているケースではこうした判断が可能ですが、スケジュール起動のような仕組みを導入している場合は、キャパシティ不足に対するフェールセーフ機構としてインスタンスタイプ変更を組み込んでおく必要があります。
また、例示したケースだと M5インスタンスタイプには空きがありましたが、第二候補とするインスタンスタイプも同様に起動できないケースを考慮する必要があるでしょう。
さらに、インスタンスタイプを変更することで、従量課金額が変更されることを許容する必要も出てきます。

2つ目の選択肢は「利用するリージョンやアベイラビリティゾーンを変更する」ことです。
キャパシティ不足の根本原因は物理リソースの枯渇に由来するものなので、物理的に別環境が用意されている別リージョンや別アベイラビリティゾーンを利用することにより、この問題を回避できる可能性があります。

ただ、別リージョンや別アベイラビリティゾーンで同じように物理リソース枯渇が起きていない保証はありませんし、仮に利用可能だったとしても別リージョンや別アベイラビリティゾーンを利用可能なよう、システムがあらかじめ設計されていなければいけません。
仮に別リージョンを利用する場合には、レイテンシの増加など別な課題にぶつかることになるでしょう。

3つ目の選択肢は「リザーブドインスタンスを利用する」事です。
リザーブドインスタンスのメリットについては各所で「コスト最適化」という側面が押し出されていますが、実はキャパシティ不足の影響を受けにくくするというメリットもあります。

ホテルでは宿泊予約をすることが一般的ですが、当然予約が入っている客室は予約者のためにキープされていて、予約の無い宿泊客には割り当てられません。
リザーブドインスタンスも同様です。
オンデマンド利用(予約無しにインスタンスを立ち上げて利用する方法をリザーブドインスタンスと区別するため、本稿では便宜上「オンデマンド利用」と記述します)で起動可能なインスタンスのキャパシティは、キャパシティ全体からオンデマンド利用中のインスタンスとリザーブドインスタンスを差し引いたものとなります。

図のように T3インスタンスタイプ全体のキャパシティを6としたとき、オンデマンド利用中のインスタンス4とリザーブドインスタンス2を差し引くと、キャパシティ6に到達しますので T3インスタンスタイプはキャパシティ上限(満室)になります。
この状況から新たにオンデマンド利用することは出来ませんが、リザーブドインスタンスの購入者はリソースが確保されているので、インスタンスを立ち上げることが可能となります。

一方、オンデマンド利用と比較して、予約のための事前手続きが必要であったり、インスタンスタイプ変更に制限があったりとリザーブドインスタンスならではの考慮事項があるので注意が必要です。
これはホテル利用でも、予約時の事前手続きや、予約後の部屋タイプ変更には所定の手続きが必要なことと似ているかもしれません。

次章ではリザーブドインスタンス利用にあたって確認するべきポイントを解説していきます。

リザーブドインスタンスの利用のポイント

リザーブドインスタンスの利用に当たり、確認すべきポイントは主に以下の6つです。

• キャパシティ予約
• ディスカウント率と明確な価格
• 支払いの柔軟性
• インスタンス変更の柔軟性
• 利用手続きと購入後の管理
• 従量課金制のメリット放棄 [評価外]
• 
  本章では、これらのポイントを少し掘り下げた解説と、次章「各社のリザーブドインスタンス比較」についての採点基準を説明いたします。

キャパシティ予約

前章で解説した通り、キャパシティが予約されオンデマンド利用と比較して、必要なときに起動出来ない可能性を小さくできる事は大きなメリットです。
本来は「必ず起動できる」と表現したい所なのですが、大規模な地域障害など、パブリッククラウド上で大規模障害が発生した場合を考慮すると、リザーブドインスタンスといえども「必ず起動できる」という表現が出来ません。
こうしたリスクを小さくするためには、「1.2 キャパシティ不足をどう回避するか」2つ目の選択肢で提示した通り、「利用するリージョンやアベイラビリティゾーンを変更する」ことが可能なようにシステム全体を設計する必要があります。
次章「各社のリザーブドインスタンス比較」では、キャパシティ予約の観点で以下を加点対象とします。
・サービス規定上キャパシティ予約に対する明確な言及がある　2点
・キャパシティ予約として1年未満のコミットを選択可能である　1点

ディスカウント率と明確な価格

オンデマンド利用比で、単位時間あたり 30%～60%程度利用料がディスカウントされる点も大きな魅力です。
パブリッククラウド利用料の適正化を考えるとき、リザーブドインスタンス購入は必ず検討されていることでしょう。
多くの場合は長期利用をあらかじめコミットし、一括前払いを行うことで最大限のディスカウントを得られるようにサービスが設計されています。
次章「各社のリザーブドインスタンス比較」では、ディスカウント率と明確な価格という観点で以下を加点対象とします。
・無料OS汎用インスタンスの割引率が40%以上ある　2点
・ディスカウント額を明確に確認可能である　1点

支払いの柔軟性

「[メリット②] 従量課金比でのディスカウント」で解説した通り、最大限のディスカウントを得るためには、1年間もしくは3年間の利用をコミットし、料金を一括前払いで支払う必要がある点に注意が必要です。
事業者によっては一括前払い以外に、一部前払いや月払いを柔軟に選択可能だったり、返金対応にも応じていただけるようです。
次章「各社のリザーブドインスタンス比較」では、支払いの柔軟性という観点で以下を加点対象とします。
・返金対応が可能　2点
・前払い無しでの利用を選択可能　1点

インスタンス変更の柔軟性

リザーブドインスタンスはその性質上、インスタンスタイプやインスタンスサイズの変更に関わる制約が付帯します。
稼働中にパフォーマンスが不足、もしくは過剰であると判断した場合、オンプレミス比で高いアジリティ要求に応えられる事がパブリッククラウドの大きな魅力ですが、インスタンスタイプを指定して購入するリザーブドインスタンスはこの強みを打ち消してしまいます。
一方、最近ではこのデメリットを払拭するために、インスタンスタイプ変更ができるサービスも登場しているようです。
次章「各社のリザーブドインスタンス比較」では、インスタンス変更の柔軟性という観点で以下を加点対象とします。
・インスタンス変更可能なオプションが用意されている　2点
・同一インスタンスタイプ垂直スケール時に割引適用される　1点

利用手続きと購入後の管理

当然ですがリザーブドインスタンス利用のためには、購入手続きが必要です。
オンデマンド利用と比べて手続きが一段階増えることや、リザーブドインスタンス購入後に適正に割り当たっているかという観点で、購入済みリザーブドインスタンスを管理する必要も生じます。
利用手続きの煩雑さや、購入後の管理手段が提供されているかは利用者にとって大きなポイントです。
次章「各社のリザーブドインスタンス比較」では、利用手続きと購入後の管理という観点で以下を加点対象とします。
・リザーブドインスタンス購入から利用までの手続きが簡単　2点
　(Web UIで操作が完結し、個別インスタンスへの適用が不要なこと)
・購入済みリザーブドインスタンスを管理する仕組みがある　1点

従量課金制のメリット放棄 [評価外]

実はリザーブドインスタンスを利用すると「使った分だけ課金」という従量課金制のメリットを放棄してしまうことを考慮しなければいけません。
これはリザーブドインスタンスの性質上仕方のないことですので評価項目からは外しましたが、例えばコスト最適化のみが目的であれば従量課金制のまま、稼働時間を削減するという手段も事前に比較検討することをお勧めします。

各社のリザーブドインスタンス比較

結論として、2020年8月12日時点で各社サービスを比較した結果は以下表の通りです。
(※Alibaba Cloudについては国際サイト契約です)

(点数が高いほど高評価)

評価ポイントが十分網羅的ではない事や、リザーブドインスタンス自体のディスカウント率の比較よりも同一スペックでの総支払額で比較するべきなど、さまざまなご意見あるかと思います。 あくまでも、一つの目安としてご覧いただければ幸いです。

参考までですが、各社ごとの評価詳細を掲載しますのでご覧ください。

Azureの場合

キャパシティ予約

・キャパシティ予約については、公式ドキュメント上で「デプロイ用のデータ センターの容量が優先されます」との表記にとどまっており、明確なキャパシティ予約では無いようです。この表記について日本マイクロソフト社へ確認した所、キャパシティの予約ではないものの表記の通りオンデマンド比で高優先度の割当制御が入るようなので、1点を加点します。(1点)
・公式ドキュメント上で「1 年間または 3 年間。 また、HBv2 VM に対してのみ使用できる 5 年間の期間」とある通り、最短コミット期間が1年間以上です。(0点)
（参考）公式ドキュメント

ディスカウント率と明確な価格

・東日本リージョン汎用 D2s v4(CentOS)インスタンス 3年全額前払い利用時の割引率は 62%でした。また、Azure独自のディスカウントとしてソフトウェア アシュアランス付きのWindows Serverライセンスを保有している場合に Azureハイブリッド特典を受ける事でよりディスカウント率を高められる可能性があります。0.5点を加点します。(2.5点)
（参考）Azureハイブリッド特典
・料金計算ツールでリザーブドインスタンスの利用料金と割引額が確認可能です。(1点)
（参考）料金計算ツール

支払いの柔軟性

・公式ドキュメント上に「予約が不要になった場合は、12 か月のローリング ウィンドウで最大 $50,000 USD までの払い戻しができます」との表記があり返金が可能です。(2点)
（参考）公式ドキュメント
※CSP契約の場合はこの限りではありません。必ず事前に提供事業者にお問い合わせください。
・公式ドキュメント上の利用料金表の通り、全額前払い,前払い無しを選択可能。また、前払い無しの場合も金額に変更がないため、さらに0.5点を加点します。(1.5点)
（参考）公式ドキュメント

インスタンス変更の柔軟性

・公式ドキュメントの通り、セルフサービスによるインスタンスタイプ交換が可能です。(2点)
（参考）公式ドキュメント
・垂直方向のスケールに対しては自動適用とはならないものの、セルフサービスによるインスタンスタイプ交換で代替可能です。(1点)

利用手続きと購入後の管理

・リザーブドインスタンス購入はAzure Portalで操作が完結し、個別インスタンスへの適用は不要です。(2点)
※CSP契約の場合はこの限りではありません。必ず事前に提供事業者にお問い合わせください。
・公式ドキュメントの通りAzureポータル上から取得可能な使用状況ファイルで参照することが可能ですが、CSVファイルベースで確認が必要であり、Azureポータルでは完結していないため 0.5点とします。(0.5点)
（参考）公式ドキュメント

AWSの場合

キャパシティ予約

・キャパシティ予約については、公式ドキュメント上で「特定のアベイラビリティーゾーンで使用するキャパシティーを予約できます」と名言されています。(2点)
（参考）公式ドキュメント
・厳密にはリザーブドインスタンスでは無いのですが、AWSの場合オンデマンドキャパシティー予約というサービスがあり、利用期間のコミットメント無しにキャパシティ予約が可能です。(1点)
（参考）オンデマンドキャパシティー予約

ディスカウント率と明確な価格

・東京リージョン汎用 m5.large(Linux)インスタンス 3年全額前払い利用時の割引率は 62%でした。(2点)
・公式ドキュメント上にリザーブドインスタンスの利用料金が掲載されています。(1点)
（参考）公式ドキュメント

支払いの柔軟性

・公式ドキュメント上に「リザーブドインスタンス購入料金は払い戻しできませんのでご了承ください。」との表記あり。但し、リザーブドインスタンスマーケットプレイスを通じて利用者間で売買可能な仕組みが整備されており、売却を通じて不要になったインスタンスの購入額を補填できる可能性があります。1点を加点します。(1点)
（参考）公式ドキュメント
・公式ドキュメント上の利用料金表の通り、全額前払い,一部前払い,前払い無しを選択可能です。(1点)
（参考）公式ドキュメント

インスタンス変更の柔軟性

・公式ドキュメントの通り、コンバーティブルRIの利用により購入後のインスタンスタイプ変更が可能です。(2点)
・公式ドキュメントの通り、「正規化係数によって決定されたインスタンスサイズの柔軟性」のもと、同じインスタンスファミリーの垂直スケールであれば割引適用となります。(1点)
（参考）公式ドキュメント

利用手続きと購入後の管理

・リザーブドインスタンス購入はマネジメントコンソール上で操作が完結し、個別インスタンスへの適用は不要です。また利用料のディスカウントのみを目的とする場合、SavingPlansではアカウント全体を一括で手続き可能な点や、キャパシティ予約のみを目的とする場合、スケジュールされたリザーブドインスタンスを購入可能である点等、独自サービスが豊富に用意されており、0.5点を加点します。(2.5点)
（参考）SavingPlans、スケジュールされたリザーブドインスタンス
※提供事業者により異なる場合があるため、必ず事前に提供事業者へお問い合わせください。
・RIレポートを通じてマネジメントコンソール上から購入済みリザーブドインスタンスの情報や推奨事項を確認可能です。(1点)
（参考）RIレポート

GCPの場合

キャパシティ予約

・キャパシティ予約については、ゾーンリソースの予約を作成することが可能で、継続利用割引、確約利用割引を受けることも可能です。
・公式ドキュメント上で「必要なときにワークロードにリソースを使用できるようにするために、特定のゾーンで仮想マシン（VM）インスタンスの予約を作成できます」と名言されています。(2点)
（参考）公式ドキュメント ・公式ドキュメント上にある通り、ゾーンリソースの予約期間に最低コミットメントはありません。(1点)
（参考）公式ドキュメント
※一部インスタンスタイプで例外あり

ディスカウント率と明確な価格

・東京リージョン汎用 n2-standard-2(CentOS)インスタンス 3年確約利用割引時の割引率は 43%でした。GCPの特長としてオンデマンド利用に継続利用割引が存在しており、これらを組み合わせて柔軟に割引適用を受ける事が出来ます。独自サービスとしてさらに0.5点を加点します。(2.5点)
・料金計算ツール、公式ドキュメント上から確約利用割引の利用料金を確認可能です。(1点)
（参考）料金計算ツール、公式ドキュメント

支払いの柔軟性

・公式ドキュメント上に「作成したコミットメントをキャンセルすることはできません。コミットメントの期間中は合意した月額を支払う必要があります。」との表記あり。(0点)
（参考）公式ドキュメント
・公式ドキュメントの通り、確約利用割引については前払い無しのみ選択可能です。(1点)
（参考）公式ドキュメント

インスタンス変更の柔軟性

・公式ドキュメント上に「購入したコミットメントは変更できません」とある通り返金、キャンセル不可です。(0点)
（参考）公式ドキュメント ・公式ドキュメントの通り、確約利用割引で購入したコミットメントタイプ内での垂直方向スケールであれば割引適用となります。(1点)
（参考）公式ドキュメント

利用手続きと購入後の管理

・確約利用割引購入はGoogle Cloud Consoleで操作が完結し、個別インスタンスへの適用は不要です。(2点)
・請求レポートを通じてGoogle Cloud Console上から割引クレジットとして表示される確約利用割引の使用状況を確認可能です。(1点)
（参考）請求レポート

Alibaba Cloud(国際サイト契約)の場合

[メリット①] キャパシティ予約

・キャパシティ予約については、公式ドキュメント上で「Zonal reserved instances provide resource reservations, but regional reserved instances do not.」とアベイラビリティゾーン予約の場合は予約されると名言されています。(2点)
（参考）公式ドキュメント
・リザーブドインスタンスのほかにサブスクリプションインスタンスを選択可能で、この場合利用期間の最低コミットメントは1ヵ月です。ただし、サブスクリプションインスタンスがリソース予約されていることに対する公式の言及が無いため、0.5点とします。(0.5点)

ディスカウント率と明確な価格

・東京リージョン汎用 ecs.g5.large(Linux)インスタンス 3年全額前払い利用時の割引率は 63%でした。(2点)
・リザーブドインスタンスの利用料金はログイン後コンソール上から確認する以外に確認手段がなく、アカウント非保持者が確認する手段が無いため、0.5点とします。(0.5点)

支払いの柔軟性

・公式FAQ上に返金に対する言及無し。返金は出来ないものと想定します。(0点)
（参考）公式FAQ
・公式ドキュメント上の支払いオプション表の通り、全額前払い,一部前払い,前払い無しを選択可能。ただし、前払い無しの利用可否はECS使用状況による資格制限があるため、0.5点とします。(0.5点)
（参考）公式ドキュメント

インスタンス変更の柔軟性

・公式FAQ上に、「No, the instance families of reserved instances cannot be changed.」とある通りインスタンス変更は不可です。(0点)
（参考）公式FAQ
・公式FAQ、「How is the zone flexibility of reserved instances applied?」の回答通り、同じインスタンスファミリーであれば割引適用となりますが、アベイラビリティゾーン予約の場合は対象外となるため、0.5点とします。(0.5点)
（参考）公式FAQ

利用手続きと購入後の管理

・リザーブドインスタンス購入はAlibaba Cloud Consoleで操作が完結し、個別インスタンスへの適用は不要です。(2点)
・公式ドキュメントの通りAlibaba Cloud Console上の請求情報から、購入済みリザーブドインスタンスを管理可能です。(1点)
（参考）公式ドキュメント

いかがでしたでしょうか。各社の特長を一言でまとめると以下のような感じですね。

• ディスカウントを主軸に支払いの柔軟性に優れたAzure
• 隙の無いサービス展開でニーズに対するカバレッジが広いAWS
• キャパシティ予約とディスカウントが分離され分かりやすいGCP
• サブスクリプション提供など、広い選択肢を提供するAlibaba Cloud

冒頭にも書いた通り、パブリッククラウドでは日々サービスのアップデートが行われていますので、上記はあくまでも2020年8月12日時点の情報という事を念頭に、利用前にしっかりとサービスを確認してください。
また、ソフトバンクではお客さまのご意見をパブリッククラウド各社へフィードバックし、サービス改善の一助となる活動をしています。
もっとこうだったらいいのにと言うご意見があれば、皆さまのお声をぜひお寄せください。

関連サービス