経緯
社内ツールやシステムを開発・運用していく中で、AWSの月額利用料がじわじわ高騰しており課題に感じていました。
ちょうどデスクトップ版のCodexと、AWSからプレビュー版のMCP（Model Context Protocol）が公開されたことを知り、「ブラックボックス化しているAWS環境でどこまで手間をかけずにコスト最適化できるのか」を試してみたのでまとめておきます。
イメージがつきやすい様に実際の指示とCodexが実行した内容を貼っておくので参考にしてください。
前提
対象は、過去に在籍していた社員が構築したBI用途のAWS環境です。
ドキュメントも残っておらずブラックボックス化してしまっていたのですが、社内ツール用の環境なので万が一失敗してもサービス影響は出ないことから試してみるにはちょうどいい環境でした。
- 旧BI基盤以外にも小さなツールが複数稼働している
- 依存関係や影響範囲が読みにくく、見直しが後回しになっていた
- AWS各サービスの概要理解と基本操作はできるが、専門的な知識はない
- できる限り楽をしたいけどリスクは負いたくない
やったこと
1. CodexにAWS MCPを追加
下記を参考にCodexにMCPサーバー（カスタムサーバー）を追加しました。
AWS MCPではuvxを利用するため、インストールしておきます。
すでにインストールされている方はスキップしてください。
$brew install uv
$uvx --version
uvx 0.10.0 (Homebrew 2026-02-05)
設定後、Codexに対して簡単な指示を行いMCPが有効になっているかどうかを確認しました。
（さらっと上手くいったかのように書いてますが、ここまで来るのに一番時間かかってます。。）
現在利用しているAWSサービスを教えて
ーーー
AWS MCPで実アカウントを照会した結果、2026-02-10時点で現在利用が確認できた主なAWSサービスは以下です（主に ap-northeast-1）。
Amazon EC2（インスタンス 3）
AWS Lambda（関数 7）
Amazon S3（バケット 11、グローバル）
AWS Systems Manager Parameter Store (SSM)（パラメータ 12）
AWS Step Functions（ステートマシン 2）
Amazon ECR（リポジトリ 3）
Amazon ECS（クラスター 1）
Amazon RDS (Aurora PostgreSQL)（DBクラスター 1）
Amazon CloudWatch Logs（ロググループ 21）
補足ですが、プレビュー版のAWS MCPはusリージョンでのみ提供されていますが、複数リージョンを跨いで利用することができます。
2. Codex経由で利用状況を棚卸し
やりたいことをCodexに指示するだけで自立して調査をしつつ、稼働しているサービスやコスト状況をわかりやすくNotionに纏めてくれました。
セキュリティ上この資料を公開することはできませんが、私の知識程度でも理解できる内容になっており、スムーズに進めることができました。
現在AWSの利用料が高騰していて不要なリソースを削除したいと考えてる
まずはどのようなリソースがあるのかと、それらの利用状況を確認して一覧化して。
可能ならnotion-mcpを使って1ページにまとめて欲しい
ーーー
了解しました。まずAWS MCPでコストに効く主要リソースを横断取得し、利用状況（稼働状態・最近更新・サイズ系）まで整理します。その後、Notionページを取得して同じ内容を追記します。
ページは空で取得できました。次に、コスト影響が大きいサービス（EC2/EBS/RDS/ECS/Lambda/S3/ECR/Logs/Step Functions）の実リソースと利用指標をまとめて収集します。
追加で「利用状況」を出すため、ECS/Step Functions/Lambda/CloudWatch Logs/EFS/VPCエンドポイントの稼働指標を収集します。
さらに精度を上げるため、Step Functionsの実行履歴、ECSサービス2件の詳細、ALBの実利用指標（リクエスト）を取得します。
利用実績の列を作るため、直近（2026-02-01〜2026-02-10）のLambda/Step Functions/ALBの実行回数メトリクスを取得します。
Step Functionsの利用状況も同じ期間で数値化します（開始回数・失敗回数）。
S3はコスト寄与が大きいため、全バケットの容量メトリクス（BucketSizeBytes）をCloudWatchから取得します。
コスト上位に Security Hub / Detective / GuardDuty / Config が見えているため、これらの有効状態も確認して一覧に含めます。
請求上は複数リージョンの可能性があるため、us-west-1 でも同じ主要リソースの有無を確認して、漏れを減らします。
収集結果を整理し、Notionページへ「現状インベントリ＋利用状況＋削除候補」を反映します。更新後に要点もここで返します。
記事を書くにあたって色々まとめてもらったんですがCodex曰く「リージョン違いで見落としやすいので、特定リージョン固定ではなく横断で確認したのがポイント」らしいです。
アピールしてくるのかわいいなw
3. すぐ効く削減案を元に、影響調査しながら作業を実施
Codexが気を効かして削減案をいくつか挙げてくれていたので、すぐに効果が出そうな作業をいくつか行ってみることにしました。
まずは一番影響が小さそうな作業としてCloudWatch Logを削除してみます。
流石に削除指示を出すのは怖かったので調査にとどめ、実際に確認した上で自分で削除しましたが、他のLambda関数が使っているかどうかも確認してくれていたため、安心感を持って削除できました。
AWSロググループから/aws/lambda/sampleを削除しようと思うんだけど影響を確認してほしい
---
削除影響を正確に見るため、/aws/lambda/sample の現設定（保持期間・メトリクス/サブスク・最近のログ流入）と、対応するLambda関数の稼働状況をAWS MCPで確認します。
追加で、他のLambda関数が LoggingConfig でこのロググループを使っていないか確認します。これがあると削除後に影響が出ます。
確認結果、/aws/lambda/sample は**削除しても影響は小さい（ほぼ無し）**と判断できます。
確認した事実（ap-northeast-1）:
ロググループは存在: /aws/lambda/sample
storedBytes: 130,699,296（約130MB）
保持期間: 未設定（無期限）
Subscription Filter: なし
Metric Filter: なし
対応するLambda関数 sample: 存在しない（ResourceNotFoundException）
他Lambdaの LoggingConfig.LogGroup == /aws/lambda/sample: 0件
最終ログ流入はログストリーム名上 2025/09/15 付近で、最近の利用なし
削除時の影響:
過去ログは完全に消える（復元不可）
監視連携（サブスク/メトリクス）への影響は今回の確認範囲ではなし
将来 sample というLambdaを再作成して実行すると、ロググループは再作成される可能性あり（保持期間はデフォルトになる）
次に過去に構築したBI用のRDSのインスタンスサイズが過剰なため縮小します。
新しいBI環境へリプレイス済みですが、一部のエンジニアが利用しているのでやり過ぎると怒られます。
直近の利用実績からインスタンスサイズを提案してくれたため、根拠を持って言い返せるので助かります。
RDSのインスタンスサイズを教えて
ほぼ使ってないはずなので小さくできるなら見直したい
ーーー
RDSの現行サイズを確認し、あわせて直近利用状況（CPU・接続数）を見て、サイズダウン余地を判断します。まずインスタンスとクラスタ情報を取得します。
続いて、直近14日間の利用状況（CPU・接続・メモリ）をCloudWatchから取得して、サイズ変更候補を判断します。
数値を読みやすくするため、同期間を1点集計（14日全体）で再取得します。
サイズダウン候補を正確に出すため、同エンジン（Aurora PostgreSQL）で選択可能なインスタンスクラスを取得します。
現在のRDSインスタンスサイズはこれです。
redash-db-0: db.t4g.large
Engine: aurora-postgresql 13.20
Status: available
Cluster: redash-db（メンバー1台）
直近14日（2026-01-27〜2026-02-10）の利用状況:
CPU平均: 10.67%
CPU最大: 12.91%
接続数平均: 3.44
接続数最大: 8
FreeableMemory平均: 約3.17GB
FreeableMemory最小: 約3.12GB
サイズ見直し可否:
ap-northeast-1 / aurora-postgresql 13.20 では
db.t4g.medium: 利用可能
db.t4g.small: 利用不可
なので、まずは db.t4g.medium への縮小候補が妥当です。
注意点:
このクラスタは実質1台構成なので、クラス変更時に再起動が入り、短時間の停止が発生します（apply-immediately 時）。
インスタンスサイズの変更はAWSコンソール上で変更できるため事実確認のついでに自分で行いました。
4. ついでにRDSメジャーアップデートも実施
上記のバージョンは2/28に標準サポートが終了するため、ついでにメジャーアップデートも行いました。
この辺からある程度任せても大丈夫そうだなと思い始めており、アップデートも行うように指示してます。
Codexが行った作業内容を見ると実行前にスナップショット取得、互換性確認、パラメータグループの更新を行ったうえでアップデートを行っている様です。
指示から完了まで10分ほどかかりましたが、ほとんどほったらかしでも勝手にやってくれるので私は他の作業をしてました。
※ほぼ使ってないRDSだったので丸投げしてます
redash-db-0のバージョンが古いのでアップデートしたい
影響調査とバージョンアップを実行して
ーーー
了解です。redash-db をメジャーアップグレード可能な最新へ進めます。まずスナップショット可用性と現在のパラメータグループ設定を確認します。
現状、クラスタはバックアップ中で、かつ現在のカスタムパラメータグループが13系なので、そのまま17へは上がらない可能性があります。次に、現在のカスタム設定差分を確認して、17系パラメータグループを作成してからアップグレードを実行します。
カスタム差分は入っていなかったため、17系の新しいパラメータグループを安全に作って切り替え可能です。スナップショット完了とクラスタ状態がavailableになったら、メジャーアップグレードを実行します。
バックアップ完了待ちの間に、17系パラメータグループを先に作成しておきます（適用はアップグレード時）。
17系パラメータグループの準備は完了しました。スナップショット完了とクラスタavailableを確認したら、17.7へメジャーアップグレードを実行します。
条件が揃ったので、redash-db を Aurora PostgreSQL 17.7 へメジャーアップグレード実行します（即時適用）。
進捗イベントが更新され、現在はオフラインに切り替えて本処理中です（事前スナップショット作成も確認）。完了まで続けて監視します。
完了しています。redash-db-0 のメジャーアップデートは実行され、現在は正常稼働です。
対象リージョン: ap-northeast-1（us-west-1 ではなく東京リージョンでした）
クラスタ: redash-db
インスタンス: redash-db-0
エンジン: aurora-postgresql
バージョン: 13.20 → 17.7（イベント上は 17.7.1）
現在ステータス: available（クラスタ/インスタンスとも）
完了時刻: 2026-02-10 02:54 UTC（JST 11:54）
ダウンタイム: 526秒（約8分46秒）
パラメータグループ: redash-db-13 → redash-db-17 に切替済み
事前スナップショット: redash-db-pre-upgrade-20260210（取得済み）
補足:
DBClusterParameterGroupStatus と DBParameterGroups が pending-reboot になっているため、静的パラメータ反映のための再起動が未実施です（再起動すると短時間の停止が発生）。
効果
- 見積もりベースで月3万円前後の削減見込み
- 作業時間はMCPの設定も合わせて約3時間
- 本作業にかかったコストはほぼなし（既存環境＋既存ツール中心）
→ 3〜4つ指示するだけで月3万円の削減
最後に
これまでなら、AWSに明るいエンジニアに依頼して「調査依頼」「作業指示」「確認」を段階的に進める必要があるため数日かかることもありましたが、やりたいことを自然言語で指示するだけで調査や実行まで自動でやってくれるので、片手間で終わらせることができました。
もちろん、複雑な本番システムでは検証や承認フローが増えるため、同じように進まないケースもあると思います。
それでも数時間のお試し作業で月3万円規模の削減が見込めたのは十分に費用対効果が出ているなと感じています。
AWS MCPはまだプレビュー版なので、AIエージェント連携を重く作り込みすぎると将来の保守負荷が気になるところです。
一方で、今回のような「棚卸し」「影響調査」「軽微な最適化」にはかなり実用的だと思います。
Discussion