Zenn
🍖

Well-Architected レビューをLLMにお願いしてみた

に公開
AWS
IaC
Bedrock
Well-Architected Framework
tech

はじめに

個人で開発しているWebアプリをAWS上に展開しています。
そんなWebアプリに対してWell-Architected レビューを「Well-Architected IaC (Infrastructure as Code) Analyzer」を利用してLLMにお願いしてみました。

本記事をもとに「JAWS ミート 2025」でLTをしました。
LT資料はこちらです。

対象読者

  • AWS上にワークロードを展開している方
  • Well-A レビューをお手軽に実施したい方
  • 構成図からWell-Aに沿ったIaCを生成したい方
  • 「Well-Architected IaC (Infrastructure as Code) Analyzer」について知りたい方

Well-Architected IaC (Infrastructure as Code) Analyzerについて

「Well-Architected IaC (Infrastructure as Code) Analyzer」はIaCやアーキテクチャ図をインプットに、AWS Well-Architectedのベストプラクティスに沿って設計できているかをレビューしてくれるプロジェクトです。

このプロジェクトはWebアプリの形式で展開され、Rvに必要なインプットを展開されたWebアプリにアップロードすることで、バックエンドにいるBedrockがRvを行ってくれます。
BedrockはAWSのホワイトペーパー等で構成されているBedrock Knowledge Baseと連携されており、情報の取得元を引用して回答してくれます。
さらに、構成図や設計書からIaCを生成することも可能です。
このWebアプリやBedrock等はプロジェクトが提供しているCFnやCDKで簡単に展開可能です。


IaC Analyzerの構成図

詳細は「Well-Architected IaC Analyzer」のGitHubリポジトリをご参照ください。
https://github.com/aws-samples/well-architected-iac-analyzer

実際にRvしてみる

では早速、Well-Architected IaC Analyzerをセットアップし、Rvを進めていきます。

Well-Architected IaC Analyzerのセットアップ

はじめにIaC Analyzerをセットアップしていきます。
いくつかセットアップ方法がありますが、今回は推奨されているCFnを用いたパターンでセットアップします。

手順は以下にありますので、原文を見たい方はこちらをご参照ください。
https://github.com/aws-samples/well-architected-iac-analyzer?tab=readme-ov-file#option-1-using-a-cloudformation-deployment-stack-recommended

0. 事前準備 モデルアクセスの有効化

IaC Analyzerで利用する以下のBedrockのモデルを有効化します。

  • Titan Text Embeddings V2
  • Claude 3.5 Sonnet v2（デフォルト）
  • （任意）Claude 3.7 Sonnet with extended thinking

モデルの有効化は以下の手順を参考にしてください。
https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/model-access-modify.html

1. CFn テンプレートのダウンロード

以下のYAMLをローカル環境にダウンロードします。これがCFnスタックを作成するためのYAMLですね。
https://github.com/aws-samples/well-architected-iac-analyzer/blob/main/cfn_deployment_stacks/iac-analyzer-deployment-stack.yaml

2. CloudFormationでスタックを作成

ダウンロードしたYAMLを使って、CloudFormationで環境を構築します。

まずはスタックの作成画面で、「既存のテンプレートを選択」、「テンプレートファイルのアップロード」を選択し、ダウンロードしたYAMLをアップロードして、「次へ」をクリックします。

次にYAMLのParameterフィールドに定義されていた任意の値を設定していきます。
たくさん設定項目あるように思えますが、大別すると以下の通りです。

  • インターネット上からアクセスできるように構成するか
  • Bedrockのモデルは何を選択するか
  • 認証は必要か
    • Cognitoで認証連携したい場合は、Cognito関連の設定
    • 任意のOIDCで認証連携したい場合は、OIDC関連の設定

インターネット上からアクセスを許可し、Bedrockのデフォルトモデルを利用し、認証を不要とするとこれくらいの設定で済みます。

設定できるParameterの一覧を機械翻訳しました。よく確認されたい場合はご参照ください。

参考 Parameter一覧

グローバル設定

インターネット向けのALBでデプロイしますか？（PublicLoadBalancer）

