terraform destroyでdevのリソースが被弾した話

Transcript

1. 2026/08/06 terraform destroy で dev のリソースが被弾した話 うな(内山 優布奈)
2. 1. プロフィール うな (内山 優布奈) 社会人 2 年目 ／ • 農学部出身 • 趣味：ライブ AWS 歴 9 ヶ月
3. 2. インシデント全体像 destroy 前 destroy 後 STG STG CloudFront RDS EC2 RDS EC2 RDS EC2 DEV DEV CloudFront CloudFront RDS EC2 CloudFront
4. 3. 原因① state ファイルの共有 Terraform は state でリソースを管理する terraform.tfstate（単一ファイル） stg apply → state に書き込み Dev CloudFront Dev RDS Dev EC2 ここが問題 dev apply → 同じ state 書き込み var-file で 絞れると思った STG RDS STG ... destroy は state の中身を全部対象にする
5. 4. 原因① var-file ≠ state の分離 -var-file は「state の参照先」を変えない terraform.tfstate 今何が管理されているか -var-file コードをどう評価するか terraform.tfvars environment = "stg" コードの評価値を変える （変数の値だけ） 独立!! Dev CloudFront Dev RDS Dev EC2 STG RDS STG ... destroy の対象 = state 全体 state を分離しなければ、環境は分離されない
6. 5. 原因② count パターンの罠 environment = "stg" で実行すると ... cloudfront.tf count = "stg" == "dev" = false ? 1 : 0 = 0 ? 1 : 0 count による環境切り替えパターン count = 1 リソースが存在する count = 0 リソースが存在すべきでない = 削除 count で環境を切り替えるのは危険
7. 6. なぜ CloudFront だけ消えたか var.environment = "stg" で destroy したとき リソース count 条件 count 値 結果 Dev CloudFront env == "dev" ? 1 : 0 0 消えた STG CloudFront env == "stg" ? 1 : 0 1 意図通り削除 RDS なし（常に存在） — 生き残り EC2 なし（常に存在） — 生き残り count = 0 は Terraform にとって 「このリソースは存在すべきでない」を意味する
8. 7. 再発防止策 未実施 環境を分離するには state を分離する ① ディレクトリ分離（最推奨） ② Remote State （S3 + DynamoDB） ③ Terraform Workspaces 本番運用・チーム開発向け 既存構成への暫定対処 どの方法でも「state の分離」が本質。 var-file の切り替えでは不十分
9. 8. まとめ 1 -var-file は環境を分離しない 2 count による環境切り替えは危険 3 AI のアドバイスは state 管理まで考慮しない Terraform は state で動く state を分離しなければ、環境も分離されない
10. ご清聴ありがとうございました