EC2利用料削減！停止起動運用、RI、SPの比較

0.導入

よくお客様からAWS利用料を削減したいという相談をいただきます。
いろいろな方法はありますが、EC2がメインの利用料となっている場合、
よくご提案するものとして、RI(Reserved Instance)の導入、SP(Savings Plans)の導入、停止起動運用の導入が挙げられます。
今回は各パターンの割引率、メリットデメリットを紹介して
どのパターンが適しているか見極めるポイントをお伝えできればと思います。
また、RIとSPのインスタンスタイプ変更の細かい条件の説明は少し長くなりそうなので、本記事ではドキュメントのリンクのみといたします。

目次
1.割引率比較
1-1.夜間停止運用
1-2.RI
1-3.RIのOS比較
1-4.SP
2.各パターンの特徴
2-1.夜間停止運用
2-2.RI
2-3.SP
3.パターンごと比較
4.EC2利用料削減のその他の手段
5.まとめ

1.割引率比較

1-1.停止起動運用
「停止起動運用」とはEventBridgeで対象サーバを定時刻に停止・起動する運用です。
社内用ファイルサーバなど夜間帯や土日は使用しないサーバで採用される運用方法です。
シンプルに停止した時間がEC2利用料の削減率に直結します。

例えば、平日は8時間停止、土日停止とした場合は
8h x 5d + 24h x 2d = 88h
1週間は24h x 7d で168hですので、88h ÷ 168h = 約52%の削減率です。

1-2.RI
RI(Reserved Instance)はEC2の使用を一定期間コミットし、インスタンスタイプなどの変更を限定的とすることで割引を受けられるAWSの仕組みです。
他の記事で「RIは最大72%割引」「RIの平均割引率は40%」という言葉を目にしますが、OSやコミット期間などによって割引率は大きく変わります。RIの割引率(オンデマンドとの比較)を算出するための要素をパラメータとし、各パラメータごとの割引率を以下表で比較しています。
その際、その他のパラメータは以下の前提条件に固定しています。
※OSが最も変動する要素なので、OSに関しては1-3. RIのOS比較にて後述します。

○前提条件
・OS ：Linux
・コミット期間：3年
・支払い方法：全額前払い
・RIのタイプ：Standard RI
・リージョン：東京リージョン
・テナンシー：共有
・インスタンスタイプ：m6i.xlarge
※比較パラメータ以外のパラメータは上記で固定

表1：OSがLinux(RI)

・コミット期間
割引率が大きく変動する要素です。ただし3年間もインスタンスタイプを固定するのはリスクがあります。
3年間の中でサーバへの需要が変わるとスペックの見直しが必要になる場面もありそうなので、将来的にサーバの使い方が変わらないか確認する必要があります。

・支払い方法
割引率の変動幅としては比較的少ないパラメータです。予算取りの問題などもありますが、前払いすることで多少のメリットはあるようです。
逆に言えば前払いしなくてもインスタンスタイプの固定をコミットすることでかなりの割引を受けることができます。

・RIのタイプ
RIにはStandard RIとConvertible RIが選択できます。
簡単にいうとStandard RIの方が柔軟性が失われる分割引率が高く、Convertible RIはその逆となります。
以下ドキュメントに細かい条件や制約事項が記載されてありますので、購入の際はご確認ください。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-reserved-instances.html

また購入の際にリージョン固定とするかAZ固定とするかを選択する必要があります。
割引率に変動はありませんが、インスタンスタイプ変更の条件などが変わってきます。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/reserved-instances-scope.html
例えば、Standard RIの場合、AZ固定のLinuxに限り、同じインスタンスタイプファミリー内であれば変更可能です。

・リージョン、テナンシー
これらのパラメーターは割引率の変動幅としては少ないパラメータです。

・インスタンスタイプ
一般的に使われるインスタンスファミリー(m、r、c、tなど)ではあまり差はありません。
また、上記のインスタンスファミリーであれば、世代数やインスタンスサイズを変えてもあまり変化はありません。
ただし例外となるインスタイプもあり、例えば、上記の前提条件の場合「x2iedn.metal」は72%、「hpc7g.16xlarge」は40%となります。しかし、これらのインスタンスタイプの使用ユーザーは限定的かと思います。

・RIの見積
以下のページでパラメータを入力すると計算することができます。
https://aws.amazon.com/jp/ec2/pricing/reserved-instances/pricing/

1-3. RIのOS比較
OSで何を使うかが、RIの割引率として最も大きな変動要素となりますので、切り出して記載します。
ライセンスが絡むOSは割引率が少なくなり、Windowsの場合はその半分ほどとなります。SPでも同様です。
OSのパラメータとして他にも「SLES」や「Windows SQL Enterprise」なども選択できますが下記表には代表的なものを記載しています。その他のパラメータは先ほどと同様とします。

