AWS CDKでやらかした & AI Codingの反省

先日AWS CDKでやらかしました。Geminiを使っての開発です。

やらかし経緯

1. 本業プロジェクトでCDKコードが完成し、AWSへデプロイを試みる。
2. Geminiから「cdk bootstrapが必要」と指摘される。
3. これまでcdk deployだけで済んでいたため理由を質問 → 「S3などのアップロード先作成のため」と聞いて納得し、実行。
4. 作業用アカウントでは権限不足で失敗。
5. Switch Roleで権限を切り替えて再実行するも、同じく失敗。
6. Stack ... is in UPDATE_ROLLBACK_FAILED state...というエラーが出て、Geminiから「CDKToolkitを手動削除」するよう提案される。
7. 言われた通りにManagement ConsoleでCDKToolkitを削除。しかしbootstrap権限もないため、その後の操作はすべて失敗。
8. 翌日、「既にbootstrap済みだった場合どうなるか」をGeminiに確認し、ようやく状況を理解。自分のミスを認識。

要点をまとめると:

「権限不足のままbootstrapを実行 → rollback失敗 → Toolkitを消して状況悪化 → 後からbootstrap済みだったと判明」

分析

ローカルコードをcdk deployする際にはbootstrapしてCDKToolkitの作成が必要なのですが、企業アカウントだとbootstrapは大抵既に実行済みです。

自分にはこの知識が欠けていて、提案通りにcdk bootstrapを実行するのですが、もちろん失敗します。権限はしっかり管理されていてますし、なんならCDKToolkitはすでに存在しています。

さらに酷いのは、一回cdk bootstrapを実行したおかげで、既存のCDKToolKitも自分が作成したものだと勘違いしてしまったことです。もしもリソース作成日を確認して、明らかに自分が作成したものではないと気づくことができれば、一歩踏みとどまることができたかもしれません。

反省

• リソース削除の際は要注意。きちんと自分が作成したものだと判断することが必要。なるべくSeniorの監視の元で行う。
• 権限不足エラーが出たときは、むやみに再実行する前に「組織的な制約」かどうかを確認する。
• Geminiの提案をそのまま実行した点については、「AIの指示が間違っていた」というよりも、「AIはそのアカウントの既存状態を把握できない」ことが本質。
• AIの提案は便利だが、環境情報がないため必ず自己判断と他者確認を挟む。