AWSのコスト削減方法として4つ説明しましたが、稼働しているサービスに影響を与えることのない、リザーブドインスタンスの購入が手をつけやすいと思います。
AWSから詳しいドキュメントや説明の動画資料がでているので、リザーブドインスタンスがどういったものであるかは、そっちを確認してください。
ここではどう適用するかというところを見ていきます。プロジェクト/サービスそれぞれの事情があるので、この記事の内容がそのまま当てはまらないかもしれませんが、やり方を考えるヒントになればと思います。
手続きだけで割引料金になる
メリット。プログラムやシステム構成には手を入れる必要がないというのは、とても導入しやすいです。また、費用が安くなるよう、AWS側で適用インスタンスなどを調整してくれます。
逆に、費用の調整は請求単位で行われるので、「プロジェクト単位で計上する必要があるから、アカウントを分けてー」とやっていても、一括請求の設定がしてある場合、アカウントをまたがって費用の調整が行われます。つまり、リザーブドインスタンスの手続きを行っていないアカウントのインスタンスに対して、割引料金が適用されることもあります。厳密に費用の按分を行う必要があるのであれば、請求ダッシュボードから請求データをダウンロードして、コツコツ計算する必要があります。
契約期間中は使わなくても費用が発生する
リザーブドインスタンスの契約は1年か3年です。全額または一部を前払いするか、前払い無しで契約することができますが、契約期間中は払い続ける必要があります。使わなくなっても、契約期間中は料金が発生します。
また、期間中に料金改定があったとしても、契約時点での料金のままで払い続ける必要があります。値下げは何度か行われているので、頭の片隅には入れておくべきでしょう。
年に1回しか検討しないのはアンチパターン
契約していたリザーブドインスタンスの期限が迫ってきた/期限が切れたので契約を検討するというのは、手抜きです。
リザーブドインスタンスは何件でも申し込めるので、状況が変わるたび、少なくとも月1回はどうするか検討すべきでしょう。
- 先月ローンチしたサービス、順調だから少なくとも○カ月は現在のインスタンス数より少なくなることはない。
- リプレースプロジェクト、やっぱり遅延していて、あとxカ月は現在のシステム構成で続ける必要がある。
- 競合が現れたあのサービス、巻き返しもうまくいっていないから、クロージングの時期をそれとなく聞いておこう。
いつ、何台必要になりそうかというのが、リザーブドインスタンスを検討する上で重要な情報になります。
契約時期をずらしてリスク分散
毎月検討していれば実現できているはずです。
プロジェクト中止でのインスタンス停止や、事業成長によるインスタンスのスペックアップで、予定よりも早く使わなくなることがあります。
契約時期がずれているということは、当初予定していたよりも早く期限が来る契約が存在しているということですから、見直すタイミングが早く来ることになります。リスク分散ですね。
コンバーティブルタイプを使う
普通のスタンダードタイプで申し込むと、インスタンスファミリー(t3とかm5とか)を契約期間中に変更することはできません。
コンバーティブルタイプで申し込むと、割引率が少し悪くなる代わりに、インスタンスファミリーを変更できるようになります。
といっても、費用が同じか増える方向にしか変更できないので、安いインスタンスタイプに変更する場合、台数を増やす必要があります。
サービスが成長しているときは1つの手だと思いますが、マネージドサービスが出てきてそちらに切り替える場合、インスタンスが余ることになってしまいます。スポットインスタンスで運用できるよう、プログラムを改修した時も起こり得る話ですね。
マーケットプレイスで売買する
契約期間が余ってしまったら、マーケットプレイスで売ってしまうこともできます。逆に、1年よりも短い契約期間のものを買うこともできます。
マーケットプレイスを使わせない方針の会社もあるので、この方法を使う場合は経理など関係者に相談しておいた方がいいと思います。
EC2だけでなくRDSも
リザーブドインスタンスはRDSにもあります。マネージドサービスで、かつ本番サービスであればMulti-AZ配置にするでしょうから、リザーブドインスタンスでのコスト削減効果は大きいです。
コスト削減にはこまめな見直しが必要
リザーブドインスタンスによるコスト削減方法を取り上げてみました。
AWSは料金を安くする方法がいろいろありますが、ズボラだと高くなりがちです。安くしたいのであれば、それなりに手間をかけましょう。
コメント