○前提条件
・コミット期間：3年
・支払い方法：全額前払い
・RIのタイプ：Standard RI
・リージョン：東京リージョン
・テナンシー：共有
・インスタンスタイプ：m6i.xlarge
※比較パラメータ以外のパラメータは上記で固定

表2：OS比較(RI)

さらに、例としてOSをWindowsとした場合の割引率を以下表で比較しています。
その他のパラメータは「表1：OSがLinux」と同様とします。

○前提条件
・OS：Windows
・コミット期間：3年
・支払い方法：全額前払い
・RIのタイプ：Standard RI
・リージョン：東京リージョン
・テナンシー：共有
・インスタンスタイプ：m6i.xlarge
※比較パラメータ以外のパラメータは上記で固定

表3：OSがWindows(RI)

1-3.SP
SP(Savings Plans)は一定期間の金額をコミットすることで割引を受けられるAWSの仕組みです。コミット期間中もRIよりもより柔軟にインスタイプなどを変更することができます。
設定するパラメータはRIとほとんど同じで、各パラメータをRIと揃えた場合、ほぼ同じ割引率となります。
SPのタイプのところがRIと少し違いますが、柔軟性が少ないタイプと多いタイプという考え方は同じで、割引率もほぼ同じとなります。

○前提条件
・OS ：Linux
・コミット期間：3年
・支払い方法：全額前払い
・SPのタイプ：EC2 Instance SP
・リージョン：東京リージョン
・テナンシー：共有
・インスタンスタイプ：m6i.xlarge
※比較パラメータ以外のパラメータは上記で固定

表4：OSがLinux(SP)

・SPのタイプ
SPにはEC2 Instance SPとCompute SPが選択できます。
簡単にいうとEC2 Instance SPはインスタンスファミリー内でのみ変更が可能で割引率が高く、Compute SPはより柔軟にインスタンスタイプを変更できる分、割引率は少し減ります。
以下ドキュメントに細かい条件や制約事項が記載されてありますので、購入の際はご確認ください。
https://docs.aws.amazon.com/ja_jp/savingsplans/latest/userguide/what-is-savings-plans.html

またSPはODCR(On-Demand Capacity Reservation)=キャパシティ予約が可能です。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html
ODCRを適応することでInsufficientInstanceCapacityエラーを回避することができます。

InsufficientInstanceCapacityエラーとはAWS側内部で対象のインスタンスが不足して、起動できないエラーです。
https://repost.aws/ja/knowledge-center/ec2-insufficient-capacity-errors
少し時間をおけば起動できるようになる場合もありますが、起動できないことがビジネスクリティカルになるサーバはキャパシティ予約をしておくと安心です。
特にインスタンスの需要が高まっている日中帯に起動を試みるとエラーが発生する確率があがります。
例えば、バックアップの静止点取得などで定期的に停止する運用の場合は注意が必要です。

・SPのタイプ以外のパラメーター
基本的に割引率の変動幅はRIと同じです。柔軟性が高いタイプ同士であるConvertible RIとCompute SPで比較しても同じことが言えます。

・SPの見積
以下のページでパラメータを入力すると計算することができます。
https://aws.amazon.com/jp/savingsplans/compute-pricing/

2.各パターンの特徴
2-1 停止起動運用

・メリット
購入オプションとしてはオンデマンドになるので、いつでもサーバの廃止、インスタンススペックの変更が特に条件なしに可能です。

・デメリット
停止起動運用のデメリットは先ほどSPの説明内で記載した
InsufficientInstanceCapacityエラーが発生するリスクがあることです。

エラー回避の対策としてODCR(On-Demand Capacity Reservation)=キャパシティ予約がありますが、
こちらは予約した間は停止期間中も課金対象なので、利用料削減のために起動/停止運用をする場合は有効な回避方法とは言えません。

再度起動を試みる、AZ変更やインスタンスタイプを変更して起動を試みることで、起動できることもありますがすぐに起動する保証はありません。
指定時間に起動が失敗するとビジネス影響が大きい場合は、停止起動運用は適しません。

2-2 RI
・メリット
SPとの比較でいえば、割引が割り当たっている対象が明らかになりますのでサーバーごとの費用が明確になります。
また弊社のAWS請求代行サービスadv.なら、RIの割引も受けつつさらにAWS利用料8%引きも上乗せされます。
RIで運用したいと思った方は、AWS請求代行adv.もぜひご検討ください。
https://cloudpack.jp/service/aws/invoice-adv.html

・デメリット
インスタンスタイプの変更に制限があることです。条件によっては可能ですがOSやAZに制限があったりするので
ドキュメントをしっかり確認する必要があります。

