COLUMN

1.Savings Plansの3つのタイプ

Savings Plansには3つのタイプがあります。それぞれ対象となるサービスが異なります。

本記事では、Amazon EC2をサポートするタイプのみを取り上げます。単にSavings Plansと書いた場合、以下の2つのタイプを指します。

• Compute Savings Plans
• EC2 Instance Savings Plans

また、Compute Savings PlansはAWS Lambda、AWS Fargateにも適用できますが、考え方をシンプルにするため、基本的にはAmazon EC2 のオンデマンドインスタンスに適用する場合を想定して説明します。

2.Savings Plansによる割引の考え方

Savings Plansによる割引についてイメージを掴んでおきましょう。

Savings Plansを利用するには、いくつかのパラメータを指定して購入を行います。パラメータに応じた料金は以下のページから確認できます。

https://aws.amazon.com/jp/savingsplans/compute-pricing/

ここでは例として以下を指定して料金を確認してみます。

上記のパラメータを選択すると、以下のように条件に合致するインスタンス名（インスタンスタイプ）の料金が表示されます。

ここでは、一番上のm5.largeの数字に注目してみます。

ここでの1,3の料金はいずれも1時間換算の料金です。Savings Plansを購入することで、本来発生するはずだったオンデマンド料金を相殺できます。以下のイメージとなります。

1時間あたりのSavings Plansの料金を指定して購入することで、それに応じたオンデマンド料金を相殺できます。上記の例では1台のインスタンスの1時間のオンデマンド料金をちょうど相殺する金額を指定しましたが、それより高い金額や低い金額も指定できます。

こういった指定金額の合計をコミットメント額と呼びます。一定量の使用を確約（コミット）することで、割引を受けられるという考え方です。Savings Plansではコミットメント額という概念が重要です。

リージョンやインスタンスファミリー、オペレーティングシステムなどのパラメータを変更すると、上記表の1,2,3の数字が変動することがわかります。特に、2の費用節減の割合が異なる、つまり割引効率に差が出るということを押さえておきましょう。

3.Savings Plansのコミットメント額

Savings Plansの購入の際に指定するパラメータはいくつかあり、コミットメント額の指定は必須です。AWS管理コンソールからSavings Plansを購入する際の画面イメージは以下です。

購入時に指定するパラメータは以下です。（表中では、Savings PlansのことをSPと略します。以降も同様。）

ここでのコミットメント額は自分で決定する必要があります。Savings Plansによる割引を適用させたいオンデマンドインスタンスの数、種類、稼働状況など、自身の環境に合わせて決めます。

4.Savings Plansの適用イメージとして回数券を考える

Savings Plansのコミットメント額を定めるためにも、Savings Plansによってオンデマンド料金を節約する具体的なイメージを確認しておきます。

ここでは、Savings Plansのことを回数券のようなものであると考えてみましょう。回数券の1枚のチケットには、「適用条件」と「コミットメント額」が書かれています。

そして、コミットメント額に応じてどの程度のオンデマンド料金を相殺できるかの料金表が別に用意されています。

料金表に基づき、そのチケットでもっとも割引効率が高くなる対象を選定し、適用を行うことで1時間分のオンデマンド料金を相殺します。選定や適用は自動で行なってくれるので、利用者が意識する必要はありません。

4-1.Savings Plansチケットに書かれている適用条件

ここでの「適用条件」はSavings Plansのタイプが大きな関わりを持ちます。

EC2 Instance Savings Plansの場合は、購入時に「リージョン」「インスタンスファミリー」を併せて指定する必要があります。その指定に合致しないオンデマンドインスタンスは、適用の対象になりません。

逆に、Compute Savings Plansタイプの場合は上記の指定が不要です。適用条件は無い、と言えます。オンデマンドインスタンスに限らず、Lambda 関数やFargateなども含め、最も効率がよいものを自動で選定してくれます。

4-2.Savings Plansのコミットメント額=チケット1枚の値段

Savings Plansのコミットメント額は、相殺可能なオンデマンド料金を決定するものであると同時に、ここでのチケット1枚の値段にも相当します。例えば相殺できるオンデマンド料金が同じでも、1年分だけ買うよりは3年まとめて買った方が1枚あたりの料金が安く済む（コミットメント額を少なく指定できる）、というイメージです。

コミットメント額（1枚あたりの料金）に影響を与える主要な要素は以下です。

4-3.Savings Plansの一部適用、複数台への適用

チケット1枚とインスタンス1台が1:1で紐づくわけではありません。割引効率が高い順に対象となるオンデマンドインスタンス（の料金）が選定された結果、チケット1枚を使っても1台分の1時間の料金すべてを相殺できない場合があります。

その場合、オンデマンド料金の一部をSavings Plansで相殺し、残りがオンデマンド料金として発生します。

逆に、オンデマンドインスタンス1台分を相殺してなおチケットに余剰が発生する場合もあります。その場合、その余剰分が別の対象に適用されます。残っているものの中でもっとも割引効率が高い対象を選定/適用し、その一部もしくは全部を相殺します。そこでもさらに余剰分が発生すれば、同じことを繰り返します。

