Terraform Local State: ローカル運用と注意点（Associate向け）

Terraformは、実リソースのメタデータと依存関係をtfstateに保持します。バックエンドを指定しない場合はローカルステート（terraform.tfstate）が既定で使われます。

ローカル運用は素早い検証に向きますが、チーム利用や機密性・可用性の要件には注意が必要です。Associate試験では、ローカルの性質・限界・安全な移行策を理解していることが問われます。

ローカルステートの基礎

バックエンドを明示しない場合、Terraformは作業ディレクトリにterraform.tfstate（JSON）を作成し、そこに管理対象リソースのID・属性・依存関係を保存します。これは実態と計画の差分計算や、参照（dataソース、出力値）に必須です。

ローカルバックエンドは状態ロックを提供しません。つまり、同じステートを複数のプロセスが同時に更新しても保護されません。チームや自動化での並行実行には不向きです。

tfstateにはシークレット相当の値が含まれることがあります。ローカルでは暗号化されず、OSのファイル権限やディスク暗号化に依存します。誤ってVCSにコミットしないよう.gitignoreが必須です。

• 既定の保存先: ./terraform.tfstate（作業ディレクトリ）
• ロック: なし（競合保護なし）
• 暗号化: なし（OS/ディスク暗号化に依存）
• 用途: 個人開発、PoC、短命環境の試行
• 注意: VCSにコミットしない、権限の最小化

ローカルステートの流れ

最小構成（バックエンド未指定＝ローカル）と基本コマンド

# main.tf（例）
resource "null_resource" "example" {}

# 初期化と差分
terraform init
terraform plan
terraform apply

# ステートの確認
terraform state list
terraform state show null_resource.example

運用パターン：単一開発者／小規模での使いどころ

ローカルステートは、個人の検証、短命なサンドボックス、CIのエフェメラル実行（毎回クリーンに作って破棄）に向きます。ステートを共有しない前提なら、構成が簡単でスピード重視の運用が可能です。

一方で、チームで同じ環境（同じステート）を操作する場合は、ロック・監査・バックアップの面で制約が大きく、リモートバックエンド（S3+DynamoDB、Terraform Cloud/Enterpriseなど）が実務では標準的です。

• PoCや学習用途：セットアップが速い
• 短命環境：実行後に破棄する前提なら管理コストが低い
• チーム運用：共有や並行実行が必要ならローカルは避ける

VCSへの誤コミット防止（推奨 .gitignore）

# .gitignore
terraform.tfstate
terraform.tfstate.backup
.crash.log
.terraform/
*.tfplan
# ステートに派生する一時ファイルも除外

ローカル運用のリスクと失敗パターン

最も大きなリスクは並行実行です。ローカルバックエンドはロックを持たないため、同じtfstateを2つのterraform applyが同時に更新すると、上書きや不整合が発生し得ます。これはリソースの重複作成や削除ミスの原因になります。

また、tfstateは平文JSONであり、秘匿情報が含まれる可能性があります。アクセス権限（例: chmod 600）とディスク暗号化の適用、バックアップファイルの管理が必須です。さらに、誤ってVCSにコミットすると、取り返しがつきません。

リファクタリング時にアドレスを変える場合（モジュール化、for_eachの導入など）は、tfstateの直接編集ではなく、terraform state mv / rm / import といったコマンドで整合性を取るのが安全です。

• 並行実行による競合（ロックなし）
• 機密情報の漏えい（平文JSON）
• VCSへの誤コミット
• 手動編集による破損（JSON破損・アドレス不一致）
• バックアップ不備による復旧不能

最低限のファイル保護と安全なリファクタリング

# ファイル権限の強化（Unix系）
chmod 600 terraform.tfstate terraform.tfstate.backup || true

# リソースアドレス変更時の安全な移動
terraform state mv aws_instance.web module.app.aws_instance.web

# 不要エントリの削除（実体リソースは消さない）
terraform state rm aws_security_group.legacy

# 既存リソースの取り込み
terraform import aws_s3_bucket.logs my-logs-bucket

バックアップと復旧（ローカル）

適用前後にステートのバックアップを取得しておくと、破損時の復旧が容易です。cpでのコピーに加えて、terraform state pullで現在のステートを安全に取得できます。

復旧時はterraform state pushでバックアップを反映できます。直接JSONを編集するより、stateコマンド群で最小変更に留めるのが安全です。バージョン差異や競合を避けるため、復旧は単一プロセス・単一端末で実施してください。

• pullでバックアップ、pushで復旧
• 適用前に計画ファイル（-out）を残すと変更追跡が容易
• バックアップは暗号化ストレージに保管

バックアップと復旧の実例

# バックアップの取得（ローカル/リモート双方で有効）
terraform state pull > backup-$(date +%Y%m%d%H%M%S).tfstate

# ローカルバックエンドへの復旧
terraform state push backup-20240101090000.tfstate

# ファイルコピーによる簡易バックアップ
cp terraform.tfstate terraform.tfstate.backup

# 計画ファイルの保存
terraform plan -out=tfplan
# 内容確認
terraform show -json tfplan > tfplan.json

ローカルからリモートバックエンドへの移行

チーム運用や本番向けには、ロック・共有・監査が揃うリモートバックエンドへ移行します。S3＋DynamoDBではオブジェクトバージョニングとテーブルロック、Terraform Cloudでは組み込みのロックと履歴が利用できます。

移行はbackendブロックを追加し、terraform init -migrate-stateを実行します。適切な権限（S3/DynamoDBのIAM、Terraform Cloudのトークン）を準備し、移行後にterraform state listで整合性を確認します。

• backend設定を追加 → initでマイグレーション
• S3はバージョニング、DynamoDBはロック用テーブルを用意
• ワークスペース単位でステートは分離される点に注意

S3+DynamoDBへの移行例

# backend設定（versions等は省略）
terraform {
  backend "s3" {
    bucket         = "my-tfstate-bucket"
    key            = "envs/prod/terraform.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "my-tf-locks"
    encrypt        = true
  }
}

# 事前準備（例）
# - S3: バージョニング有効、暗号化
# - DynamoDB: パーティションキー=LockID のテーブル
# - IAM: S3/DynamoDBへの適切な権限

# マイグレーション
terraform init -migrate-state

# 検証
terraform state list
terraform plan

Associate試験の観点：要点整理

試験では、ステートの目的、ローカルの既定挙動、ロックの有無、機密情報の扱い、バックアップと復旧、そしてリモートバックエンドの利点と移行手順が問われやすいです。CLIコマンドの正確な使い分けも確認しましょう。

• バックエンド未指定＝ローカル、ロックなし
• tfstateは機密データを含み得る、暗号化はバックエンド依存
• VCSにtfstateを入れない、.terraform.lock.hclは別用途
• 安全な変更: terraform state mv/rm/import、直接編集は最後の手段
• バックアップ: terraform state pull、復旧: state push（ローカル）
• チーム用途はリモート（S3+DynamoDBやTerraform Cloud）＋ロック

頻出コマンドの再確認

# ステート操作
terraform state list
terraform state show <address>
terraform state mv <from> <to>
terraform state rm <address>
terraform state pull > backup.tfstate

# 計画と適用
terraform plan -out=planfile
terraform apply planfile

問題で確認

よくある質問