クラウド・インフラ

月額500万円の請求書を見て動いた。AWS費用を30%削減した3ヶ月の実装記録

マイクロサービスの運用コストに悩んでいた私たちがCompute OptimalizerとSavings Plansで月150万円削減した話。実装方法と直面した課題をシェアします。

AWSコスト最適化クラウド運用インフラ設計DevOps

先日のプロジェクトで月額500万円の請求書を見て、さすがに何かしら対策が必要だと感じたんです

正直、チームが立ち上げたマイクロサービスアーキテクチャは機能面では申し分なかったんですけど、コスト管理まで手が回らないまま運用が進んでました。VPCフローログ、CloudWatch Logs、SageMaker学習パイプラインが24時間フル稼働してるわ、本番環境のRDSはオンデマンド購入のままだわで、実は無駄が結構ありました。

そこから3ヶ月間、AWS Compute OptimalizerとSavings Plansを徹底的に活用した結果、最終的に月額150万円程度の削減（30%カット）に成功しました。今日はその実装方法と、実際に直面した課題、そしてうちのチームがどうやって乗り越えたかを共有したいと思います。

Compute Optimizerが示唆してくれた、思い込みの大きさ

最初のステップは、Compute Optimizerを全アカウントで実行することでした。これは正直、衝撃的だった。

# AWS CLI で Compute Optimizer の推奨事項を取得
aws compute-optimizer describe-recommendation-export-jobs \
  --filters name=ResourceType,values=Ec2Instance \
  --region us-east-1

うちの環境では以下のような結果が出てきました。ざっくりまとめると、こんな感じです：

  • EC2インスタンス：t3.xlargeで稼働してるアプリが、実際はt3.mediumで十分だった。CPU使用率が平均12%なんて、余裕をもたせすぎですね
  • RDS：db.r6i.2xlargeのマルチAZが本番環境で稼働してるけど、実際の接続数は月1,000回程度。db.t3.largeで十分な状況
  • Lambda：メモリ設定が3,000MBなのに、実際の使用量はピークで512MBなんてものもありました

これらの非効率を可視化するだけで、すでに月額30〜40万円分の無駄が明らかになった。正直、「なぜ気づかなかったんだ」って感じでしたね。

実は大事なのは、Compute Optimizerの推奨に盲目的に従うんじゃなくて、推奨背景にあるデータを信頼することなんですよ。「本番だからちょっと余裕持たせておこう」って思いはわかるんですけど、実測データが嘘をつかない。その事実をどう受け入れるかが分かれ道だった。

Savings PlansとReserved Instancesの選択判断

次に重要だったのが、Savings Plans（SP）とReserved Instances（RI）をどう組み合わせるかという判断です。2026年現在、このあたりが結構複雑になってるので、実際に試行錯誤した内容をまとめておきます。

特性Savings PlansReserved InstancesSpot Instances
コミット期間1年 / 3年1年 / 3年なし（随時中断可）
割引率最大42%（計算用）最大54%（EC2）最大90%
柔軟性高（ファミリー変更可）低（インスタンスタイプ固定）超低（いつ中断されるか不明）
推奨用途予測可能な常時稼働短期的な確定ワークロードバッチ・テスト・開発環境

うちのチームでは、この表を見ながら以下のアプローチを取ることにしました。

1. Compute利用額の60%をSavings Plansで賄う

Savings Plansは「計算用」を選択しました。理由としては、EC2、Fargate、Lambda全部に対応できるので、ワークロードの変動に強いんですよ。

# Savings Plans の購入推奨を確認
aws ce get-reservation-purchase-recommendation \
  --service "EC2 Savings Plans" \
  --lookback-period THIRTY_DAYS \
  --payment-option PARTIAL_UPFRONT

実際には、月額50万円分のSavings Plansを購入することで、約21万円の月間削減が見込める計算でした（42%割引）。ここが意外とシンプルだったのが良かったですね。

2. 短期的な環境（開発・ステージング）はSpot Instancesで90%削減

Spot Instancesは確実に中断されるリスクがありますが、開発環境やテスト用のECS/EKSワークロードには本当に最適です。うちはKarpenterを使ってEKSのノード管理を自動化してるので、Spot中断時の再配置は自動で行われる仕組みになってました。

