CS課佐竹です。
皆さん、ブラックフライデーでは何か購入されましたでしょうか？値引きされると買いたくなる、この心理はなんとも抗いにくいものですよね。というわけで、今回も値引き＝Savings Plans (SP)のお話です。
はじめに
Savings Plans に関するブログ第4弾です。過去3つのブログは以下のリストの通りです。
- [新機能] Savings Plans のリリースにあわせてIAMの権限を修正した話
- Savings Plan と Reserved Instance の比較
- Savings Plans を推奨値を参考に4種類購入してみました
今回のブログでは「Savings Plans を購入したらどのように適用されるのか？」を解説します。公式ドキュメントの「Understanding How Savings Plans are Applied to Your Usage」と近い内容になりますが、本ブログ記事ではExcelで作成した画像を用いてより分かりやすく解説していきます。
対象リソース
今回、Savings Plans の対象とするリソースを以下に一覧で表示します。
想定するリソースは、東京リージョンの EC2 Instance のみです。Savings Plans が適用された場合の利用料「SP/h」は「公式のPricingページ」を参考にしました。またSPの値引率は「Compute Savings Plans × 3年 × No Upfront」の値となっています。この額が対象のEC2 Instanceを「1台、毎時間、全て Savings Plans でディスカウントを受けるために必要なコミット金額」となります。「値引率」は公式ドキュメントが小数点以下を切り上げしていたので、独自に再計算し小数点第2桁まで表示しました。「オンデマンド/h」は公式の通りです。4つのInstance TypeとOSについてそれぞれ「台数」を記載し、それぞれ台数分積み上げた額が「オンデマンド台数」と「SP台数」です。
これ以下は全て上記の一覧を土台として説明致します。
- 全てオンデマンドで支払う場合
- 全て Savings Plans で支払う場合
- 部分的に Savings Plans で支払う場合
- Reserved Instance と Savings Plans を併用する場合
- 土日に Linux を停止運用する場合
- 日中夜間にLinuxを停止運用する場合
- Savings Plans をオーバーコミットした場合
- Savings Plans の購入目安
Savings Plans はどのように適用されるのか？
全てオンデマンドで支払う場合
図の左上にある「SP Commit」は「いくらの Savings Plans が購入済か」を示します。今回は「$0/h」です。次に各 Instance TypeとOSの組み合わせで、「毎時何台を起動しているのか」を時間ごとに示します。なお「0:00」は「0:00 - 0:59」の1時間を表しています。よって上図は「全Type＆OS」で「10+100+10+10」の合計全130台が終日起動している場合を表しています。加えて「オンデマンド」の利用料の背景は「ホワイト」で表しており、今回の図は「毎時全てホワイト＝オンデマンド」の利用料となります。この一覧を利用料に変換すると以下になります。
終日オンデマンドで利用する場合、特に値引きはありません。これが最も基本となる「全てオンデマンドの利用料」です。
全て Savings Plans で支払う場合
この図ではSPを「$4.108/h」をコミットしています。先に掲載しました「オンデマンドの利用料全てをSPでカバーするのに必要なコミット金額」は「$4.108/h」でした。
そのため、全てが「SPでカバーされている状態」となります。実際に1時間当たりの利用料で確認するため、先ほどと同様に台数を毎時の利用料に変換した表もご紹介します。
「SPが適用済」の利用料の背景は「オレンジ」で表していますため、今回の図は「毎時全てオレンジ＝SP適用済」の利用料となります。
部分的に Savings Plans で支払う場合
部分的にSPを適用するために「$1.180/h」をコミットしたとします。この場合、どういう順に Savings Plans が適用されるでしょうか？公式ドキュメントから引用すると次の通りです。意訳も載せておきます。
First, Savings Plans apply to the account that owns them, starting with products that receive the highest savings percentage, compared to On-Demand. Then, Savings Plans are applied to the broader organization.
（意訳）まず、Savings Plans はSPを所有するアカウントに適用され、オンデマンドと比較して「最も高い Savings% (値引率)を受けるプロダクト」から適用を開始します。次に、Savings Plans は Organizations に所属する他の AWSアカウントに適用されます。
今回重要なのは「最も高い値引率のプロダクトから適用される」という点です。つまり以下の一覧の値引率において、最も値引率が高いとされる「 r5.large × Linux」のEC2 Instanceに適用されてから、次に「t3.nano × Linux」のEC2 Instanceに適用されることになると想定されます。
$1.180 = $0.7900+ $0.3900 ですので、今回コミットしたSPはLinux OSの110台で使い切られる計算です。
よって、このようにSPは適用されることになります。これも利用料に変換してみます。
上記の通り、Linuxのみがディスカウントされた状態となります。結果的に一覧では「上半分がSP、下半分がオンデマンド」という状態になります。
Reserved Instance と Savings Plans を併用する場合
Reserved Instance（RI）とSPを併用した場合を考えます。今回は「r5.large × Linux」のRIを10台分購入し、かつSPも「$0.390/h 」でコミットしたとします。この場合の適用順序についても、公式ドキュメントより引用致します。
Savings Plans apply to your usage after the EC2 Reserved Instances (RI) are applied.
Because Compute Savings Plans have broader applicability, EC2 Instance Savings Plans apply before Compute Savings Plans.
（意訳）Savings Plans は、RIが適用された後の使用量に対して適用されます。
また Compute Savings Plans の適用可能範囲は EC2 Instance Savings Plans よりも広いため Compute Savings Plan より先に EC2 Instance Savings Plans が適用されます。
このように、RI及びSPは「適用範囲が狭いもの」から順に適用されることで「無駄が発生しないように」作られています。今回はRIとSPとを比較していますが、SPの中でも優先順位がある点は覚えておいて損はないでしょう。
戻って本題ですが、今回「r5.large × Linux」のRIを10台分全て購入しているために、RIが先に適用されることから値引率が1位の「48.03%」にSPが適用されることはありません。よって、2位の値引率「42.65%」である「 t3.nano × Linux」にSPは適用されることになります。
すなわち一覧表で表すと次の通りになります。
「RIが適用される対象」の利用料の背景は「グリーン」で表しています。これをコストに変換すると以下の通りです。
補足しますと、「r5.large × Linux」の「Convertible RI × 3年 × No Upfront」の毎時利用料はSPと同じ額になりますので、同額で記載しています。
このように「RIとSPを併用する場合においては、SPより先にRIが適用されるため、値引率の順序通りにSPが適用されないことがある」場合も存在します。
土日祝にLinuxを停止運用する場合
SPを今回は「$1.710/h」コミットしたとします。加えてコスト削減のため、土日祝に「Linux OSのEC2 Instanceを停止運用」しているとします（Cloud Automator のトリガーは祝日対応済）。この場合の土日祝の利用料を考えてみますと、値引率1位である「 r5.large × Linux」、2位である「t3.nano × Linux」は停止状態でありSPが適用されることがないために、3位である「r5.large × Windows」にSPが適用されることになります。
一覧表で表すと次の通りになります。
0時間の部分は背景を「グレー」にしています。利用料に変換すると以下の通りです。
停止しているLinux OSの利用料は全て $0 になります。
このように、停止しているInstanceが存在する場合に「SPの適用順序の入れ替えが発生する」ことがあります。
日中夜間にLinuxを停止運用する場合
「土日祝にLinuxを停止運用する場合」の発展編として、日中夜間にLinuxを停止する場合（SPのコミット額は同じく「$1.710/h」コミット）を考えます。夜間は「21:00 - 翌9:00」の12時間とします。先に結果を記載しますと、以下のような状態になります。
まず、「21:00 - 翌8:59」までは「土日祝にLinuxを停止運用する場合」と同じ状態になります。しかしこのパターンを複雑化するのは日中にLinuxが起動してきたときです。夜間停止の状態では、値引率第3位の「r5.large × Windows」が全てを利用しますが、日中にLinuxが起動している時間においては「値引率が高いLinuxに先にSPが適用される」ことになるため、適用先がLinuxに切り替わることになります。これをコストに変換してみました。
$1.710/h のコミット額はLinux全台でも「$0.790 + $0.390 = $1.180」と全てを使いきれないため、残った残高「$0.530」がWindowsにも一部が適用されます。「r5.large × Windows」は $0.1710/h のため、これが3台分で「$0.513/h」を消費します。つまり3台まではフルカバーされます。これを図示したいがために、Windowsを3台と7台に分けて記載してみました。計算結果として出てきたSPの余りは「$0.530 - $0.513 = $0.017」となり、これは4台目のWindowsの一部に適用されると予想されますが、フルカバーされないためこの図では省略させて頂きました。
このように、常に「最も値引率が高いところから適用される」ため、コスト削減には最適な反面 Savings Plans の見積もりは非常に難しいのが現状です。今回は説明において「東京リージョン」にリージョンを絞っていますが、複数リージョンを利用すると「リージョンごとにSPの値引き率が異なる」ためにさらにその見積もりは複雑性を増します。
Savings Plans をオーバーコミットした場合
SPを「$5/h」コミットしたとします。これは、以下の一覧の右端に記載した「SP適用後の利用料総合計 $4.1080」を超えています。
この場合、全EC2 InstanceへSPは適用されるため、以下の図の通りになりますが、問題はコストです。
コストに変換すると以下の通りオーバーコミット分は支払いが強制的に発生します。これは Reserved Instance を購入した場合と基本的には同様の動きです。
ただこの総合計「$5.000」という利用料は「全オンデマンド」の利用料である「$6.328」よりもディスカウントされています。無駄は発生しているのは確かですが「SPをオーバーコミットしているがオンデマンドより効果的な状況」であると念のため記載させてください。
Savings Plans の購入目安
最後にですが、「Savings Plans の購入目安」について図示致します。
縦軸は1時間あたりのAWS利用料です。横軸は時刻を示しており、「青いグラフ部分が72時間のAWS利用料の移り変わり」を示しています。AWS利用料から、「昼は利用料が高く」「夜に利用料が下がる」ということがわかります。この最も安い部分を「オフピーク」と言います。Savings Plans の購入においてはこのオフピークを知ることが必要になります。そして、このオフピーク鑑みた上で「SPの値引率を加味した額を購入（コミット）する」ことがSP購入のイメージです。重要なのでもう一度記載しますが、SPでコミットする額は、値引きされた後の額となります。
Savings Plans の購入目安 （RIとの併用）
RIと併用する場合は上図のイメージになります。「RIが先に適用され、その後にSPが適用される」という順序を示すため、RIを最も下に設置しています。
オフピークをどう知るのか？
SPの「推奨」では、このオフピークを意識した推奨値を提示してくれているため、基本的には推奨通りに購入して問題ないと考えております。ですが、オフピークを実際に見てみたいという方もいらっしゃると存じます。その場合ですが、2019年11月13日にリリースされた AWS Cost Explorer の新機能が役に立つでしょう。
AWS Cost Explorer が時間とリソースレベルの詳細度に対応開始
>時間別詳細度を有効にすることで、夜間またはオフピーク時のコストの推移を見るために、最大で過去 14 日分の時間別コストを表示できます。
>使用の開始には、支払者アカウントで Cost Explorer の設定ページを開き、時間およびリソースレベルの詳細度をオプトインします。利用コストは、1 か月間の 1,000 使用量レコード ごとに 0.01 USD です。使用量レコードは 1 つの使用量として定義されます。たとえば、1 つの EC2 インスタンスが 24 時間稼動していたとすると、時間別の詳細度では 24 個分の異なる使用量レコードが生成されます。
今まで Cost Explorer では日別（Daily）と月別（Monthly）の利用料が閲覧・分析できていました。これだけでも十分強力な機能でしたが、今回のアップデートで時間別（Hourly）の利用料が確認可能となりましたため、Cost Explorer を利用して頂くことで「1日の中でのオフピーク」を閲覧・分析頂けます。ただし、追加のコストが発生します点はご留意ください。
なお、この機能に関連し、以下のブログ記事を追加で記載しております。
まとめ
今回は様々なパターンで Savings Plans の適用順序を見てきました。少々複雑な内容になりましたが最終的には「Savings Plans はRIも加味して最も効果的に値引きが行われるように適用される」ことがご理解頂けたかと思います。
なお、AWSのディスカウントロジックは詳細が全て明らかにされているわけではないため、本記事に今後何らかの修正が必要になった場合は追記にて修正させて頂く予定です。
まとめとしては簡単になりましたが、これにて終わりにします。
ではまた、お会いしましょう。
合わせて読みたい
Savings Plans の仕様に関しては、以下のブログも合わせてお読みいただければ幸いです。
佐竹 陽一 (Yoichi Satake) エンジニアブログの記事一覧はコチラ
マネージドサービス部所属。AWS資格全冠。2010年1月からAWSを利用してきています。2021-2022 AWS Ambassadors/2023 Japan AWS Top Engineers/2020-2023 All Certifications Engineers。AWSのコスト削減、最適化を得意としています。
