AWS 上でワークロードを構築する際には AWS Well-Architected フレームワーク を利用してベストプラクティスに沿った対応ができているかレビューを実施し、改善ポイントを洗い出して対応します。
ただし、レビューするための準備には時間を要するため、部分的にでも自動化できれば作業の負荷を下げることができます。そこで、今回は レビュー自動化ツールとして公開されているAWS Well-Architected IaC Analyzer について、その機能を検証します。
1. AWS Well-Architected IaC Analyzer とは
AWS Well-Architected IaC Analyzer は、AWS が提供する生成AI ベースのコードレビューツールで、CloudFormation・CDK・Terraform などの IaCテンプレートが、Well-Architected Framework に準拠しているかを自動評価してくれる仕組みです。評価結果は AWS上の Well-Architectedツール にも自動的に反映されます。言語は英語だけではなく日本語にも対応されており、分析結果も日本語で表示されます。
1.1. AWS Well-Architected IaC Analyzer の操作概要
利用方法の詳細は Github に公開されている Readme をご確認ください。
操作概要は以下の通りです。
(1) 公開されている AWS Well-Architected IaC Analyzer環境構築用のテンプレートを元に CloudFormation で AWS Well-Architected IaC Analyzer 環境をデプロイします。ALB、ECS、DynamoDB、Lambda、OpenSearch Service といった必要なリソースが作成されます。スタック名は「WA-IaC-Analyzer-(リージョン名)-GenAIStack」です。
(2) 作成されたスタックの出力を確認すると、キー値：FrontendURL にアクセス用のURLが表示されます。URL から AWS Well-Architected IaC Analyzer にアクセスします。
(3) 利用したい言語を選択します。日本語に対応しています。
(4) レビューしたいテンプレートを読み込ませてレビューを開始します。１回のレビューには20～30分かかります。
(5) レビューが完了すると評価結果が表示されます。
(6) AWSマネジメントコンソールの Well-Architected ツール に結果が反映できます。
2. AWS Well-Architected IaC Analyzer の動作検証の前提条件
それでは実際の動きを検証します。
AWS Well-Architected IaC Analyzer を実行する際には複数の条件を指定する必要があります。
ここでは検証に際して指定した条件を記載します。
2.1. 利用する生成AIモデル：Claude 3.5 Sonnet v2
AWS Well-Architected IaC Analyzer では生成AIモデルを選択できます。
この選択は CloudFormation で AWS Well-Architected IaC Analyzer 環境をデプロイする際に指定できます。デプロイ後に変更することはできまないため、生成AIモデルを変更したい場合は、再度環境のデプロイをし直す必要があります。
このアプリケーションは、主に Claude 3.5 Sonnet v2 および Claude 3.7 Sonnetでテストされています。 他のBedrockモデルでも動作する可能性があります が、異なるモデルを使用すると予期しない結果が生じる可能性があります。
説明には上記の通りの記載があり、複数のモデルの中から選択することができます。
そのため、まずはどのモデルを利用するかを検討する必要がありました。
実際に確認した結果が以下の通りです。
2.1.1. Claude 3.5 Sonnet v2 の場合
正確には「us.anthropic.claude-3-5-sonnet-20241022-v2:0」を利用しました。
10回以上実行してもエラーは発生せず正常終了しました。
2.1.2. Claude 3.7 Sonnet の場合
正確には「us.anthropic.claude-3-7-sonnet-20250219-v1:0」を利用しました。
毎回エラーが発生して部分的な分析で終了しました。
例えば以下のエラーが出力します。
部分的な分析結果
エラー: AIモデルを使用したテンプレートの分析に失敗しました。Bedrockモデルの呼び出し中にエラーが発生しました: SyntaxError: JSONの位置3503に予期しない数値があります。質問「コスト最適化 - 需要と供給をどのように管理しますか？」の分析中にエラーが発生しました。分析は停止され、57件中19件の質問が分析されました。これらの部分的な結果を使用するか、数分待ってからファイル全体の分析を再度お試しください。
進捗は実施回によって異なりますが、最後まで処理を実施することができませんでした。
2.1.3. その他のモデル（Nova Pro）の場合
正確には「us.amazon.nova-pro-v1:0」を利用しました。
毎回エラーが発生して部分的な分析で終了しました。
例えば以下のエラーが出力します。
部分的な分析結果
エラー: AIモデルを使用したテンプレートの分析に失敗しました。Bedrockモデルの呼び出しエラー: 構文エラー: JSON入力の予期しない終了。質問「信頼性 - サービスのクォータと制約をどのように管理しますか？」の分析中にエラーが発生しました。分析が停止しました。57件中44件の質問が分析されました。これらの部分的な結果を使用するか、数分待ってからファイル全体の分析を再度お試しください。
進捗は実施回によって異なりますが、最後まで処理を実施することができませんでした。
ただし、Nova Pro は動作検証されていないモデルのため、エラーになるのは想定内です。
2.1.4. 検証に利用するモデルは Claude 3.5 Sonnet v2
結果として、最も安定していた「Claude 3.5 Sonnet v2」を利用しました。
2.2. 検証対象のテンプレート：BLEA（blea-gov-base-standalone）
BLEA（Baseline Environment on AWS）は、AWS Japan が提供するセキュアな初期環境構築テンプレート群で、CDKベースで実装された OSS です。AWS Well-Architected フレームワーク のセキュリティに関するベストプラクティスが実装されています。
テンプレートとして、ベースとなるセキュリティベースラインと、その環境で稼働するリソースのサンプルテンプレートが準備されています。利用方法としては、最初にガバナンスベースのテンプレートを実行してベース環境をデプロイし、その環境上にゲストシステムのサンプルで EC2 や ECS といったリソースをデプロイする流れとなります。
| 環境 | テンプレート | 内容 |
|---|---|---|
| ガバナンスベース | blea-gov-base-standalone | 単一アカウント環境向けのセキュリティベースライン |
| ガバナンスベース | blea-gov-base-ct | AWS Control Towerによるマルチアカウント環境向け |
| ゲストシステムのサンプル | blea-guest-ecs-app-sample | ECSベースのWebアプリケーション構成 |
| ゲストシステムのサンプル | blea-guest-ec2-app-sample | EC2ベースのWebアプリケーション構成 |
| ゲストシステムのサンプル | blea-guest-serverless-api-sample | Lambda/API Gatewayベースのサーバーレス構成 |
今回の検証ではこのうち単一アカウント環境向けのセキュリティベースラインである「blea-gov-base-standalone」を利用しました。テンプレート自体は cdk synth で作成された CloudFormation用のコードが記述されている「Dev-BLEAGovBaseStandalone.template.json」を利用します。
| テンプレート | 内容 | 特徴 |
|---|---|---|
| blea-gov-base-standalone | 単一アカウント環境向けのセキュリティベースライン | - CloudTrailの有効化（API呼び出しの証跡） - AWS Configの有効化（リソース構成変更の記録） - GuardDutyの有効化（脅威検知） - Security Hubの有効化（ベストプラクティス逸脱検知） - IAM Access Analyzerの有効化 - デフォルトセキュリティグループの閉塞（逸脱時の自動修復） - AWS ChatbotによるSlack通知設定 - AWS Healthイベント通知の設定 - セキュリティ関連操作の通知（一部） - CDKによる構成管理（TypeScriptベース） |
blea-gov-base-standalone の具体的な特徴は上記の通りです。あくまでベースラインであり、ワークロードで構築する VPC や EC2 といったリソースはデプロイされませんので、それに関するベストプラクティスには対応していません。また、単一アカウント向けのテンプレートであるため、マルチアカウントを前提とするベストプラクティスにも対応していません。
2.3. 柱：すべての柱
レビュー対象の柱も選択することができます。
例えばセキュリティだけをレビューしたい場合は、それだけを指定することもできます。
今回はすべての柱を選択します。
2.4. レンズ：AWS Well-Architected Framework
AWS Well-Architected フレームワークでは、複数のレンズが準備されています。
AWS Well-Architected IaC Analyzer でも対象のレンズを選択することができます。
2.4.1. レンズの種類
AWS Well-Architected IaC Analyzer で指定できるレンズは以下の通りです。
| 区分 | 内容 |
|---|---|
| コアフレームワーク | AWS Well-Architected Framework |
| 産業用レンズ | 金融サービス業界 |
| 産業用レンズ | ヘルスケア産業 |
| 産業用レンズ | 政府 |
| 産業用レンズ | 合併と買収 |
| テクノロジーレンズ | 生成AI |
| テクノロジーレンズ | サーバーレスアプリケーション |
| テクノロジーレンズ | 機械学習 |
| テクノロジーレンズ | IoT(モノのインターネット) |
| テクノロジーレンズ | SaaS(Software as a Service) |
| テクノロジーレンズ | データ分析 |
| テクノロジーレンズ | コンテナービルド |
| テクノロジーレンズ | DevOps |
| テクノロジーレンズ | 移行 |
| テクノロジーレンズ | コネクテッドモビリティ |
| テクノロジーレンズ | SAP |
2.4.2 検証に利用したレンズは AWS Well-Architected Framework
検証に利用したレンズは コアフレームワークの AWS Well-Architected Framework です。コアフレームワークは、信頼性、セキュリティ、効率、コスト効果が高く、持続可能なシステムを設計し、クラウド内で運用するためのアーキテクチャのベストプラクティスのコレクションになります。
レンズの詳細については AWS WA Tool のレンズカタログをご確認ください。
2.5. 出力言語：日本語
現在、英語、日本語、ブラジルポルトガル語、スペイン語をサポートしています。
今回の出力言語は日本語にしました。
3. AWS Well-Architected IaC Analyzer の 実施結果
それでは実際に検証を実施します。
2章で説明した以下の設定を元に AWS Well-Architected IaC Analyzer を利用したレビューを実施しました。
| 設定タイミング | 区分 | 内容 |
|---|---|---|
| 環境デプロイ時 | 生成AIモデル | us.anthropic.claude-3-5-sonnet-20241022-v2:0 |
| レビュー実行時 | 検証対象テンプレート | Dev-BLEAGovBaseStandalone.template.json |
| レビュー実行時 | 柱 | すべての柱 |
| レビュー実行時 | レンズ | AWS Well-Architected Framework |
| レビュー実行時 | 出力言語 | 日本語 |
実施した結果は以下の通り問題なく完了します。
また、分析結果は一覧で表示されます。
フィルタをかけて絞り込んだり、EXCELに出力することもできます。
画面上でフィルターをかける際や EXCEL 出力結果を分析する際にも重要になってくるのが、「Applied（適用済み）」と「Relevant（関連する）」の項目です。「Applied」はベストプラクティスが適用されているかどうかを YES/NO で回答しています。そして「Relevant」はベストプラクティスが IaCコードに関連しているかどうかを YES/NO で回答しています。AWS Well-Architectedフレームワーク のベストプラクティスにはシステム外で対応するべき項目も多々あり、ここでは 73件がそれに該当しました。この結果から IaCコードで対応できるのは「未適用ベストプラクティスとして評価された 114件であることが分かります。
次に、「適用済みベストプラクティス」「未適用ベストプラクティス」「関連性なしベストプラクティス」の 3つの区分に関して、どのような出力がされるか一部のデータを元に紹介します。
3.1. 適用済みベストプラクティス
「適用済みベストプラクティス」は、「Applied（適用済み）」が YES、「Relevant（関連する）」が YES の組み合わせです。以下のようにベストプラクティスが適用済みと判断した理由が回答されています。例えば 1行目のベストプラクティスは「運用の可視性を確保するためにステータスと傾向を伝える」ですが、コードを読み取って SNSトピックと Slackチャネルを連携している設定を確認して、適用済みと判断してくれています。他の項目についても、同様にコードを確認して判断してくれます。
3.2. 未適用ベストプラクティス
「未適用ベストプラクティス」は、「Applied（適用済み）」が NO、「Relevant（関連する）」が YES の組み合わせです。以下の画面のように未適用であると判断した理由と、推奨事項の対策について回答されます。例えば1行目のベストプラクティスは「ダッシュボードを作成する」ですが、コードを読み取って、コード上にCloudWatchダッシュボード作成の定義がないことを確認した上で、推奨事項としてダッシュボードの作成を提案しています。
この後は、どのようにコードを記載するか検討する必要がありますが、このツールではコードの提案も実施されます。対象のベストプラクティスを選択して「詳細を取得」を選択すると、以下のようにコードの案内もしてくれます。この案内を元にコードの修正を実施することができます。
3.3. 関連性なしベストプラクティス
「関連性なしベストプラクティス」は、「Applied（適用済み）」が NO、「Relevant（関連する）」が NO の組み合わせです。以下の画面のようにステータスに「関連性なし」と回答されます。例えば ３行目のベストプラクティスは「外部顧客のニーズを評価する」ですが、これはコードで解決できる内容ではありません。そういったベストプラクティスが関連性なしと判断されます。
以上が3つの区分に対する結果内容となります。
また、この結果を AWSマネジメントコンソールの Well-Architectedツール に簡単に反映することができます。ツールの以下の画面で「Complete Well-Architected Tool Review」を選択すると Well-Architectedツールへの反映処理が実施されます。
正常終了すると、以下の通り作成されたワークロードID と反映結果が表示されます。
AWSマネジメントコンソールの Well-ArchitectedツールでワークロードIDを確認すると、以下の通りワークロードが作成されていることが分かります。
なお、先ほどのツールの「関連性なしベストプラクティス」の項目については、Well-Architectedツールでは該当なしと評価されているのでご注意ください。必要に応じて修正入力する必要があります。
4. AWS Well-Architected IaC Analyzer の 複数回実施結果
複数回同じ条件で実行していると、毎回結果に差異が発生します。
検証のために先ほどと同じ条件で10回実施した結果は以下の通りです。
適用済みベストプラクティスの降順に結果を並べていますが、最大が 122件なのに対して最小は 105件と、その判断には 17件の差が出ています。生成AIを利用しているので毎回同じ回答が返ってくるわけではありませんが、この差異の内容は気になります。なので、この章では、この差異について深堀します。
検証のため 10回実施したうちの以下の 2回の分析結果を抽出して、その結果の違いを確認しました。
まず、適用済みベストプラクティス数が 120件で同じなので、判断が全く同じと思われるかもしれませんが、実際には 120件の内容自体にも差異があります。例えば 1回目はベストプラクティスが適用されていると判断しているが、2回目は未適用と判断されたケースが 18件あります。また逆のパターンも 18件あるため、合計で 36件の差異があります。全体のチェックの中では 12%ですが、この差異がどのような内容なのかを確認します。
4.1. Security
まずは Security です。この柱は 1回目と 2回目の実施結果の差異が 2件（3%）でした。項目数が多い割にはあまり差異が発生していません。
発生した差異について 2件とも確認します。
| 区分 | 内容 |
|---|---|
| 柱 | Security |
| 問題 | SEC 5. ネットワークリソースはどのように保護するのですか。 |
| Best Practice | SEC05-BP03 検査に基づく保護を実装する |
| 適用評価理由 | [From Template] GuardDutyの有効化（DetectionGuardDutyDetector）、SecurityHubの設定（DetectionSecurityHub）、CloudTrailログの監視（DetectionCloudTrailChangeEventRule）など、トラフィックの検査とセキュリティ監視の仕組みが実装されています。 |
| 不適用評価理由 | [From Template] AWS WAF、Network Firewall、VPCトラフィックミラーリングなどのトラフィック検査メカニズムが実装されていません。現状のテンプレートには、トラフィックの深い検査を行うための機能が含まれていません。 |
上記の結果となります。本来どちらの判定になるかですが、このベストプラクティスでは不適用評価理由で言及されている機能が求められており、現状は未実装のため、「不適用」の評価が正しいです。
| 区分 | 内容 |
|---|---|
| 柱 | Security |
| 問題 | SEC 7. どのようにデータを分類していますか? |
| Best Practice | SEC07-BP03 識別および分類を自動化する |
| 適用評価理由 | [From Template] テンプレートには、AWS SecurityHubとGuardDutyが構成され、自動的にセキュリティイベントを識別・分類し、重要度に基づいて通知を行う機能が実装されています。また、CloudWatch Logsのメトリクスフィルターにより、特定のセキュリティイベントを自動的に識別・分類しています。 |
| 不適用評価理由 | [From Template] テンプレートには、Amazon MacieやAmazon Comprehendなどの自動データ識別・分類サービスの実装が含まれていません。現在の実装は、主にログデータの保護に焦点を当てています。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスの場合セキュリティイベントの検知やログ監視は補完的な要素であり、主目的は「データそのものの識別と分類」です。求められるのは Amazon Macie や Amazon Comprehend の実装ですが、実装されていないため、「不適用」の評価が正しいです。
4.2. Cost Optimization
次は Cost Optimization です。この柱は 1回目と 2回目の実施結果の差異が 7件（14%）でした。
| 区分 | 内容 |
|---|---|
| 柱 | Cost Optimization |
| 問題 | COST 2. どのように使用状況を管理するのですか? |
| Best Practice | COST02-BP02 目標およびターゲットを策定する |
| 適用評価理由 | [From Template] AWS Config ルールとCloudWatch アラームが実装されており、リソースの使用状況を監視し、特定のメトリクスに基づいて通知を行う仕組みが構築されています。例えば、UnauthorizedAttemptsEventCountなどのメトリクスが設定され、目標値に対する監視が行われています。 |
| 不適用評価理由 | [From Template] テンプレートには、コストや使用量の目標を設定・追跡するための具体的なメカニズムが実装されていません。CloudWatch Alarmsは実装されていますが、それらはセキュリティ監視用であり、コスト最適化の目標追跡用ではありません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、コストと使用量に関する明確な目標設定とその達成状況の追跡を求めています。適用評価理由で記載されているのはセキュリティに関する監視でありコストの監視ではないため、「不適用」の評価が正しいです。
| 区分 | 内容 |
|---|---|
| 柱 | Cost Optimization |
| 問題 | COST 2. どのように使用状況を管理するのですか? |
| Best Practice | COST02-BP03 アカウント構造を実装する |
| 適用評価理由 | [From Template] テンプレートはスタンドアロンアカウント用のガバナンスベース構成を実装しており、適切なアカウント構造が考慮されています。CloudTrail、GuardDuty、SecurityHubなどの重要なセキュリティサービスが単一アカウント内で適切に構成されています。 |
| 不適用評価理由 | [From Template] テンプレートはスタンドアロンアカウント用に設計されており、AWS Organizations構造や複数アカウント管理の実装が含まれていません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、単一アカウントでのセキュリティサービス構成ではなく、AWS Organizations を用いた複数アカウント構成の実装を求めています。今回のテンプレートはスタンドアロン（単一アカウント）が前提となっているため、「不適用」の評価が正しいです。
4.3. Performance Efficiency
次は Performance Efficiency です。この柱は 1回目と 2回目の実施結果の差異が 5件（16%）でした。
| 区分 | 内容 |
|---|---|
| 柱 | Performance Efficiency |
| 問題 | PERF 1. ワークロードに適切なクラウドリソースとアーキテクチャを選択するにはどうすればよいでしょうか? |
| Best Practice | PERF01-BP07 データ駆動型のアプローチでアーキテクチャを選択する |
| 適用評価理由 | [From Template] メトリクスとアラートを活用したデータ駆動のアプローチが実装されています。CloudWatchメトリクスフィルター、アラーム、EventBridgeルールを使用して、システムの状態を監視し、異常を検出する仕組みが構築されています。 |
| 不適用評価理由 | [From Template] アーキテクチャの選択が、収集したメトリクスやデータに基づいて行われている証拠が見られません。CloudWatchアラームは設定されていますが、それらのメトリクスがアーキテクチャの決定に活用されている形跡がありません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、CloudWatch や EventBridge の設定そのものではなく、それらから得られたデータを用いてアーキテクチャを選定・改善しているかどうかを評価します。今回のテンプレートではそれが明示されていないので、テンプレートの内容だけでは判断できないという意味でも「不適用」の評価が正しいです。
4.4. Sustainability
次は Sustainability です。この柱は 1回目と 2回目の実施結果の差異が 7件（24%）でした。
| 区分 | 内容 |
|---|---|
| 柱 | Sustainability |
| 問題 | SUS 2 クラウドリソースを需要に合わせる方法 |
| Best Practice | SUS02-BP03 未使用アセットの創出と維持の停止 |
| 適用評価理由 | [From Template] S3バケットのライフサイクルポリシー、CloudTrailログの保持期間設定（90日）、およびS3バケットのバージョニング管理が実装されており、未使用アセットの管理が適切に行われています。 |
| 不適用評価理由 | [From Template] テンプレートには未使用アセットの特定や自動削除のためのライフサイクルポリシーが実装されていません。S3バケットやその他のリソースに対する未使用アセットの管理メカニズムが見られません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、テンプレートを確認すると 作成する一部の S3 バケットにはライフサイクルポリシーの適用がされており、Gracier への移行や削除が設定されています。すべてのバケットではないため不適用評価と判断されていますが、必要なバケットには設定がされているので、「適用」の評価が正しいです。
| 区分 | 内容 |
|---|---|
| 柱 | Sustainability |
| 問題 | SUS 4 データ管理のポリシーとパターンをどのように利用して、持続可能性目標を達成しますか? |
| Best Practice | SUS04-BP08 データは再作成が難しい場合にのみバックアップする |
| 適用評価理由 | [From Template] CloudTrailログやConfigログなど、再作成が困難な重要な監査データのみがバックアップされており、不要なデータのバックアップを避けています。 |
| 不適用評価理由 | [From Template] テンプレートではすべてのCloudTrailログとConfigログが無条件でバックアップされており、再作成の難易度に基づく選択的なバックアップ戦略が実装されていません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、再作成が困難なデータのみをバックアップ対象とし、不要なバックアップを避けることで環境負荷とコストを削減することを評価します。CloudTrailログと Configログのデータは再作成が困難なデータであり、網羅的に取得することが求められる類のデータであるため、すべて取得していることが間違いではありません。そのため、「適用」の評価が正しいです。
4.5. Operational Excellence
次は Operational Excellence です。この柱は 1回目と 2回目の実施結果の差異が 12件（18%）でした。
| 区分 | 内容 |
|---|---|
| 柱 | Operational Excellence |
| 問題 | OPS 5. どのようにして欠点を減らし、修正を簡単にし、本番環境へのフローを改善しますか? |
| Best Practice | OPS05-BP02 変更をテストし、検証する |
| 適用評価理由 | [From Template] Config Rulesを使用して、セキュリティグループ、IAMポリシー、EBSボリュームなどの設定変更を自動的に検証しています。また、CloudTrailとCloudWatchメトリクスを通じて変更の監視と検証を行っています。 |
| 不適用評価理由 | [From Template] テンプレート内にテスト環境の設定や自動テストの実装が見られません。また、変更の検証プロセスを示す設定も含まれていません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、本番環境に変更を加える前に、テストと検証を行うことを求めています。今回のテンプレートに事前テストの仕組みはないため、「不適用」の評価が正しいです。
| 区分 | 内容 |
|---|---|
| 柱 | Operational Excellence |
| 問題 | OPS 5. どのようにして欠点を減らし、修正を簡単にし、本番環境へのフローを改善しますか? |
| Best Practice | OPS05-BP10 統合とデプロイを完全自動化する |
| 適用評価理由 | [From Template] CloudFormationテンプレートを使用してインフラストラクチャの自動プロビジョニングを実装し、AWS Configによる自動設定チェック、CloudTrailによる監査証跡の自動記録、SecurityHubとGuardDutyによる自動セキュリティ監視が実装されています。 |
| 不適用評価理由 | [From Template] CI/CDパイプライン、自動テスト、自動デプロイメントなどの完全な自動化が実装されていません。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、CloudFormation や Config による構成管理ではなく、CI/CDパイプラインによる統合・テスト・デプロイの自動化を評価します。今回のテンプレートにその仕組みはないため、「不適用」の評価が正しいです。
4.6. Reliability
次は Reliability です。この柱は1回目と2回目の実施結果の差異が3件（5%）でした。
| 区分 | 内容 |
|---|---|
| 柱 | Reliability |
| 問題 | REL 1. Service Quotas と制約はどのように管理するのですか。 |
| Best Practice | REL01-BP05 クォータ管理を自動化する |
| 適用評価理由 | [From Template] AWS Config Rules、CloudWatchアラーム、自動修復アクションの組み合わせにより、クォータ管理の自動化が実装されています。特にデフォルトセキュリティグループの自動修復が含まれています。 |
| 不適用評価理由 | [From Template] テンプレートには、Service Quotasの自動管理やクォータ増加要求の自動化機能が実装されていません。現在の実装は監視のみに留まっています。 |
上記の通りの結果となります。本来どちらの判定になるかですが、このベストプラクティスでは、AWSサービスのクォータに関する監視・通知・増加要求までを自動化することを目的としています。適用評価理由で記載されているセキュリティグループの設定変更はこの項目の内容と合致していませんし、コードには AWS Config Rulesにもクォータ管理に関する設定が記載されていません。クォータ自動化に関する設定がテンプレートに含まれていないため、「不適用」の評価が正しいです。
4.7. 検証の結果
複数回実施した際に発生している差分の多くは、本来「不適用」のベストプラクティスに対して拡大解釈をして「適用」扱いにしているものが多くみられました。そのため、実行後の分析結果チェックは必要です。
ただし、結果的に ８割以上の項目に関しては的確な回答をしてくれており、対応方法や対応するためのコードまで提案してくれるので有用なツールだと感じます。
5. AWS Well-Architected IaC Analyzer の利用料金
AWS Well-Architected IaC Analyzer を利用すると発生する費用について説明します。
5.1. AWS Well-Architected IaC Analyzer 環境の利用料（日額）
AWS Well-Architected IaC Analyzer を利用する際には、CloudFormation で AWS Well-Architected IaC Analyzer 環境をデプロイする必要があります。デプロイすると ALB、ECS、DynamoDB、Lambda、OpenSearch Service といった必要なリソースが作成されます。
私がバージニア北部（us-east-1）リージョンで環境をデプロイした際に発生した日額利用料は以下の通りです。14.09 USD なので 150円/USD換算だと 2,114円です。一番利用料に影響しているのが OpenSearch Service で、利用料の80%がこのサービス利用料です。
| # | サービス名 | USD（日額） |
|---|---|---|
| 1 | OpenSearch Service | 11.52 |
| 2 | EC2その他 | 1.08 |
| 3 | Elastic Container Service | 0.59 |
| 4 | Elastic Load Balancing | 0.54 |
| 5 | VPC | 0.36 |
| 6 | S3 | 極微量 |
| 7 | EC2 Container Registry | 極微量 |
| 8 | DynamoDB | 極微量 |
| 9 | CloudWatch | 極微量 |
| 10 | 合計 | 14.09 |
デプロイしたままにすると毎日 2,000円以上もかかってしまうので、AWS Well-Architected IaC Analyzer は利用したいときだけ CloudFormation でデプロイし、利用が終わったらすぐに削除する運用をお勧めします。
5.2. AWS Well-Architected IaC Analyzer を利用したレビュー費用（1回）
デプロイした環境でレビューを 1回実施する際に発生する費用について記載します。
こちらは実行画面の選択肢によっても大きく変わります。
今回は以下の条件が前提となります。
| 設定タイミング | 区分 | 内容 |
|---|---|---|
| 環境デプロイ時 | リージョン | バージニア北部（us-east-1） |
| 環境デプロイ時 | 生成AIモデル | us.anthropic.claude-3-5-sonnet-20241022-v2:0 |
| レビュー実行時 | 検証対象テンプレート | Dev-BLEAGovBaseStandalone.template.json |
| レビュー実行時 | 柱 | すべての柱 |
| レビュー実行時 | レンズ | AWS Well-Architected Framework |
| レビュー実行時 | 出力言語 | 日本語 |
レビューを実施すると Claude 3.5 Sonnet v2 の AWS利用料が処理内容に応じて発生します。それ以外に Lambda等の利用料も発生しますが、極微量なので割愛しています。今回の条件の場合は 1回のレビューあたり 11.5 USD が発生します。150円/USD換算だと 1,725 円です。
| # | サービス名 | USD（1回） |
|---|---|---|
| 1 | Claude 3.5 Sonnet v2 ( Bedrock Edition) | 11.5 |
6. まとめ
この投稿内容のまとめは以下の通りです。
興味のある方は AWS Well-Architected IaC Analyzer を是非活用してみてください。
| # | 内容 |
|---|---|
| 1 | AWS Well-Architected IaC Analyzer を利用することで IaCテンプレートベースのレビュー自動化が可能。 |
| 2 | 選択する生成AIモデルは Claude 3.5 Sonnet v2 が最も安定している。 |
| 3 | AWS Well-Architected IaC Analyzer は 日本語対応している。 |
| 4 | AWS Well-Architected IaC Analyzer は実施結果として、ベストプラクティスの適用状況、未適用状況を回答してくれる。未適用の場合の対策のための IaCコードの提案もしてくれる。 |
| 5 | AWS Well-Architected IaC Analyzer は実施結果を AWSマネジメントコンソールの AWS Well-Architectedツールに反映してくれる。 |
| 6 | AWS Well-Architected IaC Analyzer は同じ条件で複数回実行すると結果に差異が発生する。 |
| 7 | 差異内容を確認すると、本来「未適用」のベストプラクティスに対して、拡大解釈の判断をして「適用」扱いにしていることが多い。そのため、レビュー結果については人間のチェックも必要不可欠。 |
| 8 | AWS Well-Architected IaC Analyzer 環境をデプロイしたままにしていると 1日あたり 2,000円以上 AWS利用料が発生するので、レビューが終わったらすぐに削除する運用を推奨。 |
※ 記載されている会社名および商品・製品・サービス名は、各社の商標または登録商標です。