Vibe Coding での AWS 過剰出費３選

• 当時の利用モデルは GPT-5.5 です。利用エージェントは Codex です。
• プロンプトやエージェントの回答はイメージで書いており、原文ではありません。
• いちおうこの記事は AI 生成ではありません。

はじめに

LLM の新しいモデルがリリースされて、Vibe Coding のクオリティがどんどん上がっていますね。

プライベートで Codex を使い Web ページなどを作ってみましたが、LLM 以前に必死に作ったものが一瞬でできあがると感じます。

ただし、お金や運用負荷のことは具体的に指示しないと、よしなに考えてくれるわけではなさそうです。

将来的にはそのあたりまでやってくれるかもですが、当面は人間がチェックしたほうがよさそうだなと感じています。

ということで、私が個人的に開発している環境で遭遇した過剰出費アーキテクチャを３つ共有します。

Lambda の変数として Secrets Manager 使いたがり問題

prompt

Lambda で *** を実装してください。*** はいつでも変えられるよう変数にしておいてください。

Codex

変数は SSM Parameter Store に作成します。*** は秘匿情報として Secrets Manager で作成したほうがよさそうですね。

AWS のベストプラクティス的には仰るとおりだが、Secrets Manager は１つあたり $0.4/月 の費用が発生する。

もちろん Secrets Manager には、アクセス制御や監査、ローテーションなどのメリットがある。

ただ、自分しか利用しない小規模なアカウントで、ローテーションもしない固定値をすべて Secrets Manager に入れるのは、費用対効果が低い場合もある。

GitHub 等の SaaS リポジトリがあり、Terraform を使っているとしても、ローカルの tfvars を .gitignore したり、GitHub Actions や Terraform Cloud のシークレット変数から渡したりする程度で十分なケースもあるでしょう。

気づいたらシークレットが10個くらいできているので、ちょっと嫌な気持ちになりました。

WAF のルール作りすぎ問題

prompt

WAF で *** に関する PATH を保護してください。

Codex

各 PATH に対してルールを作成しました。

まあ、そうなるのが自然ではあるでしょう。確かにフィルタ条件としては綺麗に管理されている。人間の視認性もよい。運用しやすい。

しかし、WAF ルールは１つあたり $1/月 の費用が発生する。

すべて同じ条件、同じアクションで処理するだけなら、フィルタ条件ごとに $1 払うより OR でつないだ１ルールで十分でしょう。

Athena & CloudTrail でログが増え続けちゃった問題

これがその場で気づけず、出費も痛かった問題。

アクセス解析をしたかったので Evidence を静的サイトとしてデプロイし、集計は Athena で実施することにした。

サービスごとにアカウントを分けているので、解析用アカウントの S3 にクロスアカウントで収集して……などとやっているうちに見逃してしまった。

prompt

AWS Organizations 配下の全アカウントのアクセスログを一元的に収集して

Codex

CloudFront のアクセスログが有効になってないですね
有効にしました
S3 への操作ログが有効になってないですね
S3 に対して CloudTrail のデータイベントを有効にしました
ログは解析アカウントに配置しますね
クロスアカウントで S3 バケットに統合します

可能な範囲で経緯を遡ったところ、上記のようだったらしい。

S3 への操作ログが有効になってないですね
S3 に対して CloudTrail のデータイベントを有効にしました

これが全く記憶にない。GPT はそう解釈したのか……。

そもそも欲しかったのは CloudFront のアクセスログであり、S3 オブジェクトへの操作履歴ではなかった。

これが後々、

prompt

Evidence を使おうと思う。静的サイトとして CloudFront + S3 で配信します
データは Athena で日次生成して、CodeBuild で生成、デプロイして

Codex

わかりました！

という流れで Athena に巻き込まれてしまい、

CloudTrail のログを S3 へ保存
        ↓
Athena が S3 上のログを読む
        ↓
GetObject などが発生
        ↓
その読み取りを CloudTrail が再び記録
        ↓
CloudTrail のイベント数と S3 リクエスト数が増える
        ↓
次回の Athena 実行時に読み取るログも増える

という流れで、日次処理のたびに S3 オブジェクトが増えてしまった。

Athena が無限に自動実行されていたわけではないが、Athena の読み取りによって生成されたログが、次回の解析対象に含まれる構成になっていた。

ただ、コストは定期的に確認していたので、大事故になる前に止めることができた。

アンチパターンの把握も大事だけど、コストはこまめに確認しよう。

逆に言えば、丸投げしても一定のベストプラクティスは達成してくれる

ここまでの問題は「個人の割にはお金がかかる」のであって、秘密情報を分離する、WAF で保護する、ログを一元管理するといった基本方針は一定の精度で実現してくれています。

言われてみればそりゃそうですね。コスト条件を伝えていなければ、安全性や管理のしやすさを優先するのは自然です。

LLM の出力を鵜呑みにせず、武器として使いこなせるようになれるといいですね。

そしてコストは気がついたらではなく、定期的に見よう！

免責事項

• この記事の内容は個人の見解であり、所属する組織の意見を代表するものではありません。