アーキテクチャー設計と 生成AIによるTerraform IaC テンプレートの作り方 AWS

Transcript

1. JAWS-UG 磐田 勉強会 ／ もくもく会 アーキテクチャー設計と 生成AIによる Terraform IaC テンプレートの作り方 AWS Terraform Claude Code 前半：解説 アーキテクチャー設計 & IaC × 生成AI 発表者：伊藤 秀樹
2. PROFILE 本日の発表者 伊藤 秀樹 （いとう ひでき） 所属 輸送機器メーカーの IT 子会社に勤務 これまで 入社以来、メール・ファイル共有など IA サーバ系の IT インフラの設計構築・ サーバ運用を担当 いま CCoE のメンバーとしてアーキテクトを担当 コミュニティ JAWS-UG 磐田 を設立し、コアメンバーの一人として活動中 写真を ここに挿入 （差し替えてください）
3. INTRO 今日のゴールと進め方 このセッションで持ち帰ってほしいこと 1 設計の型を持つ AWSアーキテクチャを「レイヤ」と「依存方向」で整理する考え方 2 IaC を道具にする Terraform でモジュールを組み合わせ、環境を再現可能にする 3 生成AIを“相棒”にする Claude Code で生成 → 検証 → 修正のループを回す勘どころ 4 落とし穴を知る 静的解析では見えず、実 apply で初めて分かる問題があること アジェンダ 1 アーキテクチャー設計の考え方 2 IaC × Terraform の基本 3 なぜ 生成AI × IaC は相性が良いのか 4 Claude Code の「生成 → 検証」ループ 5 実践例：dev で設計 → stg で実環境検証 ★ このあと：もくもくタイム
4. PART 1 アーキテクチャー設計の考え方 「いきなり書く」前に、構造を決める。設計の良し悪しが、IaC の書きやすさを左右する。 レイヤで分ける base / compute / app 変更頻度・ライフサイクルが違うものを別レイヤ（別 state）に。土 台は安定、アプリは高頻度で回す。 依存は一方向に base → compute → app 下位層の出力を上位層が参照する向きに統一。循環依存をなくすと 、適用順も読みやすくなる。 通信は最小権限で Security Group 設計 「誰が誰の何番ポートへ」を SG で明示。ALB→ECS→RDS と段階 的に絞り、出口(egress)も意識する。 秘密情報は持たない Secrets Manager DBパスワードを平文で書かない。Secrets Manager が生成し、 ARN参照でアプリへ注入する。
5. PART 2 IaC × Terraform の基本 IaC とは Infrastructure as Code インフラ（VPC・ECS・RDS…）を 手作業のクリックではなく コードとして記述・管理する 同じ環境を何度でも再現できる 差分・履歴を Git でレビューできる dev / stg / prod を揃えやすい → Terraform は、これを宣言的に書ける代表的なツール（マルチクラウ ド対応） Terraform 設計の3つの土台 モジュール化 vpc / alb / ecs-service / rds … を“部品”にして組み合わせる。出力 (output)を次の部品の入力(input)に配線する。 State（状態） 実リソースとコードの対応を記録するファイル。レイヤごとに分け、S3 backend で共有。 Backend & ロック state を S3 に置き、同時実行を防ぐロックをかける（S3ネイティブロッ ク）。チーム運用の前提。
6. PART 3 なぜ 生成AI × IaC は相性が良いのか 定型が多い リソース定義は“お作法”の塊。HCLの型・引数 ・ベストプラクティスは生成AIが得意な領域 。 検証で守れる 出力をそのまま信じず、fmt / validate / セキ ュリティ静的解析で機械的に検査できる。 反復が速い 「ALB足して」「HTTPS化して」を会話で指 示。設計→コード化のサイクルが一気に縮む 。 Claude Code の役割 自然言語の指示からHCLを生成するだけでなく、リポジトリの文脈を読み、コマンド（fmt / validate / checkov / trivy / plan）を自分で実 行し、結果を見て直すところまで“ループ”を回せる。 重要：それでも最終判断は人間（Human-in-the-loop）。生成AIは“速い相棒”であって、無条件に信頼する対象ではない。
7. PART 4 Claude Code の「生成 → 検証」ループ 指示 自然言語で要件 （例: ALB+ECS+RDS） → 生成 HCL を生成 モジュールを配線 → 整形/検証 fmt / validate 配線・型・必須入力 → 静的解析 checkov / trivy セキュリティ検査 → plan 差分を確認 人間がレビュー → apply 明示承認の上で 実環境へ反映 エラーがあれば「生成」へ自動で戻り、直してから再検証する（ループ） ハルシネーション対策 存在しない引数を“それっぽく”書くことがある。公式モジュール／レジ ストリを使う・必ず validate を通す・plan を読む、で機械的に潰す。 人間のレビューは外さない plan を見て差分を承認するのは人間。apply は“明示的な確認”の後に。 生成AIは判断を肩代わりしない。
8. 実践例 ECS Web + RDS + SPA を、生成AIで設計し実環境で検証した Terraform 部品モジュールを組み合わせ、Claude Code で 2 段構えで進めた。 dev 設計 & 静的検証 9つの部品モジュールを配線（ECS/RDS/SPA） 3レイヤ（base/compute/app）に state 分割 fmt / validate / checkov / trivy は全てグリーン AWS には未接続（コードと静的解析だけ） stg AWS 実環境へ apply dev 構成を実アカウントへ terraform apply 実リソースとして成立するかを検証 静的解析では見えない不具合が5件 顕在化 モジュールを改修し、最終的に稼働 OK →
9. 実践例 アーキテクチャ（ECS Web + RDS + SPA） インターネット CloudFront SPA / OAC・HTTPS S3 (非公開) SPAコンテンツ WAF ALB (public) HTTP→HTTPS / :443 ECS Service Fargate / private オートスケール 2〜6 RDS MySQL Multi-AZ / private Secrets Manager DBパスワード ARN注入 0.0.0.0/0 → :443 :3306 依存は一方向：vpc → SG(alb/ecs/rds) → alb/ecs/rds → ecs-service ／ waf → cloudfront。循環依存なし。
10. 実践例 / dev dev：部品モジュールの組み合わせと静的検証 組み合わせた部品モジュール（9） network/vpc ネットワーク基盤 network/security-group ×3 alb / ecs / rds の通信制御 network/alb ロードバランサ（HTTPS） compute/ecs-cluster ECS クラスター compute/ecs-service Fargate サービス database/rds MySQL（Multi-AZ） security/acm ×2 証明書（ALB / CloudFront） security/waf CloudFront 向け WAF network/cloudfront-s3-site SPA フロント（S3+CF） base / compute / app の3レイヤ・別 state に分割（terraform_remote_state で参照） 静的検証の結果（AWS 非接続） terraform validate 配線・型・必須入力 Success checkov Passed 119 / Skipped 29 Failed 0 trivy (HIGH/CRITICAL) 実マージゲート 0 件 設計と静的検証の段階では“完璧”に見えた。— でも、本当の検証 はこの先だった。
11. 実践例 / stg stg：実 apply で初めて分かった5つの落とし穴 validate / checkov / trivy では検出できなかった ── すべて実環境への apply で初めて顕在化した問題 # 事象（apply で顕在化） 根本原因 対処 1 base の plan が for_each エラー SG 同士の相互参照で値が plan 時に未確定 -target で SG を依存順に段階 apply 2 RDS 作成失敗 db.t3.micro は Performance Insights 非対応 performance_insights_enabled = false 3 ECS タスクが起動失敗（Secrets 不達） egress が全拒否で NAT 経由の外部通信不可 alb/ecs SG に egress 許可を付与 4 nginx が即終了（Read-only FS） ルートFS が読取専用固定で書込先が無い モジュール改修：writable_volumes を追加 5 タスク定義の更新が反映されない ignore_changes=[task_definition] 既定 追従設定（ignore=false）に変更 学び：ecs-service モジュールは writable_volumes / readonly_root_filesystem を追加して改修（テスト 23/23 pass）。最終的に ECS 2/2 running・ALB healthy で稼働確認。
12. まとめ：今日の3つの学び 1 設計 → IaC → 検証 を“型”にする レイヤ分離・一方向依存・最小権限・秘密情報の外出し。型があるから、生成AIにも的確に頼める。 2 生成AIは“速い相棒”、判断は人間 Claude Code で生成→検証ループは一気に速くなる。でも plan を読み apply を承認するのは人間の仕事。 3 “グリーン”はゴールではない validate / checkov / trivy が全部通っても、実 apply で初めて分かる問題がある。実環境で確かめて、モジュールを育てる。
13. このあと もくもくタイムの進め方 やってみよう（作業 & 相談 OK） 1 作りたい構成を1つ決める 例：ALB + ECS、S3+CloudFront の SPA など小さく 2 生成AIに設計から相談する 「この要件のアーキテクチャを提案して」から始める 3 Terraform を生成 → validate fmt / validate を必ず通し、plan を読む 4 詰まったら相談 エラーメッセージごと聞く・周りに声をかける もっと深掘りするなら Terraform Registry（公式モジュール） AWS Well-Architected Framework checkov / trivy（IaC セキュリティ） Claude Code ドキュメント 一緒に手を動かしましょう