はじめに
サービス開始後、時間が経つにつれ肥大化するAWSのコスト。
とうとうその金額に白羽の矢が立った為、AWSのコストを削減する９の方法 を実際に試したので、その実施内容を紹介します。
1. 未使用状態のAmazon EC2やAmazon RDS インスタンスへの支払いを止める
効果が最も高かったのがこれです。すぐに着手すべき最強の一手でした。
EC2のスケジューリング
DEV環境やSTG環境は平日夜間・休日は使用しないしない為、平日日勤のみ起動するようにしました。
Auto Scalingで管理していたので、Auto Scaling のスケジュールに基づくスケーリングを利用しました。また、公式にAWS Instance Schedulerというものがあるのでこちらを利用しても良いかもしれません。
RDSのスケジューリング
こちらもEC2同様、平日日勤のみ起動するようにしました。
RDSインスタンスの起動停止はboto3によるRDSインスタンスの起動停止を行うLambdaを作成し、cloudwatch eventで定期実行させています。
2. Amazon DynamoDB にはオンデマンドのキャパシティーモードを利用する
DynamoDBの課金形態は「オンデマンドキャパシティー」という使った分だけ費用が発生するものと、「プロビジョニング済みキャパシティー」という予め需要予測を行い、指定したキャパシティに応じて費用が発生するものの2種類があります。
今回は、費用対リクエストの観点でクラスメソッドさんのDynamoDBのオンデマンドとプロビジョニングの料金を比較をしてみたを参考にコストを見積もり、
- オンデマンドキャパシティーを利用
- プロビジョニング済みキャパシティーにてキャパシティ容量を最適化
の2種類で対応しました。
3. 十分に活用されていないEC2インスタンス(RDSインスタンス)への支払いを止める
インスタンスタイプが需要に対して過剰に設定されているインスタンスのダウンサイジングを実施しました。
資料中には「CPU使用率が 40% 未満」が一つの目安として挙げられており、こちらを参考にしています。
RDSインスタンスも同様にダウンサイジングを行ましたが、EC2に比べこちらの方が効果は大きいように感じています。
理由の一つとして、RDSインスタンスはEC2インスタンスに比べ1インスタンスあたりの料金が高いことがあるのではないかと思います。
4. 十分に活用されていないネットワークリソースを削除する
不要なELB、EIP の削除を実施しました。
各AWSコンポーネントはコードで管理していたのですが、EIPはコード管理していなかった為、一時的に取得されたものや不要になったものが存在していました。
5. Savings Plans、リザーブドインスタンスを利用する
常時起動前提のインスタンスはスケジューリングによる停止ができない為、Savings Plans及びリザーブドインスタンスの利用によりコストを削減しました。
Savings Plansは昨年発表された新しい割引プランですが、リザーブドインスタンスとの使い分けとして以下の使い分けができそうです。
EC2インスタンス、Fargate、Lambda -> Savings Plans
RDS、Redshift、ElastiCache、Elasticsearch -> リザーブドインスタンス
まとめ
AWSコストはEC2インスタンスとRDSインスタンスの占める割合が多いことを改めて感じさせられました。
闇雲に手を付けて工数対削減費用効果が弱くなることを懸念していた中で今回の要点は良かったように思います。
日々のコスト管理もできるようにしたいですね！
参考文献
この記事は以下の情報を参考にして執筆しました。