[登壇資料] 「3ヶ月で月額300万円削減 ─ AWSコスト削減プロジェクトのリアル」についてお話しました #devio2026

こんにちは。クラウド事業本部のおつまみです。

2026年10月24日に DevelopersIO 2026 TOKYO にて「3ヶ月で月額300万円削減 ── AWSコスト削減プロジェクトのリアル」というタイトルで登壇しました。ご参加いただいた皆さま、ありがとうございました！

AWSのコスト削減というと、どのサービスのどの設定を変えるか、という技術の話になりがちです。
ただ、実際にプロジェクトを進めてみると、一番の壁になったのは技術ではなく「消していいか」の承認でした。

本記事では、実際に効果が大きかったコスト削減の手法と、承認の壁をどう越えたかを、登壇資料とあわせて紹介します。

登壇資料

内容サマリー

• 2〜4月の3ヶ月のプロジェクトで月額約224万円を削減し、その後スナップショット削除の効果が通年で効いて、最終的に月額約300万円の削減になった
• 効果が大きかったのは、WorkSpacesの料金モードの見直し、EBSのgp3変換、古いスナップショットの削除
• 一番の壁は技術ではなく承認で、最初の削除が承認されるまで2〜3週間かかった
• 承認が遅い原因は、お客様が慎重だからではなく判断材料がないからだった。付帯情報・週次定例・安全に消す段取りで乗り越えた

対象環境とプロジェクト体制

対象は、BtoBのECサイトを運営されているお客様のAWS環境です。2014年からAWSを使い始め、今はほぼ100%クラウドで運用されています。

課題は2つありました。

1つ目は、リソースの要否が分からないことです。
十数人が自由にインスタンスを立ち上げられる状態で、テスト用に作ったまま放置されたものや、退職された方が作ったものが積み重なり、「これは誰のものか、消していいのか」が分からなくなっていました。

2つ目は円安です。AWSはドル建てなので、何もしなくてもコストが増えていきます。

体制はシンプルで、クラスメソッドからは私1名、お客様は3名です。
お客様のうち2名がご担当者として現場での確認を、1名が部長として作業の承認を担当されました。

役割分担は、お客様が優先順位の決定・社内の調整・削除の承認、私たちが調査・手順書の作成・AWS上での実作業です。
「消していいか」を決めるのはお客様、私たちは判断を支えて実行する側、という分担で進めました。

結果

先に結果です。

3ヶ月のプロジェクト終了時点で、月額約224万円を削減しました。
その後、スナップショット削除の効果が通年で効いてきて、最終的に月額約300万円の削減になっています。

なお、サービス別に見ると、RDSやAmazon Connectなどは業務の拡大で増えていました。
削減した分の一部がこの増加で相殺されるので、請求額の差だけを見ると、実際の削減効果より小さく見えます。

削減項目の洗い出しと優先度

まずコストアセスメントで、削減できる項目を洗い出しました。
使ったのは、Trusted Advisor、Compute Optimizer、Cost Optimization Hub、それから社内ナレッジです。

項目ごとに、実行の負担とコスト効果は私のほうで評価し、優先度はお客様と一緒に決めました。

ポイントは、負担が小さく効果が大きいものから着手したことです。
WorkSpacesの料金モードやgp3への変換は、負担が小さく効果が大きいので優先度を高くしました。逆に、インスタンスタイプの見直しは効果は大きいものの負担も大きいので、優先度を低くしています。

実施した削減手法

ここでは、効果が大きかった3つを紹介します。

WorkSpaces の料金モードの見直し

WorkSpacesには、月額固定のAlwaysOnと、使った時間だけ課金されるAutoStopがあります。Standardタイプでは、月85時間以上使うならAlwaysOnのほうが安くなります。

過去3ヶ月の利用時間を調べると、長時間使っているのにAutoStopのものが45件、ほとんど使っていないのにAlwaysOnのものが18件ありました。
一覧に「変更可否」の列を用意して部門の管理者に記入していただき、承認が出た翌日にまとめて変更しています。

注意点として、AutoStopへの変更は翌月からの反映になります。

EBS の gp2 → gp3 変換

gp3は、gp2より容量あたりの単価が約2割安く、IOPSとスループットを容量と切り離して設定できます。

1TB以上のボリュームは、CloudWatchで読み書きの量と回数を見て、個別に性能を確認しました。
16TBのファイルサーバー用ボリューム4本は影響が大きいので、1本だけ先に変換し、1週間モニタリングしてから残りの3本を変換しています。

スナップショット削除

スナップショットの費用は月に約1万ドルあり、そのうち約4分の1が古いものでした。10年以上前のものも残っていました。

