IaCジェネレーターとは
IaCジェネレーターとは、AWSが提供する、既存リソースをCloudFormationのテンプレートとして作成・管理が可能になる機能です。自分はIaCとしてTerraformしか触ったことがなく、CloudFormationのページを開いたことすらほとんどなかったので、このような機能が存在することすら知らなかったです。可能性を感じる機能で知らずに済ませるのはもったいないということでご紹介となります。
使用方法
まずは使用方法です。使用方法は、CloudFormationのコンソール画面から、左メニューでIaCジェネレーターを選択し、「新しいスキャンを開始」ボタンを押下(全てのリソースでもリソースを選択しても)して対象リソースをスキャン後、「テンプレート」タブを開いて、「テンプレートを作成」ボタンを押下します。対象リソースを選択しながら画面を進めていくとテンプレートが作成されて、対象リソースをコード管理する場合の定義を取得できます。「スタックにインポート」を行えばそのままCloudFormationの管理にすることも可能です。手動で作成してしまったリソースをコード管理したい場合などの重宝するかと思います。
そもそもIaCとは
そもそもIaCとはInfrastructure as codeの略で、文字通りとなりますがインフラの構成をコード化して管理することになります。インフラリソースをコード化して管理する意義とは何かという話になると、この辺りは調べてすぐ出てくるような内容がそのままになるかと思いますが、
・手作業を排してヒューマンエラーを抑制できる
・再現性のある環境構築が可能になる
あたりが主なメリットになるかと思います。
個人的には後者のメリットが大きいと感じていて、既存システムの新規環境構築を対応することが多いので、コード化されている時とそうでない時では対応の難易度が段違いになります。コード化されていない時に新規に別環境を立ち上げるとなった時は対象リソースを洗い出し、既存構成の全体像を確認し、各リソースに必要な権限を抽出し…と、ともすれば1から構築する時より窮屈な対応を強いられます。
そんな対応をする際、コード化されていない環境をコード管理にしてそのまま適用できたら新規環境の構築も非常に簡単になるので、このIaCジェネレーターは画期的な機能だと感じます。しかし、これはAWSの機能で当然AWSのIaC=CloudFormationにしか対応しておりません。自分がそればかり使っているからというのもありますが、可読性の高さやplan機能による比較的わかりやすい変更内容の把握などを加味すると、Terraformでの管理を行いたいという気持ちがあります。
※一応Terraformer(現在非推奨)やFormer2というAWSリソース→Terraformコード変換ツールも存在しているようです。
ツール紹介
というわけで、CloudFromationをTerraformに変換するツールを簡易的にClaudeCodeを用いて作成してみようとしました。…が、テストをしていてもあまり適切な変換が行えませんでした。既存ツールとしてCloudFormationをTerraformの形式に落とし込むことができる「cf2tf」というものが存在しています。こちらについても一部サービスが技術的に対象外になってしまうなどがあったので、今回のツール構築は対応できないところが残るにしても自分で作成することで明確に対応できないサービスの判別ができるようにしたいなどの意図もありました。しかし、CloudFormationの特性上ネスト周りなどを中心に解析がうまくいかない部分が多く想定以上に難しく、想定していたクオリティのレベルに達することができませんでした。
ほぼ供養レベルですが作成したもの(作りかけ)は以下です。変換時にせっかく構文の解析をするならと構成図を作成したり(こちらも類似ツールとしてcfn-diagramというものはあります)、別環境の構築などが容易になるように特定のワードを変数として置き換えられる機能なども追加してみましたが、構成図の方もあまり綺麗に作れる形にはなっていない状態です。
https://aws-resource-inventory.vercel.app
代替案
このツール構築を経て、CloudFormationからTerraformという変換が業務などでの実用レベルあまり現実的ではないということがみえてきたところから、別アプローチとなります。見かけたのはこちらの記事で記載の方法３。
https://qiita.com/zukutakuzu/items/74d7b00e1dcc09289d89
Amazon Q DeveloperによるTerraformコード生成ということで、Amazon Q Developerが日本語にも対応したという話は去年時点で聞いたことがありましたが、自分で使用したことがなかったためこういった活用法は思いついていなかったです。プロンプトや範囲の指定の仕方によっても精度がかなりブレるということはあるようで、当然terraform validateやterraform planを用いたレビューは必要になるかと思いますが、それを差し引いても既存リソースをTerraformによるIaCに対応させる最も現実的な方法に感じました。
おわりに
収拾がつかなくなったのでたたみに入ります。
規模が大きくなると有料版(Pro)でないと難しい可能性があるなど多少の課題は残るものの、今既存のAWS環境をTerraformで管理(またはコード化して別環境を作成)するならAmazon Q Developerの活用が最も有効なアプローチだと結論づけましたが、そもそも冒頭で触れたIaCジェネレータを使用して、そのままCloudFormationで管理するというのもその時点で一つの解決策(AWS的には最もスマート？)です。個人的には可読性からTerraformを推奨したいですが、現状AWSしか触っていないのでTerraformの強みを十分に活かしきれておらず、改めて考えてみるとCloudFormationで管理してドリフトの検知などができた方が利点になりうる使い方をしてしまっているのが現状ではないかと考え直したりしています。当初の議題からは大きく逸れましたが、今回の件で慣れた方法(ClaudeCodeで無理やりTerraform管理)ばかりではなくツールの選択(Amazon Q Developerの活用や、そもそもCloudFormationという選択肢が取れるか)の重要性を痛感したように思えます。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
