AWSにおけるコスト削減の考え方

Advent Calendar 2025 AWS

こんにちは、インフラエンジニア の 森田です。

この記事はEnigmo Advent Calendar 2025の4日目の記事です。
BUYMAは8月に本番環境を移行しており、その後コストのチューニングを行っています。
この記事では実際に進めた内容を元に自分のAWSにおけるコスト削減の考え方と役立つ機能について紹介します。

サマリ

まず最終的なゴール設定ですが、リザーブドインスタンスやSavings Plans等利用量をコミットしてコスト削減を行えるモデルの購入とします。
また今回は分かりやすいよう主要なサービスであるEC2とRDSでのコスト削減をターゲットとします。

大枠では次のような流れでAWSのコスト削減を考えています。

  1. サイジングを考える
  2. 利用状況の変化を考える
  3. コストコミットを考える

次項からそれぞれで検討すべき項目と、それに利用できるAWSの機能を紹介します。

1. サイジングを考える

まずそのインスタンスに適切なリソースが割り当てられているかを考えていきます。
AWSのような従量課金のサービスにおいて一定のタイミングで現在の状況にあったリソースが割り当てられているかを考える事は重要です。
利用状況を超えたリソースの割り当ては余計な支出を生みますし、リソースが不足していればサービスの安定稼働の妨げとなってしまいます。
そのためインスタンスタイプを適切に割り当てたいなと思うわけですが、種類が多すぎて何が適切なのかの検討が難しい場合もあります。

そこで参考にできるのがAWS Compute Optimizerです。
Compute Optimizerは機械学習を用いてAWSリソースの利用状況を分析し、コスト削減やパフォーマンス向上に繋がるレコメンドを提示してくれるサービスです。

画像のようなイメージでインスタンスごとに適切か否か、否なら何が適切かを提示してくれるのでサイジングの参考にして下さい。

ただ注意しないといけないのはこれはあくまでオススメするインスタンスタイプであり、動作の保証はされないという事です。
肌感覚ですが、カスタマー利用があり負荷が一定でないWebやAppサーバ等でこのレコメンドの通りにサイジングを行うのはかなり危険だと思います。
実際にコスト削減のためアプリケーションサーバのインスタンスタイプをレコメンドよりも一回りバッファを持たせたサイズへ下げたものの、高負荷となってしまうケースがありました。 この時は1台だけ下げたインスタンスを組み込むという計画だったため即切り戻しが可能でしたが、やはり負荷の一定でないインスタンスの変更は慎重に行うべきであるということです。 逆に社内サービス等負荷がおおよそ一定になる用途のものに関してはかなり参考にできるかなと思っています。

2. 利用状況の変化を考える

次にそのインスタンスの利用状況の見通しを考えましょう。
AWSのコストコミット類の最小期間は1年であるため、1年程度見通せると良いかと思います。
大まかには以下の点を検討する形になるかと思います。

  • この用途のインスタンスは向こう1年以上利用するか

  • 1年以内にOS、DBエンジンのEOS・EOLが発生するか

OS、DBエンジンのEOS・EOLはHealth Dashboardなどが参考にできます。

OSやDBエンジンのバージョンはリザーブドインスタンスやSavings Plansで縛られないものの、
バージョンアップ後に負荷が上がる可能性はあるので、もし1年以内に発生する場合はインスタンスタイプの変更含めて検討が必要です。

3. コストコミットを考える

リザーブドインスタンス

EC2でもリザーブドインスタンスを購入することは可能ですが、インスタンスファミリーやOSの変更にも対応できる柔軟性を考慮すると、EC2には後述するSavings Plansを利用するのを推奨します。
そのため、ここでのターゲットは主に RDS とします。
※ただし直近でRDSのSavingsPlansもGAとなっているため、今後はこちらも合わせて検討するのが良いと思います。

RDS RI購入の考え方