削除条件は定例でお客様と合意し、「作成から1年以上経っている」かつ「Nameタグがない」ものにしました。
抽出スクリプトで一覧にしてお客様に確認していただき、dry-runで対象を確かめてから削除しています。

この効果が通年で効いてきたことが、プロジェクト終了後に224万円から300万円まで伸びた主な理由です。

承認の壁

ここからが登壇の本題です。

プロジェクトを進める中で、一番の壁になったのは承認でした。
削除候補の一覧をお渡ししてから、最初の削除が承認されるまでに2〜3週間かかっています。3ヶ月のプロジェクトでの2〜3週間なので、決して短くはありません。

お客様にとっては本番環境で、安全性が最優先です。止まっていること自体は当然だと思っていました。
ただ、対象は停止中のEC2が50台以上、スナップショットが数百件と大量で、1件ずつ社内で確認していただくのは大きな負担です。

そこで気づいたのが、承認が遅いのは、お客様が慎重だからではなく、判断する材料がないからということです。

リソースIDと月額だけが並んだ一覧を渡されても、「これ消して大丈夫？」には答えられません。
だったら、その問いに答えられる情報を、こちらで先回りして用意しよう、と考えました。

工夫1：付帯情報を付けて承認しやすくする

削除候補の一覧に、判断材料になる情報を付けていきました。

• 停止中のEC2：最初に起動した日時と経過日数、最後に停止した日時（StateTransitionReasonの「User initiated」の日時から抽出）
• RDS：CloudWatchのDatabaseConnectionsで1ヶ月と半年の接続数
• ELB：トラフィックの有無
• スナップショット：経過日数とNameタグの有無

一覧には「削除可否」と「備考」の列を用意して、お客様に記入していただく形にしました。

中でも特に効いたのが、作成者の情報です。作成者が分かれば、ご担当者が本人に確認するだけで済みます。

ただ、CloudTrailのイベント履歴は、コンソールで検索できるのが直近90日までです。
この環境ではCloudTrailのログがS3に保管されていたので、それをDuckDBで直接検索して、作成者や操作者を特定しました。
Athenaも選択肢でしたが、コスト削減のプロジェクトで調査のためにコストを増やしたくなかったので、手元のDuckDBを使っています。

参考：

https://dev.classmethod.jp/articles/analyze-aws-cloudtrail-events-with-duckdb/

工夫2：週次30分の定例で担当者と直接話す

短期間で削減できた最大の要因だと思っているのが、週1回30分の定例です。

毎回、削除候補の一覧と対応状況を最新にしてから臨み、その場でご担当者の疑問を解消しました。
よく聞かれたのは「最悪、何が起きるのか」「リカバリー策はあるのか」です。これにその場で答えられると、判断がその場で進みます。

承認が出たものは、定例の数時間後には削除して、完了報告まで行いました。

工夫3：安全に消す段取り

削除前の保険と、段階的な変更でリスクを抑えました。

• 削除前にAMIやスナップショットを取得し、約1ヶ月保持する
• dry-run付きのスクリプトで、実行前に対象を確認してから流す
• 影響が大きいものは、1本先行して様子を見てから残りを進める

副次効果

コスト以外の効果もありました。

gp3に変えたことで、夜間バッチの処理時間が約3分の2に短縮されました。
ディスクの書き込みがネックだと分かっていながら半分あきらめていた部分だったそうで、お客様からは「予想外のうれしい驚き」という声をいただいています。

ほかにも、WorkSpaces Cost Optimizerで月次レポートを自動化し、停止しても7日で自動起動してしまうRDSは、EventBridge Schedulerで自動停止するようにしました。

まとめ

• 負担が小さく効果が大きい施策から着手する
• 承認が遅いのは、慎重だからではなく判断材料がないから
• 「誰が、いつまで使っていたか」を先回りして調べ、一覧に付けて渡す
• 削除前の保険と段階的な変更で、安全に消す段取りをつくる

今回のプロジェクトは、お客様の声を含めて事例記事として公開されています！

https://classmethod.jp/cases/plus-cost/

最後に

今回は「3ヶ月で月額300万円削減 ── AWSコスト削減プロジェクトのリアル」というタイトルで登壇した内容を紹介しました。

コスト削減は技術の話になりがちですが、今回やってみて本当に難しかったのは、「消してよいか判断する材料をつくること」と「安全に消す段取りをつくること」でした。

皆さんの環境でも、消せそうなのに消せていないリソースがあれば、まずは「誰が、いつまで使っていたか」を調べるところから始めてみてください！

以上、おつまみ(@AWS11077)でした。