はじめに
とあるWeb開発の案件に、データまわりの助っ人として途中から入りました。
8年物のEC2（特級呪物）が莫大なキャッシュを抱えて動いている現場です。
それぞれが何のために動いているのか、誰も全体像を説明できない。
構成図はない。最初に作った人はもういない。それでもコストだけは、毎月しっかり出ていく。
これを何とかコストを減らしてくれと言われました。
結論から言います。READ ONLYに絞ったIAMを握ってClaudeと一緒にAWS CLIを叩き、無駄を片っ端から洗い出した結果、最終的に毎月数千ドル規模のコストを削れました。
ただ——正直に書くと、技術的に「削る」こと自体は今や驚くほど簡単です。本当に難しくて、本当に価値があったのは、まったく別のところにありました。今日はその話をします。
対象読者
AWSをある程度触る中級エンジニア。「請求は気になるけど、どこから手をつければいいのか分からない」という人に向けて書いています。
「触ると壊れる」と言われたAWS
引き継ぎのとき、前任に近い立場の人からこう言われました。「そのへんは触ると壊れるかもしれないので、できれば触らないでください」と。
気持ちは分かります。動いているものを下手にいじって本番を落としたら最悪です。でも、その「触らないでおこう」が何年も積み重なった結果が、目の前のブラックボックスでした。誰も中身を知らないから、誰も消せない。消せないから、ずっと課金が続く。
最初は私もコンソールをぽちぽち眺めていました。けれど画面を1枚ずつ開いていくやり方では、全体像がまったく頭に入ってこない。EC2の画面、RDSの画面、VPCの画面、CloudWatchの画面——情報がバラバラの引き出しに散らばっていて、つなげて考えられないんです。ここで一回、心が折れかけました。
READ ONLYのIAMを握って、Claudeと棚卸しを始めた
方針を変えました。コンソールを眺めるのをやめて、AWS CLIで端から構造をダンプし、その出力をClaudeに渡して解釈してもらう、というやり方にしたんです。
このとき最初にやったのが、READ ONLY権限だけのIAMユーザーを用意することでした。これが地味に効きました。
理由は2つあります。ひとつは当然、セキュリティ。万一CLIの操作をミスしても、参照しかできない権限なら本番を壊しようがない。もうひとつは——これが意外と大きかったのですが——心理的な安心感です。「壊せない」と分かっているからこそ、躊躇なくアカウントの隅々まで踏み込んで調べられた。守りに入る設定が、結果的に攻めの調査を可能にしてくれたわけです。
調査やコスト分析のためにCLIを叩くなら、まずは最小権限の参照専用ロールから。「とりあえずAdministratorAccess」で始めると、ミスがそのまま事故に直結します。
Claudeとの進め方はシンプルでした。CLIで取れた一覧（インスタンス、ボリューム、ピアリング、ロググループ……）をそのまま貼り付けて、「これは何をしている構成だと思う？」「次はどこを見れば無駄が見つかりそう？」と相談していく。私が手を動かして事実を集め、Claudeがそれを解釈して仮説と次の一手を出す。この往復が、めちゃくちゃ捗りました。
頭の中でようやくつながってきた全体像は、ざっくりこんな形でした。
手書きに毛が生えた程度の図ですが、ここまで描けて初めて「どこが怪しいか」が見えてきます。
出てきた"無駄"たち
棚卸しを進めると、想像以上にいろいろ出てきました。代表的だったものを4つ紹介します。仕組みの部分は執筆時点の情報なので、金額や正確な条件は後述の公式ページで確認してください。
使ってないのに動き続けるインスタンス
一番分かりやすかったのがこれ。どのアプリからも参照されていないのに起動しっぱなしのEC2が、複数いました。さらにやっかいなのが、停止していても残り続けるEBSボリュームや、誰も使っていないElastic IP、過去に取ったきり放置されたスナップショット。「停止したから大丈夫」と思い込んでいるリソースが、裏で静かに課金され続けていたんです。
存在しないものを見続けるダッシュボードとログ
これは見つけたとき、思わず「うわ」と声が出ました。とっくに削除されたリソースを監視対象にしたまま残っているアラームやダッシュボードが、エラーでもなく正常でもなく、ずっと宙ぶらりんの状態で課金され続けていた。観測する対象がもう存在しないのに、観測のコストだけ払い続けている状態です。
ロググループも同じで、保持期間が「Never Expire（無期限）」のまま放置されていると、出力されたログが永久に消えず、ストレージ課金がじわじわ積み上がっていきます。1つあたりは小さくても、数が積もるとボディブローのように効いてくる。
こじれたVPCピアリングが生む転送コスト
ここは少し技術的です。VPCピアリング自体の接続料は無料で、同一AZ内の通信もタダ。けれど、AZをまたぐ通信には双方向で転送料がかかります。リージョンをまたげばさらに高い。
このアカウントでは、本来なら同じAZ内で完結できたはずの通信が、構成のこじれでAZをまたいで流れていました。つまり、払わなくていい転送料を毎日垂れ流していた、というわけです。ピアリングは「つなげば動く」ので、コスト面の歪みは動作だけ見ていても気づけません。
サポート終了バージョンに乗り続ける追加課金
最後がこれ。RDSなどで標準サポートが切れたエンジンバージョンを使い続けていると、自動的に延長サポート1へ加入扱いになり、通常のインスタンス料金に上乗せで追加課金が発生します。リザーブドインスタンスの割引も効きません。
怖いのは、この上乗せが「ただ古いまま放置している」だけで発生し続けること。バージョンを上げれば止まるのに、誰も上げないから払い続けている。動いてはいるので、誰も問題だと認識していませんでした。
歴史を知らない新参者は勝手にインフラ変更をしない
ここが、この記事で一番伝えたいところです。
無駄を見つけると、つい「よし、消そう」となります。READ ONLYで調べていたので私自身は消せませんでしたが、もし強い権限を持っていたら、勢いで消していたかもしれない。
でも、それは絶対にやってはいけませんでした。
インフラのリソースは、パッと見「消して良さそう」でも、間違えて消すと大インシデントになります。表からは見えない依存関係や、誰かのバッチ処理、定期的にだけ動く隠れた利用者——「使われていないように見える」と「使われていない」は、まったくの別物です。
そこで私がやったのは、見つけたものを全部GitHubのIssueに起こすことでした。「このインスタンスは何日間アクセスログがない」「このピアリングはこのAZ間で課金が出ている」「このDBは延長サポート対象になっている」——事実と根拠をセットで、ひとつずつ。
そのうえで、インフラ担当とWebエンジニアを巻き込みました。私が「これ、消して良さそうに見えるんですけど、依存ってありますか？」と投げると、Webエンジニアが「あ、それ月初のバッチだけ使ってます」と返してくれる。インフラ担当が「そのピアリング、歴史的経緯があって……」と背景を教えてくれる。
ひとりで完結していたら、確実にどこかでやらかしていました。本当に。
その現場の歴史を知っている人にヒアリングすることは特に重要です
やってみて分かったこと
3週間ほどの棚卸しで、最終的に削れたコストは毎月数千ドル規模になりました。数字だけ見れば成功談です。でも振り返ると、学びはそこじゃなかった。
CLIのコマンドを組み立てるのも、大量の出力を解釈するのも、コストの仕組みを調べるのも、Claudeと一緒にやれば一瞬でした。技術的なハードルは、生成AIによって本当に下がっています。「どう調べるか」「どう直すか」は、もはやボトルネックではない。
では何が残るのか。「これは無駄なんじゃないか」と問題に気づき、それを言語化してIssueとして提起し、関係者を巻き込んで安全に行動に移すこと。ここだけは、AIが代わりにやってはくれませんでした。
問題を見つけても、提起しなければ誰にも届かない。提起しても、ひとりで突っ走れば事故になる。技術的な解決が簡単になったいまだからこそ、価値はそっち側——発見し、提起し、巻き込んで動かす——にまるごと移ったんだと、今回しみじみ感じました。
おわりに
もしあなたの手元にも「触ると壊れる」と言われ続けている謎のインフラがあるなら、まずはREAD ONLYのIAMをひとつ作って、AIと一緒に棚卸しから始めてみてください。きっと「うわ」と声が出るものが見つかります。
そして見つけても、ひとりで消さないこと。それが今回、数千ドルより大事だった学びです。
似たような棚卸しをやった人がいたら、どんな"無駄"が出てきたか、ぜひ教えてください。
参考
-
標準サポート終了後も、重要なセキュリティ修正やバグ修正を受けながら旧バージョンを使い続けられる有償プログラム。MySQL 5.7 や PostgreSQL 11 などが対象で、年数が経つほど単価が上がる設計になっている。 ↩