RDSの台数が少なければ、前述の検討内容を元に手動で個別に購入して問題ありません。
しかし、台数が多い場合はAWSコンソールの推奨機能を活用します。

Billing and Cost Management > 予約 > 推奨事項

ここでも「1. サイジング」と「2. 利用状況の変化」での検討が重要になってきます。
単に現状の通りにRIを購入するのではなく、無駄なリソースを排除し、EOS対応などの将来的な再構築リスクがないことを確認した上で推奨事項を見ることで、「推奨＝購入すべき正解」 という状態を作り出せるからです。

インスタンスサイズの柔軟性について

また、RDSのRI購入を後押しする要素として 「インスタンスサイズの柔軟性」 があります。
MySQL、MariaDB、PostgreSQL、Oracle、Aurora を利用している場合、同じインスタンスファミリー（例: db.r6g）内であれば、サイズ（large や xlarge 等）が変更されてもRIの割引が適用されます。 (ライセンスを含む場合は柔軟性の対象外となる点に注意して下さい)

これにより、「今は db.r6g.large が適切だが、半年後に負荷が増えて db.r6g.xlarge にスケールアップするかもしれない」といったケースでも、RIが無駄になりません。
この仕様があるため、ファミリー自体の変更（例: r6g → r7g）さえ発生しない見通しが立っていれば、比較的安心して1年/3年のコミットを行うことができます。

不要なリソースは削除済み、かつ将来のファミリー変更リスクも検討済みであれば、推奨事項に表示されている台数・期間で購入を進め、割引効果を最大化させましょう。

Savings Plans

EC2に関しては、リザーブドインスタンスよりも柔軟性が高い Savings Plans、その中でも Compute Savings Plans の利用を推奨します。
Compute Savings Plansであれば、インスタンスファミリー、サイズ、AZ、リージョン、OS、テナンシーが変わっても割引が適用されるため、構成変更に非常に強いのが特徴です。

こちらもRDS同様、AWSコンソールで推奨事項を確認できます。
Billing and Cost Management > Savings Plans > 推奨事項

ここで前項までの「1. サイジング」と「2. 利用状況の変化」の検討が活きてきます。

通常、この推奨事項は過去の利用実績に基づいて算出されるため、無駄なリソースが放置されている状態で見ると、過剰なコミット額が提案されてしまいます。
しかし今回は、既にサイジングで見直しを行い、将来的な利用期間（1年以上など）も精査済みです。
つまり、現在稼働しているリソースは「必要なリソース」のみに絞り込まれている状態と言えます。

そのため、ここでの戦略はシンプルです。

  1. Compute Savings Plans を選択する
  2. 期間は「利用状況の変化」で確認した期間（基本は1年）を選択する
  3. 表示された推奨事項の 時間単位のコミットメント を信頼して購入する

事前にしっかりとリソースの棚卸しができているからこそ、迷いや過度なマージン（リスクヘッジによる減額）を入れることなく、提示された最適解で購入を進めることができます。
これが結果として、無駄なく最大のコスト削減効果を生むことに繋がります。

まとめ

今回は「サイジング」「利用状況の変化」「コストコミット」の3ステップで進めるAWSコスト削減について紹介しました。

コスト削減というと、どうしても「とりあえずリザーブドやSavings Plansを買う」という手段が先行しがちですが、その土台となるシステムの見直しや将来予測が不十分だと、効果が薄れたり逆に無駄が発生したりするリスクがあります。
今回紹介したように、しっかりと足元（現状の利用量）と未来（これからの構成）を整理した上でAWSのレコメンド機能を活用すれば、迷うことなく最大限のコミットメントが可能になります。

インフラコストの最適化は、一度行えば終わりではなく継続的な運用が重要です。
ぜひこの機会に、皆様の環境でもCompute Optimizerや推奨事項をチェックし、攻めのコスト管理にチャレンジしてみてください。

明日の記事の担当は データアナリストの 井原さんです。お楽しみに。