Claude Codeで構築するAWSインフラストラクチャ - Terraformコード検証から修正まで
はじめに
AWS上でスケーラブルなSaaSアプリケーションを構築する際、Terraformを使ったインフラ管理は一つの手段です。構築や運用をする際に、Terraformの構文エラーや設定の不整合は、デプロイ時に問題を引き起こします。
今回は、Claude Codeを使ってTerraformファイルからなるAWSのインフラプロジェクトを構築し、検証・修正した過程をご紹介します。
下記にサンプルコードを置いています。
構築したアーキテクチャ
今回構築したのは、以下のサービスを利用したを一般的な構成です。
- VPC: マルチAZ構成のパブリック・プライベートサブネット
- Security Groups: ALB、ECS、RDS用のネットワークセキュリティ
- ALB: アプリケーションロードバランサー
- ECS on Fargate: コンテナのアプリケーションをホスティング
- RDS MySQL: 自動バックアップ・Multi-AZ対応データベース
- S3: アセット・ログ用オブジェクトストレージ
- WAF: Webアプリケーションファイアウォール
- CodePipeline: CI/CDパイプライン
※このAWS構成図もClaude Codeに書いてもらいました。
プロジェクト構造の整理
Claude Codeを使って、標準的なTerraformプロジェクト構造に整理しました：
terraform/
├── modules/ # 再利用可能なモジュール
│ ├── vpc/
│ ├── security_groups/
│ ├── alb/
│ ├── ecs/
│ ├── rds/
│ ├── s3/
│ ├── waf/
│ ├── ecr/
│ └── codepipeline/
├── bootstrap/ # Terraform状態管理用
└── environments/ # 環境別設定
├── dev/
├── stg/
└── prod/
Terraform検証プロセス
一度Claude Codeで構築したプロジェクトを検証エージェントを使用して、全ファイルの構文チェックを実施しました。
検証対象ファイル
- bootstrap: 3ファイル（状態管理用S3・DynamoDB）
- environment: 12ファイル（dev/stg/prod × 4ファイル）
- modules: 24ファイル（9モジュール × 3ファイル）
発見した問題
検証の結果、以下の問題が見つかりました。
修正作業の詳細
1. S3バケット暗号化リソース名の修正
問題: AWS Provider v5.0で廃止されたリソース名を使用
# 修正前（無効）
resource "aws_s3_bucket_encryption" "terraform_state" {
bucket = aws_s3_bucket.terraform_state.id
server_side_encryption_configuration {
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
}
# 修正後（有効）
resource "aws_s3_bucket_server_side_encryption_configuration" "terraform_state" {
bucket = aws_s3_bucket.terraform_state.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}
影響ファイル:
terraform/bootstrap/main.tfterraform/modules/s3/main.tfterraform/modules/codepipeline/main.tf
2. ALBリスナーアクション設定の修正
問題: 古いALBリスナー構文を使用（AWS Provider v4.0以降で変更）
# 修正前（無効）
resource "aws_lb_listener" "app" {
load_balancer_arn = aws_lb.main.arn
port = "80"
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.app.arn
}
}
# 修正後（有効）
resource "aws_lb_listener" "app" {
load_balancer_arn = aws_lb.main.arn
port = "80"
protocol = "HTTP"
default_action {
type = "forward"
forward {
target_group {
arn = aws_lb_target_group.app.arn
}
}
}
}
影響範囲: terraform/modules/alb/main.tf:42-66
3. S3ライフサイクルルールの修正
問題: 必須のfilter属性が不足
# 修正前（警告）
resource "aws_s3_bucket_lifecycle_configuration" "app_assets" {
bucket = aws_s3_bucket.app_assets.id
rule {
id = "assets_lifecycle"
status = "Enabled"
noncurrent_version_expiration {
noncurrent_days = 30
}
}
}
# 修正後（有効）
resource "aws_s3_bucket_lifecycle_configuration" "app_assets" {
bucket = aws_s3_bucket.app_assets.id
rule {
id = "assets_lifecycle"
status = "Enabled"
filter {
prefix = ""
}
noncurrent_version_expiration {
noncurrent_days = 30
}
}
}
4. 環境変数の統一
問題: dev環境でWAF用変数が不足
dev環境のvariables.tfに追加：
variable "ip_whitelist_enabled" {
description = "Enable IP whitelist for WAF"
type = bool
default = false
}
variable "whitelist_ips" {
description = "List of IP addresses to whitelist"
type = list(string)
default = []
}
Claude Code活用のメリット
1. 包括的な検証
- ファイル全体の同時チェック
- 構文エラー、設定の不整合、依存関係の問題を一括検出
- AWS Provider バージョン対応状況の確認
2. 効率的な修正作業
- 問題箇所の特定と修正提案
- 複数ファイルの一括編集（MultiEdit機能）
- 修正後の整合性確認
3. 標準化の推進
- 業界標準のディレクトリ構造への移行
- 環境間の設定統一
- ベストプラクティスの適用
まとめ
Claude Codeを活用することで、Terraformプロジェクトを効率的に検証・修正できました。特に、AWS Providerのバージョンアップに伴う非互換性や、環境間の設定不整合などの問題を事前に発見・解決できたことは大きな価値があります。
Infrastructure as Code(IaC)の品質向上において、このような包括的な検証プロセスは不可欠です。Claude Codeのような高度なAIツールを活用することで、より安全で保守性の高いインフラストラクチャを構築できるかもしれません。
また、Claude Codeで基本的なリソースのみ作成しているため改善をしていきたいと考えています。
Cursorなども併用して、プロジェクトの作成をするのも検討したいと思います。
Discussion