はじめに
JAWSイベントで同様の内容の登壇をさせていただきました
【登壇イベント】
Ops-JAWS Meetup 35 IaC CDK支部コラボレーション企画 2025年7月8日 (火)
【登壇資料】
Well-Architected Framework Review (WAFR) とは
6つの柱
Well-Architected Framework Review (WAFR、この記事ではW-Aレビューとも表現する)は、6つの柱と表現される観点を基にレビューを行うことにより、スケーラブルな設計を実現するための一貫したアプローチになっています。
6つの柱とは「運用上の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コスト最適化」「サステナビリティ」の6つになっています。
【AWSのAWS Well-Architectedに関するページURL】
柱ごとに質問とチェック項目あり
W-Aレビューには6つの柱がありますが、その1つずつに、いくつかの質問とチェック項目があります。6つの柱の質問の合計は57個の質問です。1つの質問に対しておよそ5個のチェック項目があるので、すべての柱を合計すると約300個のチェック項目があります。
必ずしもすべてのチェックの実施、すべてのベストプラクティスに合致する必要はない
チェック項目は多いですが、必ずしもすべてのチェック項目を実施する必要はありません。セキュリティを特に重要視するアーキテクチャであればセキュリティに関する柱のチェック項目をレビューし、そのほかの柱は優先順位をつけて実施順や実施要否を決めることができます。
また、すべてのチェック項目について、そのベストプラクティスに合致している必要はありません。
例えば、信頼性を重要視するため冗長構成にした場合、コスト最適化という観点からは過大になってしまう場合もあると思います。
チェック項目の詳細はAWSドキュメントで
チェックリストのみを見るとチェック項目の記載はとても端的な表現になっていますが、チェック項目の詳細が知りたい場合はAWSドキュメントを確認することができます。
AWSドキュメントを確認すると、各チェックリストごとに「期待される成果」「一般的なアンチパターン」「実装のガイダンス」などの詳細な記載があります。
この記載をかくにんすることで、なぜこのチェックが必要か、チェックに未適用が発生した場合にどのようなリスクが発生するか、リスクを回避するにはどのような手段を講じることができるかなどを学ぶことができます。
W-Aレビューはワークロードという単位で管理される
AWS Well-Architected Toolというサービスを利用することでW-Aレビューの結果を管理することができます。
W-Aレビューのチェックリストを表示してチェックを行うことができ、レビュー対象のアーキテクチャに対して質問の内容を適用しなくてよい場合もその理由を記載して保存することができます。
レビューの単位は「ワークロード」という単位で管理され、ワークロード単位にどのようなリスクが発生しているかを確認することができます。
ワークロードの単位は任意の単位で決めることができ、何か構想中のアーキテクチャについてのワークロードであったり、システムの一部の機能についてであったりと必要なレビューの範囲に合わせてワークロードを設定できます。
WAFR を実施する上での課題
W-Aの内容を把握している状態
W-Aレビューの内容を事前に把握している状態であれば、W-Aレビューにはそれほどの時間はかからないと思います。
お客様との要件定義などの打ち合わせの中や、チーム内での設計検討や設計レビューの際に自然な流れでW-Aレビューのチェック項目の話が盛り込まれ、検討され、課題が解決されるはずです。
繰り返しレビューを行う際にも、W-Aレビューの内容を把握していれば議論がスムーズです
W-Aの内容を把握していない状態
W-Aレビューのチェック項目は概算で300個あり、その1つ1つにその意義やアンチパターンや実行ガイダンスがあり、すべてを把握することは簡単ではありません。
もしもW-Aレビューの内容を全く把握せずにW-Aレビューを行う場合、レビュー対象のアーキテクチャとW-Aレビューの質問とチェック項目、チェック項目の詳細が記載されたAWSドキュメントをチェック項目の数だけ読み込みながらレビューを進める必要があり、膨大な時間が必要になります。
Well-Architected Framework Review (WAFR) の自動化とWell-Architectedパートナープログラム
「自動化」の選択肢が増えた
場合によっては多くの時間がかかるW-Aレビューですが、自動化を行うことも可能です。
AWS TrustedAdvisorとAWS Well-ArchitectedToolを連携させて、TrustedAdvisorの結果をチェック項目の判定の根拠にするような自動化は前からありましたが、最近は生成AIの技術により、生成AIにレビューを行ってもらうことが可能になりました。
そのため、今まで多くの時間がかかってしまうことでW-Aレビューに取り組みにくかった組織も、自動化によりより気軽に、効率的にW-Aレビューに取り組めるようになりました。
「自動化」はWell-Architectedパートナープログラムの「維持要件」の一部に
積極的にWell-Architected のベストプラクティスを活用してアーキテクチャを構築しているパートナー企業に関するプログラムにWell-Architectedパートナープログラムというものがあります。
1年ごとにいくつかの維持要件をクリアすることにより、継続的にパートナープログラムに参加できますが、2025年からW-Aレビューの自動化に取り組んでいることという旨の維持要件が追加されました。
全てのレビューを自動化するというものではありませんが、どのように自動化に取り組んでいるかを報告するような内容になります。
このことからもW-Aレビューにかかわる組織にとって、レビューの自動化のノウハウを持つことは必須の内容と言えます。
WAFR Acceleration with GenAI (Power)
※最後のPowerはつけない方が一般的なようです
WAFRのドキュメントを学習したAmazonBedrockがユーザーがアップロードされた設計資料を基にレビューを行う構成になっています。
AmazonTextractにより設計資料からレビュー対象のデータを抽出して、AWS StepFunctionsにより各柱のレビューを実行しています。
GitHubでCDKコードが公開されているので、お使いのAWSアカウントに導入が可能です。
【GitHub】
AWS Well-Architected IaC Analyzer
略称：IaCアナライザー
IaCアナライザーはWAFR Acceleration with GenAIと同じくAmazonBedrockによりW-Aレビューを行いますが、レビュー対象は主にCloudFormationテンプレートやCDKコードなどのIaCコードになります。
こちらもCloudFormationテンプレートがGitHubで公開されており、お使いのAWSアカウントに導入が可能です。
【GitHub】
AWS Well-Architected IaC Analyzer の判定結果
適用済み
適用済みの場合、レビューした質問とそのチェック項目、適用済みと判断した「理由」が記載されます
関連性なし
W-Aレビューの中にはシステムの外側で人が行うべき行動についても述べられており、それに関するチェックはIaCコードには表れないため「関連性なし」という判定結果になります
未適用
チェック項目の内容に適さない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レビューを人の力で行うなどの運用を検討する必要があります。
さいごに
IaCアナライザーのような生成AIを利用したレビューの自動化はレビューを効率化するために非常に有効なものであると思いました。生成AIを利用しているため、そのモデルによって精度は変わると思いますが、これからの生成AIの進化によって更なる精度向上と効率化が見込めると思います。
また、IaCコードを利用してレビューしている都合上、レビューしたい範囲とIaCコードの粒度の違いによるレビュー結果に対する懸念があります。IaCコードには表れないアーキテクチャやプロジェクト上の制約や特徴を含まないレビューになってしまうことでレビューの判断材料が不足してしまうことも懸念されます。
生成AIに任せる範囲と人が把握している範囲などを考慮してより良いレビューができるように工夫しましょう。
おまけ
登壇した際にIaCアナライザーの設定周りで少し質問をいただいたので情報を載せておきます
【IaCアナライザーのGitHub ※生成AIモデルなど諸注意も記載あり】
生成AIモデルは任意(Claude Sonnet3.5，3.7）推奨
生成AIのモデルはCloudFormationテンプレート実行時のパラメーターとして入力できます。自由入力形式になっているので、事前に有効化した生成AIモデルのIDであれば設定可能ですが、GitHubにある記載ではClaude 3.5 Sonnet とClaude 3.7 Sonnet の利用が推奨されています。
セキュリティ対策に注意
CloudFormationテンプレート実行時のデフォルトの設定内容だけでIaCアナライザーを実行した場合、IaCアナライザーのシステムのWebページにはURLを知っていればどこの誰でもアクセスできるようになっています。
もしとりあえず一時的にお試しで動かしてみたいということであればよいと思いますが、予期せぬところからアクセスされたり、不正な利用により高額な利用料を請求されたりというリスクは考える必要があります。
GitHubの記載にありますが、実際の運用ではCognitoなどの認証を有効にすることも検討してみてください(CloudFormationテンプレート実行時の任意のパラメーター設定認証設定があります）
※この記事のスライドのキャプチャは自身の登壇スライドから引用しています
【登壇資料】