長期的にインスタンスタイプを変更できないことにリスクを感じる場合は、
割引率は下がりますが、RIのコミット期間を1年として、1年ごとにインスタンスタイプを見直すというやり方が考えられます。
その場合は割引率や条件も鑑みてSPとの比較になるかと思います。

2-3 SP
・メリット
インスタンスタイプは未定だが割引をしたい場合は、SPは非常に有効です。
AWS Organizationsと呼ばれるサービスで複数のアカウントを統合している環境でもSPは使用可能です。
サーバ1台ごとにコミットするのではなく、サーバ全体の金額に対してコミットするイメージです。
全体で割引を当てる事ができるので、サーバ1台1台のスペックを吟味しなくてもざっくり計算で購入できます。

・デメリット
RIと比較してSPはインスタンスタイプ変更に関して柔軟性がありますが、むやみやたらにインスタンスタイプを変更(特にスペックダウン)すると、SPでコミットした金額が実際の利用料金に対してオーバーする可能性もあります。
例えばm5.xlarge 1台分の金額をコミットしている場合、m5.largeにスペックダウンをすると、コミットしたSPの金額のうち半分が割り当たらず、無駄に払ったことになります。
Cost ExplorerでSPの割り当て状況が確認できますので、インスタンスタイプを変更するときはコミットした金額が無駄になっていないか確認するようにしましょう。
https://docs.aws.amazon.com/ja_jp/savingsplans/latest/userguide/ce-sp-usingPR.html
組織の規模が大きくなりSPのコミット額も大きなってきたら、コミットした額と実際の使用状況を管理する必要があります。
また、特定のサーバにSPのコミットした金額を優先的に割り当てるという選択はできません。全体として費用を削減するというイメージとなります。

3.パターンごとの比較
○前提条件
・リージョン：東京リージョン
・テナンシー：共有
・停止時間：52%(平日は8時間停止、土日停止)
・OS：Linux
・インスタンスタイプ：m6i.xlarge
・コミット期間：3年
・支払い方法：全額前払い

表5.各パターンの比較

※ODCRとはOn-Demand Capacity Reservation=キャパシティ予約のことです。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-capacity-reservations.html

前提で記載している条件で割引率は変わってきます。
例えばWindowsの場合、RI・SPの割引率が半分ほどになるので、起動停止運用の方が有利となります。
上記のように条件を当てはめて数字を比較すれば最も安いパターンが導き出せます。

4.EC2利用料削減のその他の手段
4-1.インスタンスタイプの変更

インスタンスタイプをスペックが低いものにすれば利用料は下がります。
※SPの場合、スペックダウンしてもコミットした金額が無駄にならないかは確認するようにしましょう。
ただし適切なインスタンスタイプを見極めるには現状のリソース状況とこれからのリソースを予測する必要があります。インスタンスタイプ変更には再起動が走りますので、サーバによっては頻繁にできる手段ではありません。

同じインスタンスファミリー内での変更だけでなく、vCPU数やメモリ容量のみ変更することも可能です。
以下表に記載しておりますが、メモリ数の引き下げよりも、vCPU数を引き下げる方がコストメリットは大きいです。
また、スペックはそのままでインスタンスの世代を変更したり、プロセッサタイプ(iがインテル、aがAMD)、最近発表されたm7i-flexと呼ばれるインスタンスタイプも料金を削減する選択肢して考えられます。

○前提条件
・東京リージョン
・OS：Linux
・購入オプション：オンデマンド
・変更前のインスタンスタイプ：m6i.xlarge

表6.インスタイプの比較

4-2. アイレットのAWS請求代行サービスの利用
・アイレットのAWS請求代行サービスでAWSアカウントをご契約いただくと、AWS利用料が10%割引となります。
https://cloudpack.jp/service/aws/invoice.html

・また、RIをメインで使いたい場合は、AWS請求代行サービスadv.がお得です。RIの割引をうけつつ、さらにAWS利用料8%割引も適用されます。
https://cloudpack.jp/service/aws/invoice-adv.html

・SPのメリットの中で出てきたAWS Organizationsが使えるAWS請求代行サービスもございます。
https://cloudpack.jp/lp/aws-organizations/

5.まとめ

簡単にまとめると
停止時間が長く、起動できなくてもビジネスクリティカルでないサーバは停止起動運用。
インスタンスタイプを固定できて、分かりやすく管理したいならRI。
インスタンスタイプを柔軟に変更しながら割引を当てたい場合はSP。
Convertible RIやSPは柔軟性がある分、インスタンスタイプの選定や管理に工数がかかる場合がある。
となります。

またRIとSPの割引率や条件は、今後AWS側で変更になる場合がございますのでご注意ください。