AWSの請求額が売上の伸びより速く増えている、というチームに向けた内容です。クラウド費用の最適化に取り組もうとして、かえってエンジニアの手を止めてしまう失敗パターンを整理し、やり直す手順を示します。
対象は10人から200人規模のエンジニア組織で、AWSを中心にKubernetes（コンテナを複数台のサーバーに配置・管理する基盤）を使っているケースです。プラットフォームチームやDevOpsリードの判断材料になれば幸いです。
何が起きるか：コスト削減が開発速度を奪う
コスト削減の取り組みを始めると、よくある症状が出ます。
インスタンスサイズを上げたいだけなのに、申請チケットが必要になります。
エンジニアは承認を待つ間に苛立ち、次からは最初から大きめのスペックを確保するようになります。
結果として、承認プロセス自体が無駄遣いを助長します。
もう一つの症状はダッシュボードです。
「EC2の費用が先月比18%増」という数字だけを見せられても、誰が何をすればいいか分かりません。
オーナーが不明なまま、グラフだけが更新され続けます。
棚卸しスプリントも典型的な失敗です。
2週間かけて不要リソースを削除し、請求額は下がります。
しかし半年後には元に戻ります。
リソースを作る仕組み自体を変えていないためです。
最も深刻なのは、準備不足のまま削減を急ぐケースです。
十分な検証なしに過度なライトサイジング（適正サイズへの縮小）やSpotインスタンス（余剰キャパシティを安く使える代わりに中断リスクがある購入形態）導入を進めると、障害が発生します。
一度でも障害が起きると、組織全体に「コスト削減は本番環境を壊す」という学習が刻まれてしまいます。
なぜ起きるか：原因を段階的に分解する
根本原因は、コストを「許可が必要な特別な作業」として扱ってしまうことです。
非機能要件としてのコストを、可用性やセキュリティと同じように設計に組み込めていない状態です。
1つ目の原因は順序の誤りです。
無駄を削除する前に割引契約（Savings Plansなど、一定期間の利用を約束する代わりに単価を下げる購入方式）を結んでしまうと、削除予定だった無駄なリソースにまで割引適用の前提が固定されます。
2つ目の原因は可視化の欠如です。
費用がチームやサービスに紐づいていない状態だと、誰が責任を持つリソースなのか分からなくなります。
オーナーのいない費用は、放置されたまま固定費になります。
3つ目の原因はガードレール（逸脱を防ぐ仕組み）を後回しにすることです。
可視化もできていない段階でポリシーだけ強制すると、エンジニアは「なぜこの制約があるのか」を理解できないまま従うことになります。
納得のない制約は形骸化しやすく、長続きしません。
FinOps Foundation（クラウド財務管理の実践知を整理する団体）は、このサイクルをInform（把握）、Optimize（最適化）、Operate（運用に組み込む）の3段階で説明しています。
順番を守らずOptimizeやOperateから着手すると、今回挙げたような失敗パターンに陥りやすくなります。
自分のプロジェクトが該当するか確認する
具体的な確認ポイントは次の通りです。
- AWS Organizations（複数アカウントを一元管理する仕組み）で本番と非本番の環境がアカウント単位で分かれているか
- Cost Allocation Tags（費用をチームやサービス単位で集計するためのタグ）が全リソースに付与されているか
- AWS Cost Anomaly Detection（異常な支出増加を自動検知する機能）やBudgets（予算超過をアラートする機能）が有効になっているか
- EBSボリュームでgp2（旧世代のSSDタイプ）のまま運用している数と、未アタッチのボリューム・古いスナップショットの残数
- CloudWatch Logsのロググループに保持期間（retention）が設定されているか、無期限のままかどうか
確認コマンドの例として、未アタッチのEBSボリュームはAWS CLIで次のように確認できます。
aws ec2 describe-volumes \
--filters Name=status,Values=available \
--query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType}' \
--output tableここに大量の行が出てくる場合、削除し忘れたボリュームが費用を発生させ続けている可能性があります。
Kubernetesを使っている場合は、Pod（コンテナの実行単位）のresource requests（必要リソースの申告値）が実際の使用量と大きく乖離していないかも確認してください。
申告値が過大だと、ノードのオートスケーリングが過剰に働き、無駄なノードが立ち上がり続けます。
対策の手順：30/60/90日で立て直す
| 期間 | 目的 | 主なアクション |
|---|---|---|
| 1〜30日目 | 可視化とリスクゼロの無駄削減 | コスト配分タグ有効化、異常検知設定、未アタッチボリューム削除、ログ保持期間設定、gp2からgp3へ移行、非本番の営業時間外停止 |
| 31〜60日目 | 無駄を生む設定の是正 | Kubernetes requestsの適正化、ノード統合の有効化、耐障害性のあるワークロードへのSpot導入、S3ゲートウェイエンドポイント追加 |
| 61〜90日目 | 料金固定とドリフト防止 | 整理後の基盤にSavings Plans適用、プルリクエストへのコスト見積もり表示、タグとTTL（有効期限）のポリシーコード化、週次のチーム別レポート開始 |
最初の30日間は、プラットフォームチーム1〜2名だけで完結する作業に絞ります。
機能開発チームの手を止めずに実行できる範囲です。
31日目以降は、サービスオーナーにrequests値のレビューを依頼する程度にとどめます。
承認フローやチケット待ちを発生させないことが要点です。
90日目以降のガードレールは、Policy as Code（ポリシーをコードとして定義し自動チェックする手法）として実装します。
タグ必須化やTTL強制をCI/CDパイプラインやTerraform（インフラをコードで定義するツール）のチェックに組み込むことで、人の承認を介さずに逸脱を防げます。
週次レポートも、チームに新しい会議を増やすのではなく、既にSlackやメールで届く通知に乗せる形が望ましい形です。
コスト削減の取り組みが「追加業務」に見えた時点で、定着は難しくなります。
まとめ：確認すべきことと次の一歩
コスト削減が開発を遅らせるかどうかは、順序と仕組み化で決まります。
承認ゲートやチケット待ちを増やす前に、可視化と自動化で無駄そのものを消せないか検討してください。
次に取れる一歩として、まず前述のAWS CLIコマンドで未アタッチボリュームの数を確認してみてください。
想定より多ければ、タグ付けとCost Anomaly Detectionの設定から着手する価値があります。
割引契約の検討は、無駄の削除が終わってからで十分です。
ガードレールをコード化する段階まで到達すれば、コストは一時的な削減ではなく、設計の一部として維持される状態に近づきます。