terraform destroy したときにサブネットがなかなか消えないときは何かリソースが乗ってるかも

これはなに？

terraform に関するちょっとしたtipsです。自分が20分程度こまったので、共有しておきます。

結論

タイトルの通りです。

こんにちは

さっちゃん（@toshiakisan1127）です。ソフトウェアエンジニア1年生で、普段はWebアプリケーションの開発でバックエンド（with Python, Spring boot）と、インフラ（with CloudFormation, terraform, kubenetes）をやってます。

現象

先日、開発環境のアーキテクチャを変更するために、サブネット上に乗っているk8sクラスターをdeleteして、インフラ部分を

terraform destroy 

しようとすると、あるサブネットだけ待てど暮らせどdestroyされず気づいたらおじいちゃんになってしまいました。（実際は20分くらい待った。）しかしエラーにはならないので、強制終了するとtfstateが壊れそうなので踊るしかやることがなかったです。

調査

まずはマネジメントコンソールから直接サブネットを壊そうとすると下の画像のように、「ネットワークインターフェースが残っている」と言われて消せませんでした。

サブネットを消そうとするとネットワークインターフェースが残っていると言われる。なんだそりゃ？

これはあるEC2についてるみたいなので、（あれ、EKSクラスター落としたはずだけどなぁ...。）とか思いながらマネコン上をうろうろしてました。

この時点で「何か上に残ってるんでは？」と仮説を立ててましたが、サブネットの上に何が乗っているかを探すのってマネジメントコンソール上では辛いです...。なにかいい方法があったりするんでしょうか。今回は各マイクロサービスのterraformやcloudformationを見て回ることで、該当のサブネットを使ってそうなものがないか探して回りました。（手でリソース作ってたらどーすんねん。）

原因

結局、他のマイクロサービスのLambdaがそのサブネットの上に乗っていたので、そのアプリケーションもdestroyすると一瞬でサブネットが消えました。上記の残っていたネットワークインターフェースはLambdaの実行環境のEC2にアタッチされているものみたいです。>

アタッチされているインスタンスの所有者がAWSになっている。Lambdaの実行環境の責務がAWS側にあるという話かねぇ。

教訓

• サブネットのdestroyは、上にリソースが乗っている場合にエラーではなくTimeoutになる。（本題）
• Lambdaの実行環境ってEC2の上にあるのかぁ。そりゃそうかもしれないが、裏側が見えた気がしてちょっと面白い（雑談）