Skip to content

feat(terraform)!: S3 native state locking (requires TF >= 1.11)#92

Open
gpazevedo wants to merge 1 commit intoawslabs:mainfrom
gpazevedo:feature/tf-s3-native-lock
Open

feat(terraform)!: S3 native state locking (requires TF >= 1.11)#92
gpazevedo wants to merge 1 commit intoawslabs:mainfrom
gpazevedo:feature/tf-s3-native-lock

Conversation

@gpazevedo
Copy link
Copy Markdown

Summary

  • Replaces DynamoDB-based state locking with Terraform 1.11's native S3 locking (use_lockfile), removing one AWS resource from the state-backend prerequisites.
  • Adds S3 bucket versioning and public-access-block to the documented state-bucket prerequisites, and a rollback procedure that leverages versioning instead of terraform state surgery.
  • Bumps required_version to >= 1.11.0 across root and all module versions.tf.

Breaking change & SemVer

This raises the minimum Terraform version from 1.5.0 to 1.11.0, so it targets a 0.5.0 release per SemVer. Precedent in CHANGELOG.md:

  • 0.2.0 — Python minimum bumped 3.8 → 3.11
  • 0.3.1 — frontend framework migration (Next.js → Vite)

CHANGELOG entries added under [Unreleased]:

  • Added — S3 state bucket versioning + documented rollback procedure
  • Changed — state backend switched to use_lockfile; Terraform >= 1.11 required
  • Security — public-access-block recommended on state bucket prerequisites

Migration

Existing deployments on the DynamoDB-based backend follow a two-phase rollout documented in infra-terraform/README.md (section: Migrating from DynamoDB-only locking):

  1. Dual-lock phase — keep dynamodb_table alongside use_lockfile = true until every operator has pulled the new config and is on Terraform >= 1.11.
  2. Cutover — drop dynamodb_table, terraform init -reconfigure, then aws dynamodb delete-table.

Bucket versioning is not retroactive; enable it on the state bucket before relying on the rollback procedure.

Test plan

  • terraform init -migrate-state on a fresh bucket with use_lockfile = true succeeds.
  • terraform init -reconfigure with dual-lock config (both dynamodb_table and use_lockfile) succeeds on an existing DynamoDB-backed state.
  • Cutover to S3-only backend after dual-lock, then aws dynamodb delete-table succeeds.
  • Rollback procedure (copy-object with prior versionId, then terraform plan) restores a prior state without terraform state surgery.
  • Fresh deploy with Terraform 1.11.x completes end-to-end.

🤖 Generated with Claude Code

Replace DynamoDB-based state locking with Terraform 1.11's native S3
locking (use_lockfile). Simplifies prerequisites (one fewer AWS
resource) and enables a documented state rollback procedure via S3
bucket versioning -- a capability the project previously lacked.

Changes:
- Bump required_version to >= 1.11.0 (needed for stable use_lockfile)
- Ship backend.tf.example with S3-only locking; prereqs add versioning
  and public-access-block on the state bucket
- Add "Rolling back state" and "Migrating from DynamoDB-only locking"
  subsections to infra-terraform/README.md (two-phase dual-lock rollout)
- Update docs/TERRAFORM_DEPLOYMENT.md Terraform prerequisite version

SemVer: this is a breaking change for users pinned to Terraform < 1.11,
so it targets a 0.5.0 release. Precedent: CHANGELOG 0.2.0 (Python
3.8 -> 3.11 min) and 0.3.1 (Next.js -> Vite migration).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
@gpazevedo gpazevedo requested a review from a team April 19, 2026 16:07
@github-actions github-actions Bot added documentation Improvements or additions to documentation infrastructure labels Apr 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation infrastructure

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants