AWSパラメータシートからBedrockでCloudFormationを自動生成した際のTips

記事の対象者

• パラメータシートを元に手動でCloudFormationやTerraformのコードを書いている方
• IaC化に工数を割けず疲弊している方

はじめに

IaC化したくても以下のような状況は多々あると思います。
状況１：手動で作成済みの既存環境をコード化したいが、IaC化に避ける工数がない(運用面のメリットは伝わりにくい。。。)
状況２：IaC管理をしていても顧客への納品物としてパラメータシート(以下パラシ)も作成せざるを得ない

そのような状況の課題の1例として、以下のようなことが起こりがちです。
状況１の課題：運用の中の度重なる設定変更でパラシのメンテナンスが管理しきれず、パラシと実環境の設定が一致しない
状況２の課題：IaCとパラメータシートの2重管理になり、管理工数が高くなる。

上記の課題を流行りの生成AIで解決すべく、
AWSパラメータシートをBedrockに読み込ませてCloudFormationテンプレートを自動生成するツールを作成しました！

注意事項

• ツールの中身については記載しておりません

前提条件

• AWSパラメータシートとは
  • AWSの設定値を主にExcelで一覧化したドキュメント
    • 例:EC2のインスタンスタイプや、セキュリティグループのルール等を記載
    • メリット：視認性が高い（誰でも読める）
    • デメリット：管理が大変。数年運用していると、実環境と完全一致していることを誰も保障できない

アーキテクチャ構成

アーキテクチャについて解説します。
①Cloudshell上で実行するツールでS3に配置したパラメータシートをロード
②ロードしたパラメータシートを元にCloudFormationテンプレートの生成するようにBedrockに依頼
※モデルはツール作成時点で最新のClaude3.5 Sonnet V2を採用しています
③完成したCloudFormationテンプレートをS3に出力
④出力したテンプレートを人間がチェック
⑤Infrastructure Composerで視覚的に構成をチェック
⑥チェック済みのテンプレートからStackを作成
⑦Stackを元にAWSリソースを構築

本記事では②の中の簡単な仕組みの紹介と工夫について共有します

Tips

Tips1

問題

Bedrockの仕様で1リクエストの添付ファイル数上限が5つしかない。
https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/conversation-inference-call.html

AWSサービス単位でパラメータシートを分割していた(VPC.xlsx,IAM.xlsx,...)ため、Bedrockに対して一度のリクエストでCloudformationテンプレートの生成することができませんでした。

対処法

パラメータシート単位でBedrockへのリクエストを分けてCloudFormationを生成することで対策

パラメータシート単位でBedrockにリクエストを行うことで上記の問題を回避しました。

上記の問題として、パラメータシートをAWSサービス単位等6つ以上のファイルで管理している場合、Bedrockへのリクエスト1回で依存関係のあるAWSサービスのテンプレートを別々に作成することになるため、Outputや参照の命名が統一されなくなります。

Tips2

Tips1の問題点に対して以下の工夫で対応しました

対処法

依存関係の少ないAWSサービスから順番にテンプレートを生成し、生成したテンプレートを後続のテンプレート生成時のリクエストに含める

VPC等、EC2やECSを使用する際の前提になるパラメータシートから順にテンプレートを生成させ、生成したテンプレートを後続のテンプレート生成時に含めることで参照の問題を解決しました。例えば、EC2構築時にVPCやサブネットを指定する必要がありますが、先行して作成したVPCのテンプレートをEC2のテンプレート作成時のリクエストに含めることでテンプレート間の参照(ImportValue)を正しく行うことができるようになります。

その他

入力ファイルはpdf | csv | doc | docx | xls | xlsx | html | txt | md形式である必要があり、ファイル名に日本語は含められません。
また、環境によってはSharepointに保存していると自動的にブックが保護されている可能性があり、保護されているとBedrockでエラーになるので事前に解除する必要があります。

テンプレートのサイズが大きいと一度のリクエストで出力トークン数の上限で途切れる可能性があります。
(モデルによって異なりますが、Claude 3.5 Sonnetの場合8,192トークンが上限です）
そこで、プロンプトで出力が途切れる場合の識別子を付与させて、プログラム側でマージする処理を組むことで解消しました

おわりに

• 東京リージョンで使用可能なモデルの中で最新のClaude3.5 Sonnet v2の性能が驚異的でインフラ構築・運用に革命が起きたなと感じました。
• Cloudformation対応していないリソースでそれっぽいテンプレートを作成してしまう等の課題はありますが、公式ドキュメントをナレッジベースで読み込ませたり、web検索可能なモデルを使用することで性能向上の余地があると思うので取り組んでいきます。