Terraform as a team: remote state, locking and reviewable changes
Designing an S3 backend, separating environments and keeping concurrent operations from competing for the same state.
A terraform apply that works on a laptop is a good start. Teamwork raises other questions: where does state live, who can change it, and how do we prevent simultaneous operations? The backend belongs in the delivery architecture rather than being an afterthought.
State needs its own design
The S3 backend documentation supports native lock files through use_lockfile. DynamoDB-based locking is marked as deprecated in that documentation. Check the Terraform version and your team’s requirements before copying an older tutorial.
This configuration is illustrative. The bucket must already exist and the names need to match your environment:
terraform {
backend "s3" {
bucket = "example-terraform-state"
key = "development/network/terraform.tfstate"
region = "us-east-1"
encrypt = true
use_lockfile = true
}
}The backend does not create the bucket or enable versioning. Those decisions belong to the initial setup. Access permissions must cover both the state and its lock file.
Separate environments, separate blast radius
The landing-zone lab proposes separate accounts, roles and state files. This allows a development change to be reviewed without implicitly granting production access. Repository structure depends on the team; the important thing is being able to explain which environment each plan affects.
A useful concurrency test
In a disposable environment, start an operation that holds the lock and attempt a second operation against the same state. Then check recovery when the first operation finishes. This documents behavior; having the option in a file is not enough.
Keep a reviewable plan and check that a second plan after apply, without external changes, proposes no unexpected modifications. Avoid disabling locking as an automatic response to an error.
What to document
State location, the authorized role, recovery steps and the person responsible for approving changes. State files can contain sensitive information and need explicit access and retention controls.
References
Un terraform apply que funciona desde un portátil es un buen comienzo. Para trabajar en equipo hace falta responder otras preguntas: ¿dónde vive el estado?, ¿quién puede cambiarlo?, ¿cómo se evita una ejecución simultánea? El backend es parte de la arquitectura de entrega, no un detalle que se resuelve al final.
El estado merece su propio diseño
La documentación del backend S3 contempla archivos de bloqueo nativos mediante use_lockfile. El bloqueo con DynamoDB aparece marcado como obsoleto en esa documentación. Conviene comprobar la versión de Terraform y los requisitos del equipo antes de copiar la configuración de un tutorial antiguo.
El siguiente fragmento es ilustrativo. El bucket debe existir y los nombres deben adaptarse al entorno:
terraform {
backend "s3" {
bucket = "example-terraform-state"
key = "development/network/terraform.tfstate"
region = "us-east-1"
encrypt = true
use_lockfile = true
}
}El backend no crea por sí solo el bucket ni activa su versionado. Esas decisiones pertenecen al aprovisionamiento inicial. También hay que conceder los permisos necesarios sobre el estado y su archivo de bloqueo.
Separar entornos es separar el alcance del error
En el laboratorio de landing zone propongo cuentas, roles y estados separados. Esa separación permite revisar una modificación de desarrollo sin darle acceso implícito a producción. La estructura exacta de repositorios depende del equipo; lo importante es poder explicar qué entorno afecta cada plan.
Una prueba útil de concurrencia
En un entorno desechable, iniciaría una operación que mantenga el bloqueo e intentaría una segunda ejecución sobre el mismo estado. Después comprobaría la recuperación al terminar la primera. La prueba documenta un comportamiento; no basta con que la opción aparezca en un archivo.
También guardaría un plan revisable y comprobaría que un segundo plan, después del apply y sin cambios externos, no proponga modificaciones inesperadas. Evitaría desactivar el bloqueo como respuesta automática a un error.
Qué dejaría documentado
Ubicación del estado, rol autorizado, procedimiento de recuperación y responsable de aprobar cambios. Los archivos de estado pueden contener información sensible y merecen controles de acceso y retención explícitos.