Terraform relies on a state file to understand the infrastructure it manages. Instead of constantly querying cloud providers which is slow, expensive, and inefficient Terraform stores the current state of your resources locally or remotely. This file acts as Terraform’s “source of truth,” enabling it to detect changes, manage dependencies, and apply updates safely.
What Is a Terraform State File?
Terraform’s state file records the attributes and relationships of your deployed resources. It allows Terraform to:
- Compare desired configuration vs. actual infrastructure
- Generate accurate execution plans
- Track dependencies between resources
- Enable collaboration across teams
Because Terraform relies heavily on this file, keeping it secure and consistent is critical.
State File Best Practices
To avoid corruption, security risks, or inconsistent deployments:
- Never edit the state file manually
- Use remote storage instead of local files
- Enable state locking
- Back up regularly
- Use separate state files per environment
- Restrict state file access
- Encrypt in transit and at rest
These practices ensure your infrastructure remains predictable and stable.
Why Store State Files Remotely?
Remote backends like AWS S3 provide several advantages:
- Collaboration: Team members share one state source
- Locking: Prevents simultaneous modifications
- Security: IAM, encryption, and access controls
- Versioning: Easy rollback and recovery
- High availability: Durable and reliable storage
Local state works for learning, but teams need the reliability of remote backends.
AWS Remote Backend Overview
A typical Terraform remote backend in AWS includes:
- S3 Bucket - to store state files
- S3 Native State Locking - available in Terraform 1.10+
- IAM Policies - to control read/write access
Previously, DynamoDB tables were required for locking. Now, Terraform can use S3 alone.
S3 Native State Locking (Terraform 1.10+)
Terraform 1.10 introduced S3-native state locking, using AWS S3’s Conditional Writes (If-None-Match). This allows Terraform to manage lock files directly in S3.
How It Works
- Terraform tries to create a lock file in S3.
- If the lock file already exists, S3 rejects the request.
- If not, Terraform acquires the lock.
- When the operation finishes, the lock file is deleted.
This ensures only one Terraform operation can modify the state at a time.
Why Locking Prevents State Corruption
Without locking, two engineers could run terraform apply simultaneously, causing:
- Corrupted state
- Duplicate resources
- Missing infrastructure
- Unpredictable environments
With S3 native locking:
- Only one operation proceeds
- Others are blocked with a “state is locked” message
- State remains consistent and protected
Top comments (0)