AWSプロジェクトのリプレイスに伴うコスト削減の一例

公開日:2025/12/15

はじめに

AWS を使ってサーバー構築を行っている場合でも、時間の経過とともにさまざまな要素が古くなっていきます。たとえば、サーバーOSやミドルウェアのバージョン、AWSの機能追加に伴うベストプラクティスの変化などです。

この度、AWS 上で長期間運用されていたプロジェクトに対してセキュリティアップデートが必要となり、それに合わせてインフラ全体の刷新（リプレイス）も実施しました。その結果、AWS のランニングコストを大きく削減できました。

本記事では、今回の削減事例をもとに「どこでコストが発生していたのか」「どのような見直しで削減できたのか」を整理し、同様の課題を抱えるプロジェクトの参考となるポイントを紹介します。

削減概要

今回のセキュリティアップデートおよびインフラ全体のリプレイスにより、AWSのランニングコストを約50%削減できました。あわせて、コスト最適化と運用性向上を目的に、インフラ構成の一部を見直しています。

主な削減ポイントは効果の大きい順に次の 3 点です。

MySQL 8.0 対応（MySQL 5.7 の延長サポート終了に伴うアップグレード）
オートスケーリング可能な構成への変更（アプリケーション改修＋インフラ側のスケーリング対応）
サーバーボリュームの設計方針（構築戦略）の見直し

MySQL 8.0 対応

一番コスト削減額が大きかったのが、このデータベース周りの見直しでした。

Amazon RDS では、標準サポートが終了したメジャーバージョンを継続利用する場合、RDS 延長サポート（Extended Support）の追加料金が発生します。たとえば RDS for MySQL 5.7 は 2024 年 2 月 29 日に標準サポートが終了しており、以降は延長サポート扱いとなります。また Aurora 側も同様に、Aurora MySQL 互換エディションバージョン 2（MySQL 5.7 互換）は 2024 年 10 月 31 日に標準サポート終了となり、以降は延長サポートへ移行しています。

今回の環境は MySQL 5.7 互換（Aurora MySQL v2）を利用していたため、この延長サポート料金が無視できない水準になっていました。

対応の選択肢

この問題を解決するには「延長サポート料金が発生するバージョンを使い続けない」ことが必要です。

（基本推奨）Aurora/RDS のエンジンを標準サポート対象のバージョンへアップグレードする
可能であれば記事執筆時点の最新 LTS バージョンである MySQL 8.4 互換の Aurora を採用したかったのですが、記事執筆時点ではMySQL 8.0 互換（Aurora MySQL v3）が最新バージョンであったため、MySQL 8.0 対応としています。
（例外的な回避策）RDS/Aurora をやめて EC2 上で自己管理する
“延長サポート料金だけを緊急回避したい” といった事情がある場合、EC2（Docker 等）でバージョン固定運用に切り替えることも可能です。ただし、あくまで「可能」なだけであって、RDSが提供しているバックアップ・監視・可用性・パッチ適用などのメリットを捨てることになります。運用責任が増えるため、こちらの回避策を採るかどうかは運用保守しているサービスの特性に合わせた慎重な判断が必要です。

実施上の注意点

データベースのバージョンアップ自体は手順としては単純ですが、SQL の互換性や挙動差分の影響でアプリケーションが正常に動作しなくなる可能性があります。したがって、インフラ側だけで完結せず、アプリケーション側の検証・改修を含めた開発チームの協力が不可欠です。

また、延長サポート課金は「更新しないまま長期運用すると、追加料金でコストが押し上がる」設計になっている点に注意が必要です。
そのため、RDS/Aurora を採用する場合は、少なくとも 3〜5 年に 1 度は「次のメジャーへ上げる」前提で更改計画と検証体制を組む（＝ソフトウェア側の対応も含めて予算化・スケジュール化する）ことが、長期的なコスト最適化の観点でも重要だと言えます。

オートスケーリング可能な構成への変更

今回対象のシステムは、ピークが発生する時期をあらかじめ予測できる特性がありました。一方で、システムがモノリシックに構築されていたため、負荷対策としてサーバーのスペックアップ（スケールアップ）を行うことは可能でも、作業手順が煩雑になりやすい状況でした。

そこで今回は、オートスケーリングが可能なインフラ設計へ見直し、特定時間のスケジュールに合わせてサーバー台数を増やす（スケールアウトする）ことで、ピーク時の処理を安定して捌けるようにしました。加えて、想定外に負荷が跳ねた場合でも、オートスケーリングによって短時間で負荷に追従できる構成とし、耐障害性の向上にもつなげています。

導入にあたっては開発チームと議論しながら進め、いくつか想定外の挙動が見つかったためアプリケーション側の修正も必要になりましたが、最終的には問題なく導入できました。また、通常時・ピーク時の双方で事前に負荷試験を実施し、当初想定よりピーク時向けにインスタンススペックを一段階上げる判断は発生したものの、全体としては概ね想定どおりに導入を完了できました。

サーバーボリュームの設計方針の見直し

元々のインフラ構成では、サーバーボリューム（EBS）が大きめに確保されていました。これは、オンプレミス時代や AWS 初期の設計では「将来の増加に備えて最初から多めに確保する」ことが一般的だったためです。一方で、現在では EBS のボリュームサイズは運用中に拡張できるため、必要十分な容量から始めて、必要に応じてサイズを増やす運用にすることでコスト最適化がしやすくなっています。

重要なのは、EBS サイズ変更では拡張はできるものの縮小はできない点です。将来的に容量を増やせる前提で初期サイズを抑えつつ、拡張が必要になったタイミングでボリュームを拡張する運用に切り替えることで、無駄な確保分の課金を避けられます。
また、料金はリージョン・ボリュームタイプによって変動しますが、EBS は「GB/月」で課金されるため、たとえば 100GB と 20GB の差（80GB）は月あたり数ドル〜十数ドル程度の差になり、台数が増えると無視できない金額になります。

今回の環境では、ディスク使用量が大きく見えていた要因の多くがログファイルなどの整理・圧縮が可能なデータでした。そこで、ログの保存方針を見直してディスクの常時使用量を抑えたうえで、オートスケーリング対応の観点からも、画像・動画などのファイルは Amazon EFS で共有（共通マウント）する形に変更し、インスタンスごとに大容量ディスクを持たなくてもよい構成にしました。

結果として、開発環境を含めた EBS 利用量はおおむね 1/6 程度まで削減でき、ボリュームコストの削減につながりました。