• Home
• コーポレートブログ
• AWS Savings Plans完全に理解しました

岩石です。

弊社で入手可能なオライリージャパンの書籍をすべて揃えてから9年が経過し、来年2月には10年になります。
（参考： https://www.farend.co.jp/blog/2015/12/ndc/）
毎週ブログ更新も同じ年の8月から始めたので、本が揃った時の記事が残ってないのが残念です。

その後も新刊は購入し続けており、本棚の引越しも2度あったり本棚増やしたりしました。
社外の方も参加できる本の公開日もやってましたが、感染症の流行などもあり一旦開催を取りやめてました。
世の中の様子も少しづつ以前の状況に戻りつつありますし、またこういった取り組みを考えてみても良いですね。

AWSのコスト削減

Amazon Web Services（以下AWS）の課金方法は基本的に従量制で、何も全く使用しなければ無料であり使用しただけ各サービスの課金ルールに従って請求されることになります。
こういった課金形式であれば無駄な投資も小さくでき、最小のコストで開発・構築に取り組めるのはとても助かります。

しかしながらシステムの運用が安定し構成に大きな変更がなくなってくると、そのコストをより小さく抑えることができないかというフェーズに入ることになると思います。
システム構成の最適化の他にもAWSから提供されるコスト削減方法としてReserved Instances（以下RI）とSavings Plans（以下SP）があります。 SPは購入が適切かどうかを検証しようとすると結構悩むことがたくさんあります。

AWSさんにいろいろ教えてもらいながらやっと 完全に理解 できましたので、ブログに書いて共有しつつ、自分のメモとすることにしました。

予約型の課金方法

リザーブドインスタンス（RI）- Amazon EC2 | AWS

リザーブドインスタンス - Amazon RDS | AWS

RIとSPはともに将来の利用量を指定する購入方法となります。
雰囲気としては一定量の利用を予約するサブスクリプションを購入するようなイメージです。
RIもSPもどちらもAWS Organizationsで支払いを統合している場合、管理アカウントでの購入で連結アカウントの使用分の支払いにも適用されます。

RIはEC2とRDSに適用されます。どちらもリージョン・インスタンスタイプ・DBタイプ（RDSの場合）を指定し、1年もしくは3年の期間の使用インスタンス数を指定して購入します。支払い方法は「前払い」・「前払いなし（毎月支払い）」・「一部前払い（残額毎月支払い）」から選べます。期間と支払い方法により割引率は変動します。
支払いを宣言した形の利用となるので、仮に全く使用しなくても減額はされません。また同一構成のインスタンス稼働であっても、購入時に指定したインスタンスタイプとは異なるインスタンスの利用については減額の対象とはなりません。

通常のオンデマンド購入より大幅に値引きされるので、毎日24時間稼働し続けるインスタンスについてはメリットが大きいです（停止が一定時間発生するインスタンスについては適用するべきではないです）。

EC2のRIには通常購入のStandardのほか同等処理レベルのインスタンスタイプに変更可能なConvertible、稼働計画された利用に対応したScheduledがあります。

良いことばかりではなくRIは予約型の購入方法なので、クラウドならではのスペック変動への対応や将来より適切な構成に変化する可能性を考えると、EC2のRI利用はデメリットになることもあると思います。

なお次の項で説明するSPはRDSには対応していません。
RDSのコスト削減についてはRIしか選択できないのですが、DBシステムについては大きく仕組みを変更する場面は少ないと思うので大きな問題にはならないかもしれないです。
しかしながらサービスが大きくなると負荷も増え、スペック変更が必要になることも多いと考えるとサービス提供当初はオンデマンドで支払いを行い、一定のスペックの利用について先が見通せるようになってからRIを購入されるのが良さそうです。

Savings Plansの特徴

クラウドコストの節約 - Savings Plans - Amazon Web Services

RIでは支払い対象を細かく特定する必要がありますが、一方のSPはもう少し緩やかな指定となります。またRIは対象インスタンスタイプの台数と利用時間（期間）を指定するのですが、SPについては対象となる期間内の利用量（金額）を指定する購入方法です。
SPのプランとしてはCompute, EC2 Instance, SageMakerと3種類ありますが、今回はComputeの内容を書きます。

Compute Savings PlansではEC2だけでなくECS Fargate、Lambdaも対象になります。これらサービスの使用量を指定し減額料金で課金されるものになります。
購入の仕方としてはリージョン・時間あたりの使用量（USD）、支払い方法、そして1年もしくは3年の期間を指定します。

ちなみにEC2 Instance Savings PlansはRIと似たものになりますが、対象の指定がインスタンスファミリーとなりRIより指定が緩やかになることやRIのように時間を指定するものではなく使用量（金額）を指定するため、稼働の変動にも対応しやすくRIよりも利用しやすいと感じます（割引率はRIの方が高いです）。

SPの対象となる領域の使用料金がいくらになるかをきちんと自分で把握できている方は少ないと思います。実際の購入の場面ではAWS側で利用状況を踏まえた推奨購入金額が提示され基本的にはその金額を購入する（支払いを宣言する）ことになります（自分で計算して任意の金額で購入することも可能です）。
基本的にお任せで条件を細かく特定する必要がなく、RIやSP対象領域状況を管理する人的コストを考えるとこちらを選ぶメリットも大きいです。ただし割引率はRIと比較すると少なめですので、このあたりも考慮する必要があります。

指定する使用量の考え方

ある特定のインスタンスを継続して起動し続け台数を定めたまま運用する場合、そのインスタンスのスペックと台数で利用量の目論みが立ちますので割引率の観点でRIを購入することがお勧めですが、負荷状況により台数やスペックを変動させるなどの場合は条件をきっちり指定するRIは向いてません。

そこでSPを選ぶことになるのですが、SPは時間あたりの使用量を指定する購入方法のため適切さというのがわかりにくいです。

仮に次のような使用量を想定します。

これに対して青いBOXが示す使用量分をSPで購入した場合、少し購入が少ない（SPでカバーできていない領域が多い）と感じられます。

それではということで下の図のように購入すると買い過ぎ（SPが余る領域が多い）と感じます。

できれば下記の程度の購入になるようにしたいところです。

これがベストな買い方というわけではないですが、現在の状況から今後の使用量を予測し購入を進めることになるため、すこし少なめに購入して足りないと感じたら追加で購入するという考え方の方がより適正で安価な購入額に落ち着くと思われます。
しっかりとした計算システムを作り上げ、購入金額を算出する仕組みが作れると良いですが、そこまでたどり着くのも結構なコストがかかりそうです。後述の利用率やカバレッジもあくまで参考値でしかありませんので、現実的にはおおよその利用状況をふまえつつCost Managerが推奨購入金額として算出する数値で購入を行い、その後の経過について定期的にレビューをするのが現実的と感じました。（結局普通の使い方が一番でした😅）

レビュー方法

Cost Managerでのレビュー

購入に対して適切にSPが使用されているかについてはCost Managerを参考にすることになります。
Cost Managerの Savings Plans - 使用状況レポート（utilization reports） および カバレッジレポート（coverage reports） で期間の日付を目的のものに合わせて確認します。
集計までに2日程度かかりますので、購入した影響については数日後に結果がわかります。

使用状況は購入したSPがどの程度使用されているかを示し、購入がピッタリ一致するか足りなければ100%になります。100%から下がれば下がるほど余っている（= 買い過ぎ）ということになります。
カバレッジは購入したSPが対象となる候補の使用量に対してどの程度適用されているかを示します。 購入がピッタリなら100%で、100%から下がれば下がるほどカバーができていない（= 購入が足りない）ということになります。

前項の内容を踏まえるとシステム使用量が変動する場合は、使用率もカバレッジも100%にすることはとても難しくあまりそれを目指すのは良くないと感じます。利用形態にもよりますが、一般的にはカバレッジよりも使用率が適切になるように購入するのが良さそうです（カバレッジを重視するほうが良い場合もあるとは思います）。

Cost Explorer

Cost Explorerを使用することで、実際に課金された金額とSPやRIが適用されなかった場合の金額を確認することができます。

フィルターの「料金タイプ」と「購入オプション」を使ってフィルターをして目的の金額を表示させます。

CURの利用

また実際に使用した状況を確認する方法としてCUR（Cost & Utilization Reports）を使用して確認する方法があります。弊社ではAWSさんのおすすめでQuick Sightを使って可視化する方法をとってます。

Quick Sightのデータセットに下記でセットアップするGlueとAthenaのクエリーで作成できるテーブルを指定し分析画面を作成します。

Use AWS Glue to enable access to CUR files via Amazon Athena :: AWS Well-Architected Labs

まとめ

RIとSPともに買い直しができないので購入時は注意が必要です。
特にRDSのRIなどは「前回購入したものと同じもの」という指定ができず、毎回ヒヤヒヤしながら複数名で確認しながら購入処理を進めています。このあたりについては改善してほしいですね。

RIとSPどちらも毎月の使用料金を考えるととても嬉しいサービスですが、どちらも判断を誤るとかえって利用額が高くなる可能性もあります。社内での今後のシステム利用の増減の状況をまとめて購入判断をされるのが良いと思います。

結果としてCost Managerの推奨内容が最も適切だろうということは完全に理解はしましたが、定期的なレビューをしつつ必要になったらまたこのブログを見返したいと思います。

【スタッフ募集中】
弊社ではAWSを活用したソリューションの企画・設計・構築・運用や、Ruby on Rails・JavaScriptフレームワークなどを使用したアプリケーション開発を行うスタッフを募集しています。採用情報の詳細
弊社での勤務に関心をお持ちの方は、知り合いの弊社社員・関係者を通じてご連絡ください。

---