IaC は『コードレビューできるインフラ』を作る武器
Terraform はマルチクラウド対応の代表的 IaC ツールです。本記事では編集部の視点で、実務で押さえるべき state 管理・モジュール設計・チーム運用を公開情報をもとに整理します。Kubernetes 本番運用 もご参考に。
state 管理の鉄則
(1) リモートバックエンド必須：S3+DynamoDB / GCS / Terraform Cloud。(2) state ロック：複数人の同時 apply 防止。(3) workspace で環境分離：dev/stg/prd を切り分け。(4) state の暗号化：機密値が含まれるため必須。(5) state を Git に入れない：絶対NG。Observability 実践 でドリフト検知も合わせて。
モジュール設計の指針
(1) 1モジュール1責務：vpc / rds / eks 等に分ける。(2) 変数とアウトプットを明示：使い方が一目で分かる設計。(3) バージョン固定：ref=v1.2.0 等で再現性を担保。(4) プライベートレジストリ：社内モジュールを集約。(5) 過度なDRY化を避ける：抽象化しすぎは読みにくい。
plan/apply の運用
(1) plan を PR で見る：Atlantis / Terraform Cloud / GitHub Actions。(2) 本番 apply は手動承認：自動マージ禁止。(3) plan の差分が大きい場合は要警戒。(4) 並列 apply の制限：state ロックで衝突防止。(5) destroy 操作の権限分離：誰でも消せる状態は危険。
シークレット管理
(1) tfvars に機密値を書かない。(2) Vault / SOPS / クラウドの Secret Manager を経由。(3) 環境変数で渡す場合は CI ログ非表示に。(4) state 内の機密：sensitive=true で表示抑制。(5) 監査ログ：誰が何を変更したか追跡可能に。
CI/CD への組み込み
(1) fmt / validate / tflint：PR 必須チェック。(2) plan 自動化：PR コメントに差分を投稿。(3) policy as code：Sentinel / OPA で禁止リソースを検出。(4) state ドリフト検知：定期 plan で乖離を警告。(5) 環境別の credential 分離：本番権限を最小化。
失敗しがちなパターン
(1) state を破損：手動で消した・複数人で同時編集。(2) 巨大な state：分割せず長時間 plan/apply。(3) モジュールのバージョン未固定：意図せず破壊変更が走る。(4) destroy 事故：terraform destroy 連発。(5) 本番反映を手動 console と並行：state とのドリフト。対策は、(1)バックエンド+ロック、(2)state分割、(3)バージョン固定、(4)権限分離、(5)IaC 一本化、です。