既存プロダクトのAWSコストを診断する観点と削減の優先順位
「先月よりAWSの請求がまた増えている」——事業が成長しているならまだしも、トラフィックはほぼ横ばいなのに費用だけが右肩上がり、という相談を経営者の方からよく受けます。誰かが意図的に無駄遣いしているわけではなく、サービスを立ち上げた当初の構成のまま、リソースを見直す機会がなかっただけというケースがほとんどです。
クラウド費用は「使った分だけ」課金される仕組みのため、一度膨らんだコストは自然には縮みません。誰かが意図的に診断し、削減の判断をしない限り、右肩上がりのまま固定費化していきます。この記事では、既存プロダクトのAWSコストを診断するときに私たちが実際に見ている観点と、可用性を落とさずに削減する優先順位を、発注者・経営者向けに整理します。
AWSコストが増える典型的な原因
まず、なぜコストが膨らむのかを知っておくと、診断の勘所が掴みやすくなります。
- オーバープロビジョニング: サービス立ち上げ時に「念のため大きめ」に選んだEC2やRDSのインスタンスサイズが、実際の負荷に対して過大なまま放置されている
- 使っていないリソースの放置: 検証用に立てたEC2、削除し忘れたEBSボリューム、開発が終わった環境のRDS、紐付いていないElastic IPなど、誰も使っていないのに課金され続けているリソース
- RDS/EC2のサイズ過大: ピーク時の負荷を基準にサイズを決めたまま、平常時の余剰キャパシティを削っていない
- データ転送費(NAT Gateway・リージョン間通信): 見落とされがちだが、NAT Gateway経由の通信やS3からの転送量が積み上がって高額化しているケースは多い
- ログ・バックアップの肥大: CloudWatch Logsのライフサイクル設定がなく無期限保存、RDSのスナップショットが世代管理されず溜まり続けている
- Savings Plans / リザーブドインスタンス未活用: 常時稼働のリソースをオンデマンド料金のまま払い続けている
これらは単発の原因ではなく、複合的に積み重なって「気づけば倍になっていた」という結果を生みます。だからこそ、個別のアラートではなく棚卸しとしての診断が必要になります。
まず何を見るか(診断の入り口)
診断は感覚ではなく、数字から入ります。
- Cost Explorerでサービス別・期間別の内訳を見る: どのサービス(EC2・RDS・S3・データ転送等)が費用の何割を占めているか、直近3〜6ヶ月の推移とともに確認する。ここで「増加している項目」が特定できれば、調査範囲を絞り込める
- タグ付けの状況を確認する: 環境別(本番/検証)・機能別にコストを分解できるタグが付いているか。タグが無いと「どのリソースが何のために存在するか」が分からず、削除判断ができない
- Trusted Advisor / Compute Optimizer の推奨事項を確認する: AWSが標準で出している「使用率が低いインスタンス」「アイドル状態のリソース」の指摘は、無料で得られる一次情報として有用
- 請求書の明細を月次で並べる: 急に増えた月がないか、増加のタイミングと機能リリース・トラフィック増加のタイミングが一致しているかを突き合わせる
この段階で「何にいくら使っているか」を可視化するだけでも、経営判断の材料としての価値があります。多くの現場では、この可視化自体がこれまで行われていません。
削減の優先順位(可用性を落とさず削る)
診断で見えた無駄を、闇雲に削るとサービス障害のリスクを高めます。私たちは次の順番で着手します。
1. 誰も使っていないリソースの削除(リスクほぼゼロ)
停止したまま課金され続けているEC2、紐付いていないEBS/EIP、用途不明で放置されたRDSインスタンスなど。稼働への影響がないため、真っ先に削減できる対象です。
2. ライフサイクルポリシーの設定(即効性が高く低リスク)
CloudWatch Logsの保持期間設定、S3のライフサイクルルール(古いオブジェクトをGlacierへ移行または削除)、RDSスナップショットの世代管理。一度設定すれば継続的にコストが下がり続けます。
3. インスタンスサイズの見直し(要負荷検証)
CPU・メモリ使用率の実測データを基に、EC2やRDSのインスタンスタイプをダウンサイジングする。ここは「削って終わり」ではなく、ピーク負荷時に問題が出ないかの検証が要るため、テスト環境での負荷試験や段階的な変更を挟みます。可用性への影響が出やすい領域なので、監視体制を整えたうえで進めるのが鉄則です。
4. Savings Plans / リザーブドインスタンスの適用(中長期の固定費削減)
常時稼働することが確定しているリソース(本番のEC2・RDS等)に対して、1年〜3年のコミットメントで単価を下げる。将来の構成変更予定がある場合はコミット期間とのバランスを見る必要があります。
5. アーキテクチャレベルの見直し(効果は大きいが工数もかかる)
NAT Gatewayの構成見直し、S3のリージョン間転送を減らす設計変更、キャッシュ層(CloudFront・Redis)の導入によるオリジンへのアクセス削減など。効果は大きいものの、設計変更を伴うため計画的に進める領域です。インフラの構成そのものに手を入れる話になるので、既存の構成を壊さない段階的な移行計画が必須になります。
この順番で進めることで、「すぐ効く・リスクが低い」施策から着手し、リスクの高い変更は検証を挟んでからという進め方ができます。逆に、負荷特性を理解しないままいきなりインスタンスをダウンサイジングすると、ピーク時にレスポンス遅延や障害を招くことがあります。実際、コスト削減目的の見切り発車な変更が原因で障害が増えるケースも見てきました。障害が頻発している状態からの改善については、障害が多いWebサービスを改善する優先順位でも詳しく解説しています。
外部に診断を頼むという選択肢
自社にインフラ専任のエンジニアがいない、あるいはいても日々の開発に追われて棚卸しの時間が取れない、という状態であれば、外部への診断依頼は合理的な選択です。
外部診断のメリットは、しがらみなく「今の構成が本当に必要か」をゼロベースで問い直せることです。社内の担当者は「昔決めた構成には理由があったはず」という前提から離れにくく、見直しが後回しになりがちです。第三者が入ることで、その慣性を断ち切れます。
進め方としては、まず1〜2週間程度でCost Explorerの内訳・リソースの棚卸し・アーキテクチャの現状把握を行い、削減余地と概算のインパクト・リスクをレポートにまとめます。その上で、実際の削減作業(リソース削除・ライフサイクル設定・サイジング変更等)を継続的な改善支援として進めるかを判断していただく、という二段階が現実的です。
まとめ
- AWSコストの増加は、オーバープロビジョニング・使っていないリソースの放置・ログ肥大などが複合的に積み重なった結果であることが多く、まず「何にいくら使っているか」の可視化から着手すべき
- 削減は「誰も使っていないリソースの削除」のような低リスクな施策から着手し、インスタンスのダウンサイジングなど可用性に影響しうる変更は負荷検証を挟んで段階的に進める
- 自社に棚卸しの時間や専任者がいない場合、外部の第三者診断で「今の構成が本当に必要か」をゼロベースで見直すのが効率的
torcheees では、既存プロダクトのAWSインフラを対象にした開発診断や、継続的な改善支援を提供しています。まずは現状の構成とコスト内訳を一緒に確認するところから始められます。既存プロダクトの改善全般については既存プロダクトの改善、外部チームが最初に見る観点もあわせてご覧ください。お問い合わせフォームからお気軽にご相談ください。