4-4.Savings Plansの適用は時間単位で行われる

チケットは1時間ごとに1枚使用されます。Savings Plansは1年間か3年間のコミットメント期間を指定して購入するため、8,760（365×24）枚つづり/26,280（365×3×24）枚つづりの回数券をイメージするとよいでしょう。

回数券を前払いで買うことも、後払いで買うこともできます。前払いで買った方が1枚の値段が安くなるのは先述の通りです。

4-5.Savings Plansは自由に適用タイミングを選べるわけではない

ここまでSavings Plansのことを回数券に例えて説明してきました。回数券というと自身のタイミングで利用できるイメージが浮かぶかもしれませんが、Savings Plansはそうではありません。

そのため、自動で回数券のチケットをもぎるボットがついてくると考えましょう。

もぎりボットにより、1時間に1回チケットはもぎられていきます。その1時間の枠の中で、割引効率が最も高い対象を選定し、チケットが適用されます。チケット1枚がインスタンス1台と1:1になるとは限らず、一部相殺にとどまったり余剰分が発生し得る、というのは先述の通りです。

また、適用対象が存在しないケースもあることに注意してください。例えば夜間はすべてのインスタンスを停止している環境があった場合、その時間帯にはオンデマンド料金が発生しません。その時も変わらずもぎりボットはチケットをもぎるため、そのチケットは適用対象が無く無駄に消費されます。

チケットが自動的に適用されていくイメージを表した絵は以下です。

ここでは図中のインスタンスは割引効率がすべて同じケースを想定して記載しています。以下を押さえてください。

• チケットは自動的に使用される
• チケットは特定のインスタンスにひもづく物ではなく自動で対象が選定され適用される
• 1台の一部のみ相殺することもあれば、余剰分が発生することもある

5.Compute Savings Plans とEC2 Instance Savings Plansのどちらを選べばいいの？

ここまでの説明の中で、Compute Savings PlansタイプとEC2 Instance Savings Plansタイプの差異について触れました。改めて整理すると、以下の違いがあります。

その他のオプション、例えばコミットメント期間指定や支払いオプションなどに差異はありません。

Compute Savings Plansタイプの方がより柔軟に適用してくれる分、割引効率が少し劣るという特徴があります。環境で使用するインスタンスがある程度固定されており今後一定期間変更が見込まれない、ということであれば割引効率の高いEC2 Instance Savings Plansタイプを選択し、そうでなければCompute Savings Plansタイプを選択する、というのが基本的な考え方になります。

6.どんな時にSavings Plansを使うといいの？

すべての環境でSavings Plansを活用するのが最善手というわけではありません。ここまで述べてきたように、Savings Plansには「インスタンスが停止している時にも利用される」「購入プランによっては適用条件がある」という特徴があります。

よって、インスタンスの起動/停止が頻繁に行われたり、インスタンスの数やファミリーが頻繁に変更される環境では思うようにコストメリットが得られない場合があります。

そういった意味で、一定の稼働が固定化されている環境での利用が推奨されています。

6-1.Savings Plansとリザーブドインスタンスのどちらを選べばいいの？

上記の画像では、Savings Plansと合わせて「RI」も併せて記載されています。ここでのRIはリザーブドインスタンス（Reserved Instances）のことを指します。

リザーブドインスタンスは、Savings Plansと同じく一定の固定の稼働が見込まれるワークロードへの適用が推奨されています。リザーブドインスタンスもSavings Plansと考え方は似通っており、回数券のようなものというイメージで表せます。Savings Plansのタイプと同じように「提供クラス」という概念があり、2種類に分かれます。

Savings Plansとリザーブドインスタンスの差異を大まかにまとめると、以下となります。

• 割引効率は両者で特に差異なし
• Savings Plansの方がより柔軟に適用ができる
• Savings Plansと異なりリザーブドインスタンスではコミットメント額の換算が不要
• 一部リザーブドインスタンスでしかできない機能がある

Savings Plansの柔軟性がメリットになることが多いためそちらを優先して検討し、機能や運用などを考慮してリザーブドインスタンスの方がメリットが上回る場合はリザーブドインスタンスを選択する、という方針がおすすめです。

詳細な比較は別の記事にて行ったことがありますので、併せてご参照ください。

EC2 でリザーブドインスタンス（RI）と Savings Plans （SP）のどちらを選ぶべきか？基準とするための最強の比較表を作ってみた | DevelopersIO

7.Savings Plansの利用を助ける便利な機能

Savings Plansを利用する際に便利な機能がいくつかあります。ここでは概要のみをご説明します。詳細が気になる場合は、ドキュメントを参照してみてください。

8.まとめ

本記事では、Savings Plansの基本的な考え方について説明しました。

Savings Plansは、うまく活用すればオンデマンドインスタンスと比較して数10パーセント以上の割引効率を実現できます。ただし、適用条件に合致する対象が環境に存在しなければ無駄が発生するというリスクもあります。仕様を正しく理解し、どのような内容で購入するかをよく検討のうえご利用ください。

クラスメソッドの千葉幸宏（チバユキ）がお届けしました。