はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 10 日目です。
今回は CloudFormationの処理を律儀に待つ必要はないんだと学んだ話 を書いていきます。
やっていたこと
CloudFormation で作成されたリソース一式を削除する作業をしていました。削除するリソース自体は EC2 とセキュリティグループと ALB と……という感じで、諸々削除しても大丈夫！なことは事前に慎重すぎるくらい確認をしていたので、ほかにやることといえばルートボリュームのバックアップをどうするかや、EC2 に削除保護が設定されていないか確かめるくらいでした。
削除対象のリソースは、EC2 が RDS へアクセスをするという形で、一部が現行のサービスと紐づいていました。今回 RDS は削除対象ではなかったため触らず（万が一誤動作で何かしてしまったら嫌なので、必要以上に触らないようにもしていました。）特に EC2 へ注意を払っていました。
諸々の下調べを終えた初心者エンジニアは、サービスの切り離しも完了したし、いざ実行だ！と、意気揚々とスタックの削除を行います。
結果
CloudFormation の処理が 永遠にも思える時間終わらず、しかもそれを律儀に待っていたため、 必要ではない残業をすることになりました。
終わらないが、エラーは出ていない ので、そのうち終わるんだろうナァ…ちょっと時間がかかっているんだけなんだろうナァ…と思いのんびりしていましたが、一時間ほどたったところでこれは何かおかしいのでは？とようやく気が付くことができました。
何が起きていたのかというと、現行 RDS のセキュリティグループに、削除予定のセキュリティグループが紐づけられていたことで、依存関係が処理できずにセキュリティグループの削除処理がストップし、そのせいでスタックの削除がいつまでも完了しないという現象が発生していました。
コンソール画面から手動でセキュリティグループの紐づけを解除後、再びスタックの削除を実行したらものの数分で処理が完了しました。
何を考えていたのか
エラーが出ていないんだから、そういうことなんだろう… と、自然に身を任せすぎました。それまでも RDS や ALB の作成を CloudFormation で行う際にけっこうな時間がかかっていたので、スタックの処理に時間がかかっていても これはそういうものなんだと思い込み、なにかおかしいことが起きているのでは？という疑いを持ちませんでした。愚かです。
まとめ
CloudFormation の処理を律儀に待つ必要はありません。何かおかしいな？時間かかりすぎかな？ と思ったら現場（コンソール）を直接覗きにいきましょう。何かしらの想定外がそこにあります。
当時はありませんでしたが、現在は画像のタイムラインビューというものが実装されています。こちらにより、CloudFormation がいま そのリソースに対して何の処理をしているのか？ がとてもわかりやすくなりました。
不安になったらこちらで実行時間や処理内容をじっと監視するのも異変を察知する有効な手段かと思います。
