この記事は「もくもく会ブログリレー」 18日目の記事です。

AWS CloudFormation IaC ジェネレーターは、既存のAWSリソースをCloudFormationやCDKのコードにすることができる機能です。

【AWS公式】既存のリソースのテンプレートを生成（IaC ジェネレーター）

既存のリソースをコード化したいというケースはよくあるので、とても便利な機能でありますが、現状では生成されたコードの修正が必要なパターンが多いです。

この記事ではその修正内容に焦点を当てて記述します。そのため、どこをどう直せばデプロイできたのか？という点が把握できるので、IaCジェネレーターの精度をより強く体感できるかと思います。導入前など、実際に使ってみる前の参考にしてください。

検証

デプロイする環境

EC2にパブリックでSSH接続できるだけの単純な環境です。

検証の流れ

検証は以下のような流れで進めます。

  1. リソースのデプロイ
  2. IaC ジェネレーターでスキャン
  3. IaC ジェネレーターでコード化（テンプレートの作成）
  4. リソースの削除
  5. CloudFormationでデプロイ

ここでもっとも重要なのは 「5. CloudFormationでデプロイ」です。このポイントを読んでいただければ、コード化からデプロイまでこれくらいかかるというのがおおまかに把握できるかと思います。

コード化するときの「関連リソースを追加」というステップについて

IaC ジェネレーターでコード化する際に「関連リソースを追加」というステップが存在します。これはテンプレート作成時に、選択したリソースだけでは環境を再現できない場合、間のリソースを補完してくれる機能です。この機能は確かに間のリソースを補完はしてくれるのですが、逆に不要なリソースやパラメータを増やしてしまうパターンがあります。

先に結論だけ書いておくと、本検証のレベルであれば、関連リソースを追加する場合の方が修正する箇所が増えるため、関連リソースは追加しない方がデプロイまで早かったです。

具体的にどういう修正が発生するのかというのは気になるポイントだと思うので、本記事ではこの「関連リソースを追加」したパターンと、そうでないパターンの2パターンを記述します。

1.リソースのデプロイ

前項の「デプロイする環境」を構築します。方法はなんでも良いですが、私はTerraformでデプロイしました。使ったコードは以下に置いておきます。コード内でも適用されていますが、この時タグを設定しておくと、のちの抽出が楽になります。

GitHubリポジトリ / Iac-generator

詳細は readme にも記載していますが、利用の際はSSHキーの作成、S3バケットとSSH許可IPの記述が必要です。デプロイしたら、ネットワークまで正しくデプロイされていることの確認のために、SSHの接続までやっておきましょう。

2.IaC ジェネレーターでスキャン

CloudFormation → IaC ジェネレーター → スキャン → 新しいスキャンを開始

3. IaC ジェネレーターでコード化（テンプレートの作成）

テンプレート → テンプレートを作成

ステップ1：テンプレートの詳細を指定

テンプレート名を入力 → 削除ポリシーと置換ポリシーは「削除」に変更

※デフォルトの「保持」にするとスタックの削除や更新時にもリソースが残り続けてしまうので、ここでは「削除」としています。

ステップ２：スキャンしたリソースを追加

「1.リソースのデプロイ」のリソースを追加しましょう。「タグ値」で絞るのが一番簡単です。

ステップ3：関連リソースを追加

前項で説明をしたステップです。追加しない場合はチェックを外し、追加する場合はチェックを入れたままにします。本キャプチャではすべてチェックを外した状態にしています。

あとは確認してテンプレートを作成しましょう。

4. リソースの削除

「1.リソースのデプロイ」でデプロイしたリソースを削除してください。Terraformで作っていれば、 terraform destroy を実行します。

5. CloudFormationでデプロイ

デプロイ

「3. IaC ジェネレーターでコード化（テンプレートの作成）」で作成したテンプレートを使ってデプロイします。デプロイの方法はなんでもよいですが、AWS CLIを使う方法が手間が少なくておすすめです。

aws cloudformation deploy --stack-name iacgenerator --template-file iacgenerator.yaml

※参考 CloudFormationのAWS CLI

おそらくここでエラーが出力され、スタックの削除→エラー対処→デプロイ…を何度も繰り返すことになります。以下では「3. IaC ジェネレーターでコード化（テンプレートの作成）」で関連リソースを追加しなかったパターンと、追加したパターンで正しくデプロイできるまで修正した箇所をすべて記載します。

下記の結果から前述の通り、「関連リソースなし」の方が修正箇所を少なくできることがわかります。

パターン①：関連リソースなし

不要な設定 / 5項目
  • EC2とネットワークインターフェースでプライベートIPが重複
  • EC2とネットワークインターフェースでサブネットの設定が重複
  • 利用できないCPUオプションの設定
  • ネットワークインターフェースのID指定
  • EBSの指定
必要な設定 / 3項目
  • IGWをVPCにアタッチ
  • サブネットとルートテーブルの紐付け
  • IGW向けのルートテーブル

パターン②：関連リソースあり

不要な設定 / 13項目

関連リソースなしの項目は、こちらのテンプレートでもすべてエラーとして出力されました。さらに以下の項目が不要な設定として出力されてしまいました。

  • サブネットとネットワークACLの紐付け
  • EC2とEBSの紐付け
  • ルートテーブルのVPCエンドポイント
  • 複数のルートテーブル（2つが余剰）
  • 複数のセキュリティグループ（1つが余剰）
  • ネットワークACLの作成
  • Route 53の設定
  • ネットワークインターフェースの作成
必要な設定 1項目
  • IGWをVPCにアタッチ

実際のコード

こちらのGitHubリポジトリからご確認ください。コメントアウトにて必要/不要リソースがわかるようになっています。（ID等はすべてマスクされているので、スタックは流せません）

CDKへのインポート

IaCジェネレータで直接CDK用のファイルへ出力できるわけではないのですが、テンプレートファイルに対して、cdk migrate を使って変換が可能です。コンソールにも下記のような記述が存在します。

ステップ 3: CloudFormation または CDK にインポートする
生成されたテンプレートを開いて、リソースを CloudFormation にインポートします。cdk migrate コマンドを使用して、テンプレートを CDK アプリケーションに変換することもできます。

※参考：CDK Migrate: AWS CDK への移行コマンドの発表

さいごに

いかがでしたでしょうか。IaCジェネレーターの使用感が掴めたかと思います。とても有用な機能ではありますが、前述されているようなエラーの処理はもちろん、各パラメータが正しく設定されているかも確認しましょう。

導入の際はエラーの修正やパラメータの確認がかえって負担になり、場合によっては0ベースで作った方が早いというパターンもありえるかと思います。導入はこのあたりをしっかり見定めて検討が必要です。

2024/2にGAされたばかりの機能なので、まだまだ進化していく機能だと思われます。今後のアップデートを楽しみにまちましょう！

明日の記事は、佐藤竜也さんの「社内LT大会ハイブリッド開催時の配信構成を考えていく」です。実際にiret東京/大阪でハイブリット配信を実現してくれました。前回同様、配信に興味がある方は必見の記事です！