State Isolation, Remote Locking & Blast Radius Control

In this module, you'll learn to:

• Set up an S3 state backend with native locking, encryption, and least-privilege access
• Give every layer its own state, so a mistake in one can't reach the others
• Share values between layers through SSM Parameter Store instead of terraform_remote_state

Before you start: read Enterprise Repository & Module Layout. This module gives each of its layers a state of its own.

State is both your source of truth and a risk

The state file is how Terraform knows which real cloud resources belong to your code. Handled carelessly, it creates two big risks:

1. Two runs at once: two CI jobs or engineers applying at the same time can overwrite each other's state, leaving orphaned resources or drift.
2. Too much in one place: with all infrastructure in one state file, a mistake anywhere can affect everything.

A secure S3 backend with native locking

The state bucket needs several layers of protection. Terraform 1.10 added native locking to the S3 backend, using S3 conditional writes (use_lockfile), and it became generally available in Terraform 1.11. A separate DynamoDB lock table is no longer needed:

# backend.tf (Terraform 1.11+)
terraform {
  backend "s3" {
    bucket       = "corp-terraform-state-us-east-1-prod"
    key          = "networking/vpc/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    kms_key_id   = "alias/corp-terraform-state"
    use_lockfile = true # native S3 locking
  }
}

Older runners · DynamoDB locking

DynamoDB locking (dynamodb_table) is deprecated from Terraform 1.11, but runners still on older versions need it. To migrate, set both use_lockfile = true and dynamodb_table for a while: Terraform then takes both locks, so old and new runners can't overlap. Once every runner is on 1.11 or later, remove dynamodb_table and decommission the table. A backend change like this affects every run, so record it as an ADR (Module 10).

State hygiene

Never commit state or the local provider cache. Do commit the provider lock file, .terraform.lock.hcl, in each root module, so every machine resolves the same provider versions (Module 08):

# .gitignore at the terraform/ root
**/.terraform/*
*.tfstate
*.tfstate.*
crash.log
override.tf
override.tf.json
*_override.tf
*_override.tf.json
# .terraform.lock.hcl is NOT ignored: commit it

Layering state to control blast radius

Never put all infrastructure in one state file. Give each layer from Module 01 (00-bootstrap, 01-networking, 02-security, 03-data, 04-compute) its own directory and its own key in the state bucket.

Then a mistake in 04-compute only locks and changes the compute state. The networking and database state files aren't part of that run at all.

Avoiding the terraform_remote_state trap

Teams often share values between state files with data "terraform_remote_state":

# ANTI-PATTERN: Tight state coupling
data "terraform_remote_state" "vpc" {
  backend = "s3"
  config = {
    bucket = "corp-terraform-state-prod"
    key    = "networking/vpc/terraform.tfstate"
    region = "us-east-1"
  }
}

resource "aws_security_group" "app" {
  vpc_id = data.terraform_remote_state.vpc.outputs.vpc_id # Tightly coupled!
}

The alternative: SSM Parameter Store

Publish the values other layers need to AWS Systems Manager (SSM) Parameter Store, and read them with a data source:

# 1. In 01-networking: Publish the value
resource "aws_ssm_parameter" "vpc_id" {
  name  = "/infrastructure/prod/vpc/vpc_id"
  type  = "String"
  value = module.vpc.vpc_id
}

# 2. In 04-compute: Read it
data "aws_ssm_parameter" "vpc_id" {
  name = "/infrastructure/prod/vpc/vpc_id"
}

resource "aws_security_group" "app" {
  vpc_id = data.aws_ssm_parameter.vpc_id.value
}

Now each layer reads only the values it needs, IAM can grant access per parameter, and the parameter names form a clear, written contract between layers.

Key terms

• State file: Terraform's record of which real resources belong to the code. It can hold secrets, so it's protected like one.
• use_lockfile: native S3 state locking, generally available from Terraform 1.11. It replaces the DynamoDB lock table.
• Blast radius: how much one run can change. One state per layer keeps it to that layer.
• terraform_remote_state: reads another state's outputs, but needs read access to that whole state file.
• SSM parameter contract: values one layer publishes by name and another reads, with IAM access per parameter.
• .terraform.lock.hcl: committed to Git. .terraform/ and *.tfstate never are.

Pop quiz

Five questions: three on the ideas in this module, and two scenarios where you apply them. The order changes every time you take it, and 4 out of 5 passes.