LoginSignup
1
0
@kado__gen

IaC ジェネレーターで豪快にリソースを掃除した話

Last updated at Posted at 2024-02-04

IaC ジェネレーター登場前

IaCジェネレーターの登場前はFormer2を使用して既存のリソースをIaC化することができました。
IaC化先もCloudFormationやTerraform,CDKなど色んな選択肢がありました。
詳細はOutputsを開くと出てきます。

一方でこれを使用するには2つの壁があるかと思います。

  • IAMのCredentialをFormer2 に埋め込む
  • そもそもプロキシ制限で会社の環境で使えない

一旦後者は置いておくとして、
AWSをほぼ触ったことがないけどIaC化してみようかなと思った当時の私は以下の躊躇と対峙しました。
　"このCredential情報を渡して本当にいいんだろうか"

調べると下記のブログやFormer2を触った時に出てくるReadOnlyAccessを使えばいいのかと出てくるわけです。

image.png

これがIaC ジェネレーター登場前に
初心者がIaC化を楽にやってみようと思った時の心理と壁でした。
そして、職場利用させて欲しいと懇願するには既存リソース情報を全て持っていかれるのかをきちんと説明する必要もあったわけです。
救世主となるのか?

IaC ジェネレーターを試してみた

試しにVPC関連リソースをデフォルトで一気に作って、EC2を立ててしまいましょう。

image.png

image.png

IaC ジェネレーターはCloudFormationの中にいます。
とりあえず、スキャンしてテンプレート作成を実施してみます。
image.png

image.png

大きく今までのCloudFormation作成と違うのはこの辺りですね。
スキャンしたリソースを選択できます。
image.png

今回はEC2とVPC関連のNameタグがiac-generatorにしていたのでタグ名で絞って選択します。
image.png

そして出来上がったIaCをスタックにインポートしてCloudFormationから実行します。

実際にEC2インスタンスは構築したEC2と対応していました。
image.png

ここでスタックを削除して確認します。
一部リソースが削除できませんでした。

インターネットゲートウェイと
image.png
ルートテーブルに依存関係がありそうです。
image.png

結局マネジメントコンソールからVPC削除して解決していますが、
"どんなリソースがあるのかをコード化することが可能"は紛れもない事実かなと思います。
現状は本当にこの機能を業務で使うなら過信せずにParameterつかったりRef使ったり等、ある程度の書き直しをする前提の方がいいのかなと思います。
(もちろん、"依存関係は多少あっても、どんなリソースがあるのかをコード化する"ことが目的ならこれでも良い気がします)

ひょっとして既存リソースのお片付けの方が嬉しいのでは？

上記の作業で一番気になったのが既存リソースからIaC化するリソースを選択式で選ぶ際に"こんなに掃除してないIAMロールがあるのか"と思いました。
そして、そのままインポートしてスタック追加削除すれば掃除できるのではと。
依存関係エラーが起きようともちょっとした作業くらいはこちらでやればいいですし。
対象は以下になるイメージでやってみようかと思います。

スキャン結果からIaC化するインポートは該当するリソースがないとエラーになります。
スキャンは一日に回数が限られているのでIaC化する対象を絞ったり工夫が必要です。
ストーリー例と解決方法は以下です。

  1. アカウント内全体スキャンを実施する
  2. アカウント内全体スキャン結果からVPCとEC2を選択してテンプレートBを作成する
  3. テンプレートBからスタック作成を行い、スタック削除することでリソースも削除される
  4. アカウント内全体スキャン結果からテンプレートAをもう一度作成しようとするとインポートできずにエラーが出る
  5. テンプレートリソースタブから既に消したVPCとEC2を削除する
  6. VPCとEC2を除いたIaCが出来上がる

という訳で作成します。
image.png

CDKのアセットが入ったS3なんかは選べないようになってましたね。
image.png

出来上がったコードは6000行！
自動で作られるロールも沢山ありました！
image.png

そしてスタック作成、削除を豪快にやってみました。
気ままにいじり倒したAWS環境のリソースを一気に削除しようとして何%が完全に消すことができて、何%が消せないのか全く想像ができませんでした。
消えなかったものは以下です。

この AWS マネージドキーは、AWS のサービスによってお客様に代わって作成、管理、使用されます。お客様には、アカウントの AWS マネージドキーを表示し、AWS CloudTrail ログでその使用を監査するためのアクセス許可があります。ただし、AWS マネージドキーのプロパティの変更、そのローテーション、キーポリシーの変更、またはその削除のスケジュール設定はできません。

S3はまだしも、削除できないロールは完全に頭から抜けてました。
CloudFrontはどこから消すんだろう..ぱっと見いない..見間違いだろうか..

感想

ルートテーブルとインターネットゲートウェイの依存関係エラーからちょっと気になることもありますが、
既存のリソースを確認して選んでIaC化できるのがAWSで完結しているのがいいなと思います。
検証したときのものが一部残っていたらしくそのあたりがきちんと消えていたり、
昔作ったロールがごっそり消えていたので掃除としては更によく感じました！

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0