はい、やってしまいました。犯人は僕（鈴木）です。
弊社ではAWSをめちゃくちゃ使わせて貰っています、300台以上のEC2インスタンスが存在します。うち、30台くらいが常時起動です。
先々月、AWSのコスト削減をしようということで重い腰をあげて、まずは数台分のリザーブドインスタンスを購入しました。
しかし、あろうことか購入するインスタンスサイズを間違えてしまったので、意図したとおりに費用削減されていないことが発覚しました。
その際の対応方法をまとめたので、参考になればと思います。*1
[追記]Qiitaにも同じ内容を投稿しました。
ちなみに、本記事に登場するリザーブドインスタンスの仕様は以下の通りです。
- 東京リージョン
- 料金は全前払い
- 1年契約
- Standardクラス
- アベイラビリティーゾーンの指定なし
まずは簡単にAmazon EC2と、リザーブドインスタンスあたりの用語の説明から。（知っている方は読み飛ばしてください。）
Amazon EC2とは
Amazon EC2とは、Amazon Elastic Compute Cloudの略で、Amazonが提供する仮想サーバです。
使用するサーバリソースを柔軟に変更することができ、使用するサーバリソースと使用時間に応じて料金が変わる仕組みです。
ひとつひとつのサーバのことをインスタンスといい、インスタンスにはオンデマンドインスタンスとリザーブドインスタンス等があります。*2
オンデマンドインスタンスとリザーブドインスタンス
オンデマンドインスタンスは、起動時間に対してお金を払います。つまり時間に対する従量課金です。一番ベーシックな使い方かと思います。
リザーブドインスタンスは、簡単に言うと長期間使用することを前提に、オンデマンドインスタンスよりも安い料金で使用することができるインスタンスです。弊社では、常時起動予定のインスンタンス4つに対して、1年間分、全前払いで購入しました。
インスタンスタイプとインスタンスサイズ
インスタンスの性能は、そのインスタンスがどのインスタンスタイプであるかによって決まります。 例えば、m3.largeというインスタンスタイプの性能は下記の通りです。largeの部分をインスタンスサイズと呼ぶようです。
| インスタンスタイプ | vCPU | ECU | メモリ | インスタンスストレージ | 年間料金(オンデマンド) | 年間料金(リザーブド) |
|---|---|---|---|---|---|---|
| m3.large | 2 | 6.5 | 7.5 | 1 x 32 SSD | $1,690.68 | $950.00 |
詳しくはこちらを。
対応手順
お待たせしました。ここから本題です。
1. リザーブドインスタンス適用状況を確認する
まず、購入したリザーブドインスタンスが正常に使われているかを確かめました。
EC2 マネジメントコンソール＞レポート＞EC2 リザーブドインスタンスの使用状況 から確認できます。
https://console.aws.amazon.com/ec2-reports/?breadCrumb=EC2Console#ReservedInstanceUtilization:
すると、今回の対象は常時起動のインスタンスなので本来100%になっているはずが、そうではないことに気づきます。5%しか適用されていないものもあります。
（とはいえ、オンデマンドインスタンスに比べると、$100程度は安くなっていることがわかります。）
2. 適用されていない原因を調査する
以下の順に原因を切り分けました。
- 対象のインスタンスを起動していない
- 対象のインスタンスとリザーブドインスタンスで、リージョンが異なる
- 対象のインスタンスとリザーブドインスタンスで、アベイラビリティーゾーンが異なる
- 対象のインスタンスとリザーブドインスタンスで、インスタンスタイプが異なる
今回の場合は、a~cは問題なく、dが問題であることがわかりました。
a~cが原因であればリザーブドインスタンスのパラメータを変更すれば容易に対応できるのですが、今回はそうはいかないようです。
3. 変更可能であれば、対象のインスタンスのインスタンスタイプを購入したリザーブドインスタンスと同じインスタンスタイプに変更する
ちなみに、今回は対象のインスタンスは弊社の基幹となるサーバなので、インスタンスタイプを変更することは難しいことがわかりました。
なので変更はおこなっていません。
4. 適用されていないリザーブドインスタンスのインスタンスクラスを調べる
調べたところ、リザーブドインスタンスの提供クラスによっては変更、交換ができるようなので、これができるかを検討してみました。
どうやら
のようです。
今回購入したリザーブドインスタンスは、、、
「Standard」*3
インスタンスサイズしか変更できないようです。
5. 変更可能であれば、リザーブドインスタンスのインスタンスサイズを変更する
インスタンスサイズを変更できる条件は下記サイトに載っていました。
5.1. インスタンスサイズの大きいリザーブドインスタンスを購入してしまった場合
例えば、以下のケースです。
c3.xlargeではなく、c3.2xlarge を購入していた
c3.2xlargeを2つの c3.xlarge に分割できることがわかったので欲しかった c3.xlarge を手に入れることはできます。 ただし、1つの c3.xlarge が余ってしまいますので、手順6を参照してください。
5.2. インスタンスサイズの小さいリザーブドインスタンスを購入してしまった場合
例えば、以下のケースです。
(1) m3.2xlargeではなく、m3.xlargeを購入していた
m3.xlargeをもう一つ購入することでm3.2xlargeとして使えるかと思いましたが、以下の記載の通り、追加購入すると終了日時が一致しないため変更は無理なようです。
インスタンスサイズの変更は、他の属性詳細 (リージョン、使用タイプ、テナンシー、プラットフォーム、終了日時など) が一致し、利用可能な容量がある場合にのみ許可されることに注意してください。
こちらも手順6を参照してください。
6. 常時起動しているインスタンスを調べる
常時起動しているインスタンスの中に購入したリザーブドインスタンスと同じインスタンスタイプのものがあればめでたく解決なのですが、おそらく「1. リザーブドインスタンス適用状況を確認する」で適用されていないことを確認した時点で多分ないんだろうと思います。
その場合、常時起動しているインスタンスの中に購入したリザーブドインスタンスと性能の近いインスタンスがあれば、リザーブドインスタンスタイプに合わせて変更してしまうのが良いかと思います。
例えば、c3.xlargeのリザーブドインスタンスが余っている場合、常時起動のm3.largeのインスタンスをc3.xlargeに変更すれば、スペックを落とさずに料金を安くすることができます。 この場合、年額$200弱のコストを削減できます。
| インスタンスタイプ | vCPU | ECU | メモリ | インスタンスストレージ | 年間料金(オンデマンド) | 年間料金(リザーブド) |
|---|---|---|---|---|---|---|
| m3.large | 2 | 6.5 | 7.5 | 1 x 32 SSD | $1,690.68 | $950.00 |
| c3.xlarge | 4 | 14 | 7.5 | 2 x 40 SSD | $2,233.80 | $1,505.00 |
まとめ
Amazon EC2のリザーブドインスタンスを誤って購入したときの対処法について説明しました。 いろいろ書きましたが、「3. 対象のインスタンスのインスタンスタイプが変更可能であれば変更する」の時点でAWSのサポートの方に問い合わせるのが一番いいです。最適なリカバリー方法を教えてくれるかと思います。
誤ったものを購入すると面倒くさいことになってしまうのでみなさんもお気をつけください、という注意喚起の記事でした。それでは。