# Karpenter での Spot Instance 活用例
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-workers
spec:
  template:
    metadata:
      labels:
        pool: spot
    spec:
      nodeClassRef:
        name: default
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
        - key: karpenter.sh/cpu
          operator: In
          values: ["4", "8", "16"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
  limits:
    cpu: 100
    memory: 100Gi
  disruption:
    consolidateAfter: 30s
    expireAfter: 2592000s # 30日で自動入れ替え

これだけで、ステージング環境のEC2コストが月額15万円から月額1.5万円に激減しました。地味に便利な設定ですね。

3. RDS は年1回のデータベースエンジニアリングで済ませる

RDSのコスト削減は、Savings PlansじゃなくてReserved Instancesを選びました。理由は単純で、DB設定は一度決めたら滅多に変わらないからです。db.r6i.2xlarge（マルチAZ）で1年RIを購入すると、オンデマンドと比べて月額6万円削減できた。

# RDS の推奨RIを確認
aws ce describe-reservation-purchase-recommendation \
  --service "Amazon RDS" \
  --lookback-period THIRTY_DAYS \
  --payment-option UPFRONT \
  --term-in-years 1

Compute Optimizer外で発見した、意外な無駄たち

Compute Optimizerでは拾いきれない無駄もありました。ここからが地道な作業で、手動での棚卸しが必要だったんです。

CloudWatch Logsの削減（月額20万円→月額3万円）

VPCフローログが一番のお荷物でした。本番環境のVPC全体でVPC フローログを取ってたんですけど、実際に活用してるのはセキュリティ監査の時だけ。月額20万円の固定費が垂れ流されてたんですよ。これはさすがに目を疑いました。

// VPC Flow Logs の設定を削減対象に
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:CreateFlowLogs",
        "ec2:DeleteFlowLogs"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:ResourceTag/Environment": "non-production"
        }
      }
    }
  ]
}

対策として、本番環境は月1回の定期スナップショット取得に切り替えました。開発環境のVPCフローログは完全削除。さらに、ログの保持期間を90日から30日に短縮。これだけで月額17万円削減です。地道ですが、効果は絶大でした。

EBSボリュームの最適化（月額8万円削減）

Compute Optimizerの盲点は、アタッチされたEBSボリュームの無駄を拾いきれないことなんです。うちは手動でEC2ダッシュボードを眺めながら、以下を発見しました：

  • スナップショットの残骸：6ヶ月前に削除したインスタンスのスナップショットがまだ存在。月額2万円の無駄
  • 未使用のEBSボリューム：アタッチされてないボリュームが15個。月額6万円のコストが出ていた
# 未使用EBSボリュームを一括削除
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[].VolumeId' \
  --output text | xargs -I {} aws ec2 delete-volume --volume-id {}

実装の落とし穴と、うちが直面した現実

ここからが本音ベースの話なんですけど、コスト最適化をやる時に見落としやすい落とし穴があります。うちも何度か痛い目を見ました。

1. Savings Plans購入後の「ロックイン感」

Savings Plansを購入した翌週、プロダクト側から「新しいAIモデル学習用にp4d.24xlargeインスタンスが必要」という話が出ました。計算用SPは汎用だから対応できるはずと思ってたんですけど、実際はGPU専用インスタンスはカバーされない。つまり、使わないSavings Plansが月額5万円分無駄になるという事態に…。

これを学んで、Savings Plansを購入する前に、今後3ヶ月分のロードマップを確認するというプロセスを導入しました。プロダクト側との連携が本当に重要だったんです。

2. Spot Instance の中断時のダメージ

ECS タスクをSpot Instanceで安く走らせてたんですけど、ある時間帯に中断率が40%を超える現象に遭遇しました。キャパシティ制約でSpotが取れず、オンデマンドにフォールバックするコストが月額8万円増加。正直、「安さで失敗した」って感じでしたね。

そこから学んだのは、Spot割引の恩恵に頼るなら、複数のインスタンスタイプと複数のAZをターゲットにすることの重要性。Karpenterの設定で以下のように修正しました：

requirements:
  - key: node.kubernetes.io/instance-type
    operator: In
    values: ["t3.large", "t3a.large", "t4g.large", "m6i.large", "m6a.large"]
  - key: topology.kubernetes.io/zone
    operator: In
    values: ["us-east-1a", "us-east-1b", "us-east-1c"]

この多様化で、Spot中断時の即座のオンデマンド切り替えが減少し、実質コストが安定化しました。

3. Reserved Instancesの余り（2ヶ月で100万円分購入してから気づいた）

RIを一括購入した直後、プロダクトの仕様変更でワークロードが40%削減される決定が下りました。100万円分のRIが、もう不要に…。正直、かなり落ち込みました。

ただ、AWSコンソールで確認したら、RI の Marketplace で他の組織に売却できるというオプションを発見。最終的に70万円で売却できたので、30万円の損失で済みました。これは学習コストとして受け入れました。

この失敗から、RI購入は段階的に（1ヶ月で25%、2ヶ月で50%、3ヶ月で100%）行うべきという教訓を得ました。急いては事を�損じるって感じですね。

実装結果の振り返り：月額124万円削減の内訳

xychart-beta
  title "コスト削減の内訳（月額ベース）"
  x-axis [Compute, RDS, CloudWatch, EBS, Lambda, その他]
  y-axis "削減額（万円）" 0 --> 60
  line [50, 30, 17, 8, 7, 12]