有効（デフォルト）：インターネットからアクセス可能なロードバランサーをデプロイします
無効：VPCネットワーク内からのみアクセス可能な内部ロードバランサーをデプロイします
内部ロードバランサーのアクセス設定について：
内部ロードバランサーにアクセスするには、以下のいずれかの方法でデプロイ先VPCへのネットワーク接続が必要です：
VPCピアリング
VPN接続
AWS Direct Connect
その他のネットワーク接続ソリューション
⚠️ セキュリティ警告：認証を無効にした状態で「有効」を選択した場合、アプリケーションは認証なしで一般公開されます。インターネット向けデプロイの場合は、認証の有効化を強く推奨します。

Amazon BedrockモデルID（ModelId）

デフォルト：anthropic.claude-3-5-sonnet-20241022-v2:0（Claude 3.5 Sonnet v2）
必要に応じて別のBedrockモデルIDを指定することも可能です
注意：本アプリケーションは主にClaude 3.5 Sonnet v2およびClaude 3.7 Sonnetでテストされています。他のBedrockモデルでも動作する可能性はありますが、異なるモデルを使用すると予期しない結果が生じる場合があります。
認証設定
認証を有効にする（Authentication）

無効（デフォルト）：アプリケーションへのアクセスに認証は不要です
有効：選択した方法で認証を有効にします

認証方法（AuthType）

none（デフォルト）：認証なし
new-cognito：新規のAmazon Cognitoユーザープールを作成します
existing-cognito：既存のAmazon Cognitoユーザープールを使用します
oidc：OpenID Connectプロバイダー（Auth0、Oktaなど）を使用します

SSL証明書ARN（CertificateArn）

認証を「有効」に設定した場合のみ必要です
形式：arn:aws:acm:region:account:certificate/certificate-id
重要：認証を有効にする前に、アプリケーションアクセスに使用する予定のDNSドメインをカバーする有効なAWS Certificate Manager（ACM）証明書を準備しておく必要があります

認証専用設定

新規Cognitoユーザープール設定

AuthTypeが「new-cognito」に設定されている場合、以下のパラメータが必要です：

  • Cognitoドメインプレフィックス（CognitoDomainPrefix）

  • Cognitoドメイン用の一意のプレフィックス（例：wa-analyzer）
    生成されるドメイン形式：your-prefix.auth.region.amazoncognito.com
    許可されるコールバックURL（CallbackUrls）

  • ユーザーがサインイン後にリダイレクトされるURLのカンマ区切りリスト
    アプリケーションアクセスに使用するURLに続けて/oauth2/idpresponseを含める必要があります
    例：https://wa-analyzer.example.com/oauth2/idpresponse
    ログアウトリダイレクトURL（LogoutUrl）

  • ユーザーがログアウト後にリダイレクトされるURL
    例：https://wa-analyzer.example.com
    既存Cognitoユーザープール設定
    AuthTypeが「existing-cognito」に設定されている場合、以下のパラメータが必要です：

  • 既存CognitoユーザープールARN（ExistingUserPoolArn）

  • 既存のCognitoユーザープールのARN
    形式：arn:aws:cognito-idp:region:account:userpool/pool-id
    既存CognitoクライアントID（ExistingUserPoolClientId）

  • 既存のCognitoユーザープールのクライアントID
    既存Cognitoドメイン（ExistingUserPoolDomain）

  • 既存のCognitoユーザープールのドメイン
    Cognitoプレフィックスドメイン：your-prefix.auth.region.amazoncognito.com
    またはカスタムドメイン：auth.your-domain.com
    既存CognitoログアウトURL（ExistingCognitoLogoutUrl）

  • ユーザーがログアウト後にリダイレクトされるURL
    例：https://wa-analyzer.example.com

OpenID Connect（OIDC）設定

AuthTypeが「oidc」に設定されている場合、以下のパラメータが必要です：

https://github.com/aws-samples/well-architected-iac-analyzer?tab=readme-ov-file#cloudFormation-configuration-parameters

スタックの作成が開始されました。

IaC Analyzerにアクセスしてみる

スタックを作成して10~20分程度でステータスが「CREATE_COMPLETE」に遷移します。（今回は17分でした。）
これで環境構築は完了です。
「出力」タブに「FrontendURL」というキーでWebアプリのリンクが表示されています。

リンクをクリックし、IaC Analyzerにアクセスできました。

日本語に変更

画面右上の⚙マークを選択して日本語を選択すると、日本語化することができます。

日本語に変更できました。
これで環境準備は完了です。

（おまけ）AWS Diagram MCP Serverに構成図を作ってもらう

RvのインプットとしてIaCの他に、構成図も利用できます。
いままで構成図はdraw.ioやPPT等で作ってきましたが、地味に大変です。
これもLLMにお願いしちゃいましょう。
awslabsが提供してくださっているaws-diagram-mcp-serverを使うと簡単に作成できちゃいます。
https://awslabs.github.io/mcp/servers/aws-diagram-mcp-server/

出来上がった構成図は以下の通りです。
SQSがない以外は目立ったハルシネーションもなく優秀です。

IaCをRvする

では実際にRvしてみます。
まずは「完全なIaCプロジェクト」を選択し、zip化したterraformコードをアップロードします。

次にRv対象の柱を選択します。
すべて選択するもよし、入出力トークンコスト削減のために必要な柱に絞るもよしです。
今回はせっかくなのですべて選択しましょう。

最後にオプション設定です。
特定の業界およびテクノロジー領域に特化したレンズを設定したり、出力言語や補足ドキュメント（.pdf .txt .png .jpg .jpeg）、Well-Architected Toolとの連携も可能です。
今回は「Serverless Lens」を選択してみます。

「レビューを開始」をクリックし、10分ほど待つとRvが完了します。
結果を見てみましょう。

分析結果タブ

38のベストプラクティスを確認し、12の未適用ベストプラクティスを検出することができました。

検出された指摘の中で感心したのはLambda関数のコード署名を無効化していることの指摘で、

Lambda関数のコード署名が無効化されており（.checkov.ymlでCKV_AWS_272がスキップ）、ランタイム保護が十分に実装されていません。

と、checkovのRv観点を無効化していることまで指摘してくれたことです。

さらに、右下のチャットツールを使うと詳細な解説もしてくれます。
「長時間実行が見込まれる処理において、素のLambdaではなくStepFunctionを使いましょう。」という指摘に対して詳細な説明を求めたところ、以下のようにStepFunction用のコードまで作成してくれました。
これをそのまま手動で書いてもいいですし、JSON形式でダウンロードしたチャット履歴をコーディングエージェントに渡したら良しなに実装してくれそうです。

また、この結果をcsv形式でDLすることも可能です。

Well-Architected Toolタブ

また、Well-Architected Toolタブで「Complete Well-Architected Tool Review」をクリックすると、柱と潜在するリスクレベルごとのサマリを作成してくれます。


サマリ出力例

さらに、「Generate Well-Architected Tool Report」をクリックすると、PDF形式のレポートまで出力してくれます。（ただし、出力言語は英語でした。）

構成図をRvし、IaCを生成する

次に構成図のみでRvを実施してみます。
こちらの目玉は、オプション設定の「IaC 生成」機能です。

オプション設定でIaCテンプレートタイプを選択して、「レビューを開始」します。

次に、「分析結果」タブで「IaCドキュメントを生成」をクリックします。

IaCが生成されると、グレーアウトしていた「IaC ドキュメント」が活性化します。
アーキテクチャ図に則ったCFn YAMLが生成されていました。加えて、CloudWatch等、アーキテクチャ頭上に未定義なリソースも定義されていました。

プロジェクト開始時にアーキテクチャ設計をして、このIaC 生成機能を使ってたたき台を作ってみるのはありですね。

お片付け

Rvが終わったら、分析結果やチャットログ等必要なファイルをDLして、作成されたスタックを削除しましょう。

参考 今回のRvでかかった費用

OpenSearchの費用がほぼです。
消し忘れていた時間も結構あったので、必要な時に作ってすぐ削除すればもう少しお安く済むかもしれません。

まとめ

IaC Analyzerを使ってWell-A RvをLLMに実施してもらいました。
結構お手軽だし、優秀なので「仕事なくなっちゃうな～」と思いました。
代替されない仕事ができるように頑張りたいものです。

Discussion