こんにちは！
アジアクエスト株式会社の矢内です。
本記事は、「2025 Japan AWS Jr. Champions Qiitaリレー夏」50日目の記事です。
過去の投稿はこちらからご覧ください！
はじめに
IaC（Infrastructure as Code）を普段業務で利用されていますか？
IaC を利用することでシステムの構築・運用が効率化される一方、コードのレビューはエンジニアの目に大きく依存します。
- セキュリティは安全か
- ベストプラクティスに沿っているか
- レビュー担当者によって見るポイントがバラバラ
などは、レビュー担当者の経験や知識に左右されがちです。
AWS 公式が提供する Well-Architected IaC Analyzer（以降 IaC Analyzer と記載） を使えば、IaC コードを自動で診断し、AWS のベストプラクティスに沿った指摘を受けられます。
本記事では、IaC Analyzer の基本的な使い方と実務でどう使えるのか・どう役立つのかを深掘りします。
※ IaC Analyzer は、コードレビューのほかにも構成図の分析や、構成図から IaC コードの生成もしてくれますが、本記事はコードレビュー観点の内容となるためそれらについては触れません。
IaC Analyzer とは
IaC Analyzer は、Well-Architected Framework をベースにした IaC コード診断ツールです。
1. セキュリティ
2. 信頼性
3. パフォーマンス効率
4. コスト最適化
5. 運用上の優秀性
6. 持続可能性
これらのフレームワークをベースに、IaC コードをスキャンし、問題点を指摘してくれるツールです。
特徴と利点
メリットは以下などが挙げられます。
-
AWS 公式ルールに基づく解析
→ Well-Architected Framework を軸に診断してくれる。 -
複数の IaC コード対応
- CloudFormation (YAML/JSON)
- Terraform (.tf)
- AWS CDK
-
コードレビューの補助
→人力レビューのばらつきを減らし、見逃しを減らす。
→レビュー時間、工数の削減
一番の特徴は Well-Architected Framework 観点でレビューをするところかと思います。
Well-Architected Framework の柱は知っているけど、私自身深くは理解できていませんし、同じく柱それぞれの詳細を把握しているか自信がない方にとっては AWS 公式で診断ツールを提供してくれるのはありがたいです。
他にも Terraform や CloudFormation などの複数の IaC コードにも対応しているので、活用できるプロジェクトも幅広くあります。
IaC Analyzer のセットアップ
いくつか方法がありますが、推奨されている CloudFormation テンプレートを使用すれば簡単にデプロイができます。
デプロイ方法の詳細はこちらをご覧ください。
※前提条件として IaC Analyzer は Bedrock を使用するので、リージョン内の以下のモデルアクセスを有効にする必要があります。
- Titan Text Embeddings V2
- Claude 3.5 Sonnet v2 または Claude 3.7 Sonnet
基本的な使い方
デプロイが完了し、URL にアクセスすると IaC Analyzer の画面が表示されます。
基本的な使い方は以下になります。
- レビューしたい IaC ファイルをアップロード
- Well-Architected Framework のどの柱をレビューに含めるか選択
- オプションで以下を設定可能
- 特定のワークロード・タイプにより的を絞ったガイダンスを提供するためのレンズを選択
- 出力言語
- レビュー強化のための補足資料を追加
- 「レビューを開始」をクリック
レビューを開始してから分析に10分ほどかかりますが、上記の手順を実施するだけで簡単にレビューしてくれます。
実践：Terraform コードの分析
試しに S3 バケットを作成するシンプルな Terraform コードを分析させました。
resource "aws_s3_bucket" "sample" {
bucket = "my-sample-bucket"
}
レビュー内容に含める Well-Architected Framework の柱はすべてを選択し、オプションではレンズを標準的な「Well-Architected Framework」にしました。
レビューが終わると、画像のような柱によってどのベストプラクティスが適用されているのかなどが表示されます。
未適用については理由と推奨事項についても記載をしてくれます。
また、IaC Analyzer の機能としてチャットルールを使って詳細な説明までしてくれます。
上画像の右下にある赤く囲った部分をクリックすれば、チャットツールが開きます。
未適用のベストプラクティスが多かったのでおおまかな改善点を聞いたところ、チャットツールから以下の内容が返ってきました。
このS3バケットの定義は非常に基本的なものですが、いくつかの重要なセキュリティおよび信頼性の設定が不足しています。主な改善点を説明します：
🔒 セキュリティの改善点
- 暗号化の設定が必要
resource "aws_s3_bucket_server_side_encryption_configuration" "example" { bucket = aws_s3_bucket.sample.id rule { apply_server_side_encryption_by_default { sse_algorithm = "AES256" } } }
- パブリックアクセスのブロック
resource "aws_s3_bucket_public_access_block" "example" { bucket = aws_s3_bucket.sample.id block_public_acls = true block_public_policy = true ignore_public_acls = true restrict_public_buckets = true }📋 信頼性の改善点
- バージョニングの有効化
resource "aws_s3_bucket_versioning" "versioning" { bucket = aws_s3_bucket.sample.id versioning_configuration { status = "Enabled" } }
- ライフサイクルルールの設定
resource "aws_s3_bucket_lifecycle_rule" "rule" { bucket = aws_s3_bucket.sample.id id = "transition-to-ia" status = "Enabled" transition { days = 30 storage_class = "STANDARD_IA" } }📊 モニタリングの改善点
- アクセスログの有効化
resource "aws_s3_bucket_logging" "example" { bucket = aws_s3_bucket.sample.id target_bucket = aws_s3_bucket.log_bucket.id target_prefix = "log/" }
- タグ付けの追加
resource "aws_s3_bucket" "sample" { bucket = "my-sample-bucket" tags = { Environment = "Production" Owner = "TeamName" Project = "ProjectName" } }これらの改善を実装することで、以下のリスクを軽減できます：
- データの不正アクセスや漏洩
- 意図しないデータの削除や変更
- パフォーマンス問題の検知遅延
- コンプライアンス要件違反
- 運用管理の複雑化
特に、セキュリティと信頼性の観点から、暗号化とパブリックアクセスブロックの設定は優先度の高い改善項目として推奨します。
改善したほうがいい事項をコード付きで回答してくれました。
コードまで提案してくれるのはありがたいですね。
活用シナリオ
ここまで読んでみて IaC Analyzer 便利そうだなと感じた方もいらっしゃると思いますが、では実際に案件や実務で使うとなった際に、どういった場面で役立つかを考えていきます。
以下の表は、役割ごとに活用シナリオを整理してみました。
| 役割 | 活用シナリオ | 効果 |
|---|---|---|
| 開発者（IaC 利用者） | プルリク前に IaC Analyzer を実行してセルフチェック | レビュー前に明らかな設定不備を修正でき、指摘の往復を減らせる |
| レビュー担当者 | IaC Analyzer の結果を踏まえてレビュー | 観点のブレを防ぎ、設計や運用方針など本質的なレビューに集中できる |
| 新人エンジニア | IaC Analyzer の指摘内容を学習教材として活用 | 「なぜこの設定が必要か」がわかり、ベストプラクティスを習得しやすい |
| セキュリティチーム | 分析結果を監査的に利用 | ポリシー違反の早期発見、監査対応の効率化 |
| 運用チーム | 定期的に既存 IaC コードをスキャン | 改善ポイントの発見に役立つ |
開発者（IaC 利用者）
実際に IaC を利用する開発者にとっては、セルフレビューのツールとして非常に役に立ちます。
自分が書いたコードを IaC Analyzer に投げることで、ベストプラクティスに準拠しているかを逐一確認ができレビュー担当者からの単純な指摘を受ける頻度が減り、コードを Git で管理していればプルリク前に自分で品質を高めることが可能です。
レビュー担当者
開発者のメリットと被りますが、開発者側でセルフレビューをすることでレビュー担当者側への負担が軽減します。
レビューが属人化するとレビュー内容に差が生じやすいです。しかし、フレームワークに基づいて共通の観点を保ったままレビューを行えるので、一定の基準を保ったままコード品質を担保できます。
新人エンジニア
IaC や AWS 初心者にとっては指摘内容を学習教材として活用すれば、フレームワークに基づいた設計思想の理解やベストプラクティスの習得につながります。
チャットツールから詳細なコードの提案もしてくれるので、コーディング知識の向上も図れます。
セキュリティチーム
セキュリティ関連の分析結果を監査的に利用すれば、セキュリティポリシーに反する設定があっても早期に発見ができ、監査対応の効率化になります。
運用チーム
クラウドサービスは頻繁に更新されるため、以前は正しかった設定が非推奨になることがあります。既存の IaC コードを定期的に分析させることで、改善点を発見しやすく可視化にも役立ちます。
デメリット・懸念点
役立つケースは多いですが、デメリット・懸念点もいくつか考えられます。
1. 誤検知・過検知がある
ベストプラクティスをベースに分析するので、例えば「バージョニングを有効化せよ」と指摘されるが開発環境では不要なケースがあったり、プロジェクトポリシーや要件と推奨結果との間にずれが生じたりすることがあります。
対策：
- プロジェクトごとのガイドラインを定め、必ずしも全指摘に従わなくてもよいと明確化する
- 「本番環境」「開発環境」など用途に応じて結果を取捨選択する
2. フローに組み込まないとチーム内で使われづらい
ファイルを自分でアップロードして実行する必要があるので、手動実行では「忙しい時に忘れる」「人によって実行の有無がばらつく」といった運用の課題が出やすいです。
対策：
- 定期的に実行するスケジュール・フローを決めて運用する
- CI/CD パイプラインに組み込み、自動で分析が走るようにする
3. 大規模コードでの実行負荷
大量のリソースを記載したコードを分析すると、実行時間が大幅にかかる可能性があります。
対策：
- コードをモジュール単位で分割し、対象を絞って分析する
- 開発中は部分的なレビューを行い、リリース前に全コードを分析する運用にする
上記以外にも、IaC Analyzer 自体の実行環境の管理や使用に伴うコストの発生などがあると思います。
これらを踏まえながら、どうチーム内で実装・活用していくかを決める必要があります。
まとめ
活用できそうなシナリオおよび懸念点など挙げましたが、個人的にはとても便利なので利用したいと感じました。
実際に新システムを設計・構築する際にセキュリティやコストなど考慮しますが、しっかりと Well-Architected Framework に基づいたと自信をもって言えるシステムはあまりないかなと思います。
IaC Analyzer はそういった新システムの設計・構築時だけでなく、既存のシステムの改修にも役に立ちます。
これまで人間が行っていたレビューの負担を軽減でき、且つシステムの不備を解消するアドバイスもくれるので興味がある方は触ってみてください。
本記事では触れていませんが、構成図の分析や構成図から IaC コードの生成といった機能もあるので試してみたいですし、今後も機能の拡張など期待されるので引き続き注目していきたいと思います。
最後に
IaC Analyzer は、IaC コードを自動的に診断し、Well-Architected Framework に基づいて改善点を提示してくれる強力なツールです。
しかし、分析結果をすべて修正する必要はありません。
すべて修正しようとすると、膨大な時間と工数がかかりますし、IaC Analyzer はあくまで Well-Architected Framework に沿っているか確認できるサポートのような役割です。
実際のシステム要件・運用ポリシー・コストなどを踏まえて、人間の判断と組み合わせながら柔軟に対応することが大切だと個人的に思います。