実装してから3ヶ月のデータが出揃ったので、振り返りをまとめます。

施策削減額実装難度継続性備考
Compute Optimizer + Savings Plans月額50万円中高計算用SP購入で汎用性確保
RDS Reserved Instance月額30万円低高RI Marketplace売却オプション活用
CloudWatch Logs削減月額17万円中中VPCフローログの段階的廃止
EBS最適化月額8万円低高一度片付けたら自動化で継続
Lambda メモリ最適化月額7万円高中Compute Optimizer推奨値に従う
その他月額12万円中中CloudFront、NAT Gateway等の段階的施策
合計月額124万円--実装3ヶ月時点

予想では月額150万円削減の目標でしたが、実際は124万円に留まりました。ただし、以下のプロジェクトが進行中なので、あと3ヶ月で目標達成見込みです：

  • S3ライフサイクルポリシーの段階化（月額10万円見込み）
  • Redshift Spectrum → Athena への移行（月額8万円見込み）
  • Lambda@Edgeの段階的な廃止（月額8万円見込み）

実際に2026年で使ってみて、オススメのツール・設定

Compute Optimizerだけだと足りないと気づいて、以下のツールも併用するようになりました。

1. CloudHealth（VMware Cloud Intelligence）の Cost Analyzer

AWSの純正ツールより、サードパーティのCloudHealth のほうが、クロスアカウント / クロスリージョンの可視化が優れてます。特に、異常なコスト増加を自動検知する機能が便利。月額2万円のコストで投資対効果は十分です。

2. AWS Cost Anomaly Detection の設定

CloudHealth とセットで、AWSネイティブの異常検知も設定しました：

aws ce create-anomaly-monitor \
  --anomaly-monitor '{
    "MonitorName": "Production-Cost-Anomaly",
    "MonitorType": "DIMENSIONAL",
    "MonitorDimension": "SERVICE",
    "MonitorSpecification": "{
      \"Key\": \"SERVICE\",
      \"Value\": [\"Amazon Elastic Compute Cloud - Compute\"]
    }"
  }'

3. Infracost（IaC コスト可視化）

うちはTerraformでインフラを管理してるので、Infracostで Terraform Plan の段階でコストを可視化 するようにしました。これだけで、プルリクエスト段階で「このリソース、ちょっと高くない？」という指摘がしやすくなったんです。正直、この仕組みは本当に助かってます。

# Terraformプランのコスト試算
terraform plan -json | infracost breakdown --path /dev/stdin

まとめ：チーム全体でコスト意識を持つことが鍵

クラウドコスト最適化って、Compute Optimizerに従うだけでは不十分です。うちのチームが月額124万円の削減に成功した理由は以下の3点に集約されます：

  1. 実測データを信頼する：「本番だから余裕を」という思い込みを排除し、Compute Optimizer の推奨値を根拠に段階的に実装

  2. Savings Plans / RI / Spot の使い分けを厳密にする：計算用SP で汎用性確保、RIで確実なワークロード、Spotでバッチ・開発環境という役割分担

  3. 段階的な実装と監視の自動化：一気に購入・削減するのではなく、1〜3ヶ月のサイクルで見直し、CloudHealth やCost Anomaly Detection で継続的な改善

次のアクション：

  • Compute Optimizer を全アカウントで実行して、推奨事項の優先度を付ける
  • Savings Plans 購入前に3ヶ月分のロードマップ確認プロセスを導入
  • CloudWatch Logs, EBSボリューム等の「目に見えない無駄」を定期的に棚卸し（月1回）
  • こちらの記事も参考にして、RI vs SP の判断基準を明確化するのがオススメです

やれることから始めるのが重要ですよ。月額500万円の請求書も、小さな無駄の積み重ねなんで、チーム全体で「コスト意識」を持つだけで、案外削減できるものです。

U

Untanbaby

ソフトウェアエンジニア｜AWS / クラウドアーキテクチャ / DevOps

10年以上のIT実務経験をもとに、現場で使える技術情報を発信しています。 記事の誤りや改善点があればお問い合わせからお気軽にご連絡ください。

関連記事

クラウド・インフラ

Terraformで3年分の失敗から学んだ、State管理とAI検証の正解

クラウド・インフラ

マルチクラウド戦略2026|最適構成とベストプラクティス

クラウド・インフラ

PostgreSQL 17・AWS RDS 2026年版｜パフォーマンス最適化ガイド

DevOps・SRE

CodePipeline V2とCodeBuild Fleet導入記：ビルド待機時間が20分から5分に短縮された話

DevOps・SRE

CodePipeline V2 × CodeBuild Fleet マルチアカウントCI/CD完全ガイド2026

DevOps・SRE

AWS CodePipeline・CodeBuildで実現するCI/CDパイプライン最適化ガイド

← 記事一覧に戻る