【AWS】WAFRの新常識!? IaCコードからレビューを効率化【IaCアナライザー】

はじめに

適切な運用や実装ができているかの尺度の一つとしてのAWS Well-Architected Framework

AWSを活用したシステムが適切に作れているか、適切に運用できているか、どのようなリスクがあるかをチェックする際に、標準的なチェック材料として「AWS Well-Architected Framework」というものがあります。

レビューには時間がかかり、人の知識や経験に依存する

このAWS Well-Architected Frameworkのすべてのチェック項目を人手でチェックしようと思うとかなりの時間を要する場合があります。
チェックの精度も担当者の経験や知識によってばらつきが出るため、AWS Well-Architected Frameworkによるレビュー(WAFR)に慣れていない間は非常に多くの時間がかかることやリスクの見落としなどの多くの課題が発生します。

今回の記事では、生成AIを利用した自動レビューの1つであるIaCジェネレーターを利用したレビュー方法について記載しました。
この記事の内容を、IaCジェネレーターによる自動レビューがどのようなものなのか、どのようなケースで有効に活用できるのか、どのような課題があるかについて考えるヒントにしていただければと思っています。
※この記事では AWS Well-Architected Frameworkレビューを「WAFR」と表現しています

↓ この記事の海外向け版はこちら

JAWSイベントで同様の内容の登壇をさせていただきました

2025年7月8日に行われた「Ops-JAWS Meetup35 IaC CDK支部コラボレーション企画」にてこの記事と同様の内容の登壇をさせていただきました。

【登壇イベント】

Ops-JAWS Meetup 35 IaC CDK支部コラボレーション企画　2025年7月8日 (火)

【登壇資料】

Well-Architected Framework Review (WAFR) とは

6つの柱(観点)でのレビュー

Well-Architected Framework Review (WAFR、この記事ではWAFRとも表現する)は、6つの柱と表現される観点を基にレビューを行うことにより、スケーラブルな設計を実現するための一貫したアプローチになっています。
6つの柱とは「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」「サステナビリティ」の6つになっています。

【AWSのAWS Well-Architectedに関するページURL】

柱ごとに質問とチェック項目がある

WAFRには6つの柱がありますが、その1つずつに、いくつかの質問とチェック項目があります。6つの柱の質問の合計は57個の質問です。1つの質問に対しておよそ5個のチェック項目があるので、すべての柱を合計すると約300個のチェック項目があります。

必ずしもすべてのチェックの実施、すべてのベストプラクティスに合致する必要はない

チェック項目は多いですが、必ずしもすべてのチェック項目を実施する必要はありません。セキュリティを特に重要視するアーキテクチャであればセキュリティに関する柱のチェック項目をレビューし、そのほかの柱は優先順位をつけて実施順や実施要否を決めることができます。
また、すべてのチェック項目について、そのベストプラクティスに合致している必要はありません。
例えば、信頼性を重要視するため冗長構成にした場合、コスト最適化という観点からは過大になってしまう場合もあると思います。

チェック項目の詳細はAWSドキュメントで確認可能

チェックリストのみを見るとチェック項目の記載はとても端的な表現になっていますが、チェック項目の詳細が知りたい場合はAWSドキュメントを確認することができます。
AWSドキュメントを確認すると、各チェックリストごとに「期待される成果」「一般的なアンチパターン」「実装のガイダンス」などの詳細な記載があります。
この記載をかくにんすることで、なぜこのチェックが必要か、チェックに未適用が発生した場合にどのようなリスクが発生するか、リスクを回避するにはどのような手段を講じることができるかなどを学ぶことができます。

WAFRはワークロードという単位で管理される

AWS Well-Architected Toolというサービスを利用することでWAFRの結果を管理することができます。
WAFRのチェックリストを表示してチェックを行うことができ、レビュー対象のアーキテクチャに対して質問の内容を適用しなくてよい場合もその理由を記載して保存することができます。
レビューの単位は「ワークロード」という単位で管理され、ワークロード単位にどのようなリスクが発生しているかを確認することができます。
ワークロードの単位は任意の単位で決めることができ、何か構想中のアーキテクチャについてのワークロードであったり、システムの一部の機能についてであったりと必要なレビューの範囲に合わせてワークロードを設定できます。

WAFR を実施する上での課題

W-Aの内容を把握している状態ではスムーズに実施できる

通常の仕様検討やレビュープロセスの中に自然にチェック観点を含められる

WAFRの内容を事前に把握している状態であれば、WAFRにはそれほどの時間はかからないと思います。
お客様との要件定義などの打ち合わせの中や、チーム内での設計検討や設計レビューの際に自然な流れでWAFRのチェック項目の話が盛り込まれ、検討され、課題が解決されるはずです。
繰り返しレビューを行う際にも、WAFRの内容を把握していれば議論がスムーズです

W-Aの内容を把握していない状態では非常に時間がかかる

チェック項目は全部で約300個

WAFRのチェック項目は概算で300個あり、その1つ1つにその意義やアンチパターンや実行ガイダンスがあり、すべてを把握することは簡単ではありません。
もしもWAFRの内容を全く把握せずにWAFRを行う場合、レビュー対象のアーキテクチャとWAFRの質問とチェック項目、チェック項目の詳細が記載されたAWSドキュメントをチェック項目の数だけ読み込みながらレビューを進める必要があり、膨大な時間が必要になります。

WAFR の自動化とWell-Architectedパートナープログラム

自動化にかかわる時間や、一貫性を保つための対策として、自動化を実現する技術がいくつか登場しました。

時間がかかる課題改善に「自動化」という選択肢

生成AIによるレビュー支援

場合によっては多くの時間がかかるWAFRですが、自動化を行うことも可能です。
AWS TrustedAdvisorとAWS Well-ArchitectedToolを連携させて、TrustedAdvisorの結果をチェック項目の判定の根拠にするような自動化は前からありましたが、最近は生成AIの技術により、生成AIにレビューを行ってもらうことが可能になりました。
そのため、今まで多くの時間がかかってしまうことでWAFRに取り組みにくかった組織も、自動化によりより気軽に、効率的にWAFRに取り組めるようになりました。

「自動化」はWell-Architectedパートナープログラムの「維持要件」の一部に

積極的にWell-Architected のベストプラクティスを活用してアーキテクチャを構築しているパートナー企業に関するプログラムにWell-Architectedパートナープログラムというものがあります。
1年ごとにいくつかの維持要件をクリアすることにより、継続的にパートナープログラムに参加できますが、2025年からWAFRの自動化に取り組んでいることという旨の維持要件が追加されました。
全てのレビューを自動化するというものではありませんが、どのように自動化に取り組んでいるかを報告するような内容になります。
このことからもWAFRにかかわる組織にとって、レビューの自動化のノウハウを持つことは必須の内容と言えます。

WAFR Acceleration with GenAI

WAFRのドキュメントを学習したAmazonBedrockがユーザーがアップロードされた設計資料を基にレビューを行う構成になっています。
AmazonTextractにより設計資料からレビュー対象のデータを抽出して、AWS StepFunctionsにより各柱のレビューを実行しています。
GitHubでCDKコードが公開されているので、お使いのAWSアカウントに導入が可能です。

【GitHub】

AWS Well-Architected IaC Analyzer（IaCアナライザー）

IaCコードをベストプラクティスに沿って評価する

IaCアナライザーはWAFR Acceleration with GenAIと同じくAmazonBedrockによりWAFRを行いますが、レビュー対象は主にCloudFormationテンプレートやCDKコードなどのIaCコードになります。

IaCコード、アーキテクチャ図、PDFドキュメントを分析可能

IaCコードはCloudFormtion、Terraform、CDKのコードが分析可能です。
IaCコード以外ではアーキテクチャ図の画像ファイル(PNG/JPEG/JPG形式)、PDFのドキュメント(テキストや図が記載されたもの)が分析可能です。

分析項目は用途に応じて選択可能

WAFRの各チェック項目すべてをチェックすることも可能ですが、選択した柱のみの分析や、専門分野に最適化されたレンズを選択してその内容をチェックすることも可能です。

GitHubでCloudFormationテンプレートが公開されている

こちらもCloudFormationテンプレートがGitHubで公開されており、お使いのAWSアカウントに導入が可能です。

【GitHub】

AWS Well-Architected IaC Analyzer の判定結果

適用済み

適用済みの場合、レビューした質問とそのチェック項目、適用済みと判断した「理由」が記載されます。
上記の図では「OPS01-BP04 コンプライアンス要件を評価する」の項目に関して、S3バケットの暗号やCloudFrontでのHTTPS強制の実装がこの項目の適用済みの理由とされています。

関連性なし

W-Aレビューの中にはシステムの外側で人が行うべき行動についても述べられており、それに関するチェックはIaCコードには表れないため「関連性なし」という判定結果になります
上記の図では「OPS02-BP02 プロセスと手順に特定の所有者が存在する」のチェックについて関連性なしと判定されています。このチェック項目はシステム運用担当の役割に関する内容のため、関連性なしという判定が妥当です。

未適用

チェック項目の内容に適さないIaCコードになっている場合、そのチェック項目は「未適用」と判定されます。
未適用の項目ではレビューした質問とチェック項目、理由の他に「推奨事項」が記載されます。
推奨事項は該当のチェック項目を「適用済」にするためのヒントが記載されます。

生成AIとチャットでやり取りして、理解を深める

推奨事項欄にあるキラキラマークや、画面右下のWellArchitectedマークをクリックすると生成AIとのチャットダイアログが開きます。
この生成AIとのチャットを利用して、未適用項目の対策について具体的なIaCコードを提案してもらったりしてWell Architectedについての理解を深めることができます。

チャットでのやり取りは英語で始まりますが、日本語での回答を依頼すると以降のやり取りを日本語で行うことができます。

AWS Well-Architected IaC Analyzer　運用に関する課題(個人的見解)

本質的に必要な改善が判断しにくい

検証：適用済みの項目の理由の一部を未適用の状態に変更した

結果：未適用扱いに結果が変わったが、推奨事項は変更した内容とは異なる内容になった

「適用済み」と判断されたチェック項目の理由を確認し、その理由をなくすような変更をIaCコードに加えることにより「未適用」として判定されるかを検証してみました。
IaCコードに加えた変更はCloudFrontのHTTPS強制の設定を無くすものです。これにより、コンプライアンスに関するチェック項目の判定が「未適用」になるはずです。
結果は判定が「未適用」となりましたが、判定した「理由」と、適用済みにするための「推奨事項」の項目が今回変更を加えたCloudFrontのHTTPS強制についてのピンポイントの推奨事項ではなく、Configを利用するなどより一般的な推奨事項になっていました。

「未適用」項目の推奨事項は一般論であり、本質的な推奨事項ではないのではないか？

クリティカルな問題であればピンポイントの問題点を修正することは優先的に行わなければなりません。それと同時に一般論でのベストプラクティスに関する推奨事項を無視してよいというわけではありません。
一般論での推奨事項を行うことは大切ですが、それにより必要以上の工数がかかったりコスト増につながることもあります。あるいはそのアーキテクチャが持つ独自の課題の解決が見落とされる場合もあります。そのため、一般論の推奨事項に頼ることも危険と言えます。
W-Aレビューを行うアーキテクチャにとってどのような改善を行うことが本質的に正しいのかはIaCアナライザーの結果のみに頼らず、人の経験や知識と合わせて考えることで答えを出す必要がありそうです。

必要なレビューの粒度がIaCコードの粒度と合わない場合がある

IaCアナライザーのレビュー粒度はアップロードしたIaCコード範囲

IaCアナライザーはその名前が示す通りIaCコードを基にレビューを行います。そのため、レビューの範囲はIaCコードの範囲(CloudFormationでいうところのスタック)になります。

人がレビューしたい範囲は時と場合による

人がアーキテクチャのレビューを行う際の範囲は時と場合によって様々です。アーキテクチャ全体をレビューしたい場合もあれば、アーキテクチャのある一部の範囲の機能の集まりをレビューしたい場合もあります。また、改修案件ごとにレビューしたい場合もあれば、チームが担当している範囲でレビューしたい場合もあります。
IaCコードが人がレビューしたい範囲で分割されていない場合、レビューしたい範囲ではないIaCコードの内容でレビュー結果を「適用済み」や「未適用」が判定され、関係がない推奨事項を提案される可能性があります。

IaCコードをレビューしたい範囲に合わせるのか、人がIaCコードの結果をうまく利用した運用を行うのか

もし仮にIaCコードをレビューしたい範囲に分割できれば必要な範囲でレビューができますが、レビューしたい範囲はその時々で変わるので実際にはレビューしたい範囲でIaCコードの分割を変えるのは難しいと思います。
そのため、IaCアナライザーの結果の「理由」などから判定の根拠になったIaCコードの記載が目的のレビュー範囲内のものかを確認し、範囲外であれば理由にある同様の内容がレビュー範囲内にあるか、範囲内になければW-Aレビューを人の力で行うなどの運用を検討する必要があります。

セキュリティ対策に注意

CloudFormationスタック作成時に認証をFalseにした場合、認証画面がIP制限の設定は行われません。
つまり、IaCアナライザーのシステムのWebページにはURLを知っていればどこの誰でもアクセスできるようになっています。
↓スタック作成時の認証に関するパラメーター

もしも、とりあえず一時的にお試しで動かしてみたいということであればよいと思いますが、予期せぬところからアクセスされたり、不正な利用により高額な利用料を請求されたりというリスクは考える必要があります。

セキュリティ対策①ALBのセキュリティグループ

ALBのセキュリティグループに対して自身のPCもしくは社内のネットワークのIPからのアクセスのみ許可する設定を行うことにより、アクセス元の制限を書けることが可能です

セキュリティ対策②Cognito認証

各IPの設定が手間になる場合は、スタック作成時にも指定できるAmazonCognitoを利用することで、IaCアナライザーの画面の前にAmazonCognitoの認証画面を設定することが可能です。
このAmazonCognitoの認証を行うことにより、ユーザープールに登録されたメールアドレスやパスワードが一致したユーザーのみIaCアナライザーにアクセスさせることが可能です。

スタック作成時にはすでに作成済みのCognitoと連携するか、スタック作成時に新たにCognitoを設定することができます
↓スタック作成時のCognitoの設定選択

さいごに

IaCアナライザーのような生成AIを利用したレビューの自動化はレビューを効率化するために非常に有効なものであると思いました。生成AIを利用しているため、そのモデルによって精度は変わると思いますが、これからの生成AIの進化によって更なる精度向上と効率化が見込めると思います。
また、IaCコードを利用してレビューしている都合上、レビューしたい範囲とIaCコードの粒度の違いによるレビュー結果に対する懸念があります。IaCコードには表れないアーキテクチャやプロジェクト上の制約や特徴を含まないレビューになってしまうことでレビューの判断材料が不足してしまうことも懸念されます。
生成AIに任せる範囲と人が把握している範囲などを考慮してより良いレビューができるように工夫しましょう。

IaCアナライザーによるレビューが有効なケースの例 ※個人的な意見

• 優先度が低いチェック項目で人手によるレビューの時間が取れない場合に不足分のレビューを補う
• 本格的なレビューを行う前に、各項目を短時間でざっとレビューして改善項目の候補を把握したい場合
• 人手によるレビューを行った後で、別の観点でのレビュー漏れがないか確認するために自動レビューで再度チェックする

※この記事のスライドのキャプチャは自身の登壇スライドから引用しています
【登壇資料】