こんにちは、臼田です。
みなさん、CloudFormationでリソース作成を自動化してますか？(挨拶
今回はふとハマってしまった内容を共有します。
結論
今回の事象ではAmazon GuardDutyのランタイムモニタリングを有効にしていたことで、ECSクラスターを作成したVPCに自動的にVPCエンドポイントが作成され、これがCloudFormationのスタック削除時に残っていたためうまくスタックが削除できませんでした。
個別にVPCエンドポイントを削除することで解消できました。
以降は問題の発見から事象の詳細まで解説します。
問題: CloudFormationのスタック削除でサブネットの削除がうまく行かない
ある日ふと作成したチュートリアルのアプリケーションで利用したCloudFormationスタックを削除したら、本来きれいに消えるはず(これまで何回も使っていてちゃんと消えていたはず)なのに消えない事象に遭遇しました。
エラーを見てみます。以下のようにイベントの詳細を見ると、何かの依存関係でサブネットが消えてくれません。
何が依存しているのかを確認する方法は色々あり、王道をいくならAWS Configのリソースから確認すれば良いのですが、元々削除したいリソースですから、力技でマネジメントコンソールから直接削除してみます。
すると以下のように、削除できない理由と依存関係が詳細に表示されます。削除することが確定であれば、問題点をすぐ見つけられるためこの方法が非常に効果的です。今回はネットワークインターフェイスが存在しているので、リンクをクリックしてたどります。
さらにこれらを選択して削除してみます。
同じように依存関係が出てきて、VPCエンドポイントが表示されます。これも開きます。
ここでなんのVPCエンドポイントか見てわかります。GuardDutyのエンドポイントですね。これを見て、GuardDutyでランタイムモニタリングを設定していたことが思い出せました。Amazon ECS クラスターの Runtime Monitoring - Amazon GuardDutyにて、ランタイムモニタリングの設定により「GuardDuty セキュリティエージェントをデプロイすると、GuardDuty が Amazon Virtual Private Cloud (Amazon VPC) エンドポイントを作成します」となっているためこれが展開された結果になります。
というわけでVPCエンドポイントを削除していきます。削除できたら、遡ってVPCまで削除して、最後にCloudFormationスタックを削除しましょう。
ついでにログ調査
実際にこのリソースがいつ作られたのでしょうか？CloudTrailを見てみます。
該当の動作はGuardDutyRuntimeMonitoringというユーザー名でフィルターすると確認できます。DescribeSubnetsから始まり、状態を確認したりセキュリティグループを作成したりして、VPCエンドポイントが作成されていました。
時系列的には、CreateServiceをして実際にFargateが立ち上がるタイミングがトリガーとなり、諸々動作してVPCエンドポイントが作成されるまで30秒程度でした。
まとめ
というわけで、なぜかうまくサブネットが削除できないと思ったらGuardDutyの設定によるものでしたという話でした。
自動でVPCエンドポイントを作成して脅威のチェックをしてくれるのはめちゃくちゃ便利ですが、削除する際にはじゃまになるので忘れずに消しておきましょう。
12
