AWSのIaC化で失敗しないコツ｜TerraformとCDKの使い分けからCI/CDまで

AWSをIaC化すると「再現性」「レビュー可能」「変更履歴」の3つを一気に手に入れられます。一方で、初期設計を間違えると逆に運用が重くなるのもIaCの怖さ。本記事では現場で効くコツをまとめます。

ツール選びの基本

• Terraform：マルチクラウド・成熟・人材豊富。インフラ専任チーム向け
• AWS CDK：TypeScript / Python で書ける。アプリ寄りエンジニアと相性◎
• AWS SAM：Lambda + API Gateway 中心ならこれが最短
• CloudFormation（生）：他ツールが入らない制約環境向け

選定で迷うなら「運用するチームが何を書きやすいか」を最優先に。学習コストと採用市場の広さの両面でTerraformが無難です。

ディレクトリ構造のテンプレ

infra/
├── modules/              # 再利用可能なモジュール
│   ├── network/
│   ├── ecs-service/
│   └── rds/
├── envs/
│   ├── dev/
│   │   ├── main.tf
│   │   └── terraform.tfvars
│   ├── stg/
│   └── prd/
└── README.md

環境別にディレクトリを分け、共通部分はモジュールに切り出します。「dev だけ反映する」が安全に行えるのがポイント。

tfstate（状態ファイル）の管理

ローカルにtfstateを置くのは絶対NG。S3＋DynamoDBロックが定番です。

terraform {
  backend "s3" {
    bucket         = "myorg-tfstate-prd"
    key            = "ecs-service/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "terraform-lock"
    encrypt        = true
  }
}

• S3のバージョニング・暗号化を必ず有効化
• DynamoDBロックで同時applyを防ぐ
• tfstateを別アカウント（管理用）に置くと事故が減る

環境差分はvariablesで吸収

環境ごとに module を別物として書くのではなく、変数で切り替えるのが基本。

# envs/prd/terraform.tfvars
env             = "prd"
ecs_min_tasks   = 3
ecs_max_tasks   = 30
rds_instance    = "db.r6g.large"
multi_az        = true

CI/CDで安全に流す

GitHub Actions等で plan を Pull Request にコメント、apply はマージ後に手動承認、が定番フロー。

• Pull Request時：terraform fmt・validate・plan を実行しPRに添付
• マージ後：mainブランチで apply。本番は手動承認ステップを挟む
• OIDC認証でAWSにログイン（長期キーを置かない）

ドリフト（手動変更）対策

「コンソールでちょっと触る」が積み重なると、IaCと実態が乖離します。

• 本番アカウントは原則 ReadOnly。書き込みはIaCのみ
• 定期的に terraform plan をCIで実行し、差分をSlack通知
• 緊急対応で手動変更したら、必ず24時間以内にIaCに反映するルール

「IaCにしないもの」を決める

全てをIaC化する必要はありません。次のものはむしろ管理外で問題ないことが多いです。

• IAMユーザー個別のログイン情報
• RDS / S3に格納されたデータそのもの
• 使い捨ての検証用リソース

まとめ

IaCは「書ける」よりも「運用に組み込める」かが鍵です。最初に小さく始めて、CI/CDとレビュー文化を育てながら適用範囲を広げていきましょう。