Table of Contents
What Is a Terraform Backend?
A backend determines where Terraform stores state and how operations like plan and apply are executed. Choosing the right backend is critical for team collaboration.
Backend Comparison
| Backend | Locking | Encryption | Best For |
|---|---|---|---|
| S3 + DynamoDB | Yes (DynamoDB) | Yes (SSE) | AWS teams |
| GCS | Yes (built-in) | Yes (default) | GCP teams |
| Azure Blob | Yes (lease) | Yes (SSE) | Azure teams |
| Terraform Cloud | Yes (built-in) | Yes | Any cloud, enterprise |
| Consul | Yes (built-in) | No (needs TLS) | HashiCorp stack |
| PostgreSQL | Yes (advisory locks) | No (needs TLS) | Self-hosted |
| Local | No | No | Solo development only |
S3 Backend (AWS)
The most popular backend for AWS teams:
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "services/api/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-state-locks"
encrypt = true
}
}
Setup requirements:
- Create S3 bucket with versioning enabled
- Create DynamoDB table with
LockIDas partition key - IAM permissions for S3 and DynamoDB access
GCS Backend (Google Cloud)
terraform {
backend "gcs" {
bucket = "company-terraform-state"
prefix = "services/api"
}
}
Azure Blob Backend
terraform {
backend "azurerm" {
resource_group_name = "terraform-state-rg"
storage_account_name = "tfstateaccount"
container_name = "tfstate"
key = "services/api/terraform.tfstate"
}
}
Terraform Cloud Backend
terraform {
cloud {
organization = "my-org"
workspaces {
name = "api-prod"
}
}
}
Best Practices
- Always enable state locking — prevents concurrent modifications
- Enable encryption at rest — state contains sensitive data
- Enable versioning — recover from accidental state corruption
- Use separate state files per component — blast radius reduction
- Restrict access with IAM — only CI/CD and authorized users
Learn More
- Terraform for Beginners Course — hands-on backend labs
- Terraform By Example Book — real-world patterns
- Terraform Cheat Sheet — quick command reference



