💰
AWSのコストを30万円/月 削減した話
はじめに
私が2024年6月以降に着任した、既存システムと新システムにおけるAWSコスト最適化施策について共有します。
結果として、約30万円/月以上のコスト削減が見込める試算となりました。
背景
主な業務は下記の2軸でした。
- 既存システムの保守運用・改善活動:長期間運用している環境に対するコスト最適化やリソースの見直し
- 新システムのインフラ開発:より効率的な設計や構成の導入によるコスト削減施策
当初、AWS上で運用しているシステムが多く、それらに割り当てられたリソースの中には不要なものや過剰なものが多く存在していました。新規システムはまだ開発段階であったため、設計段階からコスト最適化の視点を取り込むことが可能でした。
以下で実際に行った施策と、その結果削減できたおおよその金額を紹介します。
コスト削減施策(既存システム編)
1. 利用していないEIP(Elastic IP)の解放
対応前の状況:
- どのEC2にも関連付けられていないEIPが8個存在。
施策内容:
- 未使用EIPを全て解放。
効果:
- 8個で約3,000円/月程度の削減ができました。
2. 用途不明EC2インスタンスの削除 (t2.micro 3台・Cloud9の残骸)
対応前の状況:
- 3台のEC2インスタンス(t2.micro)が稼働中だが用途不明。
- 調査したところCloud9環境構築時に作成され、そのまま放置されていた模様。
施策内容:
- 安全性確認後、3台のEC2インスタンスをバックアップ後に全削除。
効果:
- t2.microは1台あたり約800~900円/月程度(※概算)のコストがかかっていたため、3台で約2,500円/月程度の削減が可能となりました。
3. 未使用EBSのバックアップと削除
対応前の状況:
- 割り当てられたまま未使用のEBSが3つ存在。
施策内容:
- スナップショット取得後、不要と判断して削除。
効果:
- トータルで約1,000円/月程度の削減ができました。
4. 不要データを蓄積していたS3の見直し (Storage Lensで分析)
対応前の状況:
- 約80TB以上の大容量データがS3上に保管。
- AWS Storage Lensで分析したところ、解析用Athenaクエリでメモリ溢れ時の一時データ(
athena-spill
)としてS3が利用され、不要データが大量蓄積していたことが判明。
施策内容:
- Athenaクエリ設定とワークフローを見直し、
athena-spill
と想定される不要データを削除。 - ライフサイクルポリシー導入により定期的な不要データ削除も実施。
効果:
- S3コストは80TBに達していたため、不要データ削除で最低200,000円/月以上の大幅削減に成功しました。
↑削除実施以降の日時コスト
5. DynamoDBのプロビジョニングモード見直し
対応前の状況:
- プロビジョンされたキャパシティが実際の要求より大幅過剰。
施策内容:
- スループット要件を再評価し、適正なプロビジョン値に設定。
効果:
- 約20,000円/月程度のコスト削減ができました。
6. CloudTrail・CloudWatchログ出力間隔・保管期間の調整
対応前の状況:
- ログをほぼデフォルト設定で長期間保存。
- 必要以上のログを長期保管しておりコスト増。
施策内容:
- ログ出力頻度や保持期間を短縮し、必要最低限のデータのみ保持。
効果:
- 約5,000円/月程度のコスト削減に成功しました。
7. Lambdaメモリチューニング
対応前の状況:
- メモリ過剰割当によりLambda実行コストが増大。
施策内容:
- 実行時間・必要メモリを再分析し、適正メモリ値へ調整。
効果:
- 約3,000円/月程度のコスト削減ができました。
コスト削減施策(新システム編)
1. ElastiCacheのサーバレスモードから非サーバレスモードへ移行(1台)
対応前の状況:
- サーバレスモードは柔軟だが、一定の負荷・リクエストパターンでは割高に。
施策内容:
- ワークロードを分析し、固定的なノードタイプ(cache.t3.micro)を用いた構成に変更。
効果:
- 約3,000円/月程度のコスト削減ができました。
2. NAT Gateway利用を極力抑えた構成の設計
対応前の状況:
- dev・stg・prd環境全てにNAT Gatewayを配置(prdの冗長構成含め計5台)。
- NAT Gatewayは時間課金+転送料が発生しコスト増要因。
施策内容:
- VPCエンドポイントを積極的に活用する設計に変更し、最終的にprd環境も含めてNAT Gatewayを使用しない構成へ移行。
効果:
- dev・stg・prd環境全てのNAT利用を停止することで、約70,000円/月程度のコスト削減が可能となりました。
3. 週末利用のないシステムのスケジュール停止
対応前の状況:
- dev・stg・prd問わず、常時EC2やRDSが起動状態。
施策内容:
- Lambdaによるスケジュール起動/停止を実装。
- 週末など利用のない期間にEC2やRDSを停止。
- EC2(t3.small): 約1,500円/月削減
- RDS(db.t3.small): 約4,000円/月削減
(合計で約5,500円/月程度削減)
効果:
- インスタンス台数に比例して削減額増加。現状で約5,500円/月程度のコスト削減。
総合的な効果
上記の各種施策を合計すると、
- EIP削減: 約3,000円/月
- 不要EC2削除(Cloud9残骸): 約2,500円/月
- 未使用EBS削除: 約1,000円/月
- S3不要データ削除: 最低200,000円/月
- DynamoDB再設定: 約20,000円/月
- CloudTrail/CloudWatch調整: 約5,000円/月
- Lambdaメモリ調整: 約3,000円/月
- ElastiCache最適化: 約3,000円/月
- NAT Gateway削減: 約70,000円/月
- 週末停止: 約5,500円/月
合計で約30万円/月以上(約313,000円/月程度)の削減を実現しました。
対応策
- AWS Budgetsを使用して一定のコストを上回った場合、首脳陣 + 私に通知する仕組みの追加
- AWS Cost Anomaly Detectionを使用してコストの異常を首脳陣 + 私に通知する仕組みの追加
まとめ
今回の取り組みで、クラウド環境においてリソースの「放置」がいかにコスト増を招くかを再認識しました。特に、Terraformによるインフラ構成管理を導入し、環境構築からリソース棚卸しまで「コード化」することで、リソース状態を継続的・定期的に把握しやすくし、適切な運用改善サイクルを回せるようになります。
これらの施策が、AWSコスト最適化を検討されている方々の参考になれば幸いです。
Discussion