AWS Savings Plans はじめてのおつかい

こんにちは。
ご機嫌いかがでしょうか。
"No human labor is no human error" が大好きな吉井 亮です。

担当しているプロジェクトで AWS Savings Plans (以下 SP) を購入する機会がありました。
前職までは勧めて買ってもらう立場でしたが、今回は初めて買う側です。前職では専門チームが見積もり作ってくれましたし、実際に買う操作は自分ではしなかったのですが、自分でやるとなると責任が違いますね。

Savings Plans とは

SP は長期利用をコミットすることで割引を受けられる仕組みです。
1年または3年の契約期間を選択できます。また、前払いなし/一部前払い/全額前払いの3通りから支払い方法を選択できます。全額前払いが最も割引率が高くなっています。

EC2 の場合は Compute Savings Plans と EC2 Instance Savings Plans の2つのタイプが用意されています。
Compute Savings Plans は、インスタンスファミリー、サイズ、アベイラビリティーゾーン、リージョン、OS、またはテナンシーに関わらず割引が適用されます。
EC2 Instance Savings Plans は、インスタンスファミリーが固定になりますが、代わりに割引率が高くなります。
何れにしても Reserved Instance より高い柔軟性が特徴です。

Savings Plans のよくある質問

結論

なんとか効率良い購入方法はないものかと思案してみましたが、結局のところ AWS Cost Explorer の推奨事項通り購入するので間違いがなさそうという結論になりました。
さすが公式機能です。突き詰めていったり特徴的なワークロードだったりして推奨事項より効率良い購入があるかもしれませんが、そんなことをしている時間を考えるとプラマイゼロかもしれません。

Savings Plan のよくいただくお問い合わせについて

EC2 Auto Scaling での Savings Plans

今回なぜ考えてみようという気になったかといいますと、EC2 Auto Scaling を利用している環境でした。
夜間に減台、朝になったら5〜6倍に増台して運用しています。この日中分を SP でなんとかしたいと考えて次第です。

オーバーコミット、つまり夜間は定価を上回るコミットメントで SP を購入、日中の割引を大きく受けることで得をしたかった訳です。
仮に夜間を10台、日中を60台とした場合、必ず起動している10台をベースにコミットメント価格を決めるのが基本的な考え方なのですが、11台分や12台分オーバーコミットしてみたらという計算をしてみましたが、
最低起動の10台が最も効果的でした。
後から考えれば当たり前ですよね。停止していればコンピュートには課金発生しないので。。。

まとめ

24時間稼働の EC2 で SP 活用というのはよく考えていましたが、Auto Scaling 利用時の SP について考える良い機会になりました。
SP はやっぱり複雑でした。月末になったら裏側で自動的に割引する仕組みがあると幸せだなーと感じます。