Day 7 of #30DaysOfTerraform: Managing Multiple Environments with Terraform Workspaces

#30daysofawsterraform
By Day 7, Terraform usage starts to resemble real production workflows. You now have structured code, reusable modules, variables, and clean repositories. The next problem becomes obvious: how do you manage multiple environments without duplicating everything?
Development, staging, and production environments almost always need similar infrastructure with slightly different values. Day 7 focuses on Terraform workspaces, a feature designed to solve this exact problem by isolating state while reusing the same configuration.
The Environment Problem in Infrastructure as Code
Without a clear strategy, teams often handle environments by copying directories:
dev/
staging/
prod/
Each folder contains nearly identical Terraform code with small changes. This approach works initially, but it introduces serious problems:
Code duplication
Drift between environments
Risky manual edits
Difficult automation
Terraform workspaces offer a cleaner alternative by separating state, not code.
What Terraform Workspaces Actually Are
A Terraform workspace is a separate state associated with the same configuration.
The code stays the same, but Terraform tracks infrastructure independently for each workspace.
Conceptually:
Same Terraform files
Different state files
Isolated infrastructure per environment
You can list workspace using:
terraform workspace list
Create a new one:
terraform workspace new dev
Switch between them:
terraform workspace select prod
Each workspace maintains its own state, which means changes in one environment never affect another.

Terraform Workspaces and Environment Isolation
How Terraform Uses Workspaces Internally
Terraform automatically exposes the active workspace name via:
terraform.workspace
This value becomes incredibly useful when combined with variables, locals, and naming logic.
For example:
locals {
environment = terraform.workspace
}
Now your infrastructure becomes environment-aware without extra configuration.
Using Workspaces for Resource Customization
Once the workspace name is available, it can influence resource behavior.
Example:
resource "aws_s3_bucket" "example" {
bucket = "my-app-${terraform.workspace}-bucket"
tags = {
Environment = terraform.workspace
}
}
With this setup:
devworkspace createsmy-app-dev-bucketprodworkspace createsmy-app-prod-bucket
Same code. Different infrastructure. Clean separation.
Workspaces and Remote State
When combined with a remote backend like S3, workspaces become even more powerful. Terraform automatically namespaces state files by workspace:
s3://terraform-state-bucket/project-name/dev/terraform.tfstate
s3://terraform-state-bucket/project-name/prod/terraform.tfstate
This ensures:
No state collisions
Safe parallel usage
Clean environment isolation
This pattern is commonly used in real-world Terraform deployments, especially when paired with CI/CD pipelines.
When Workspaces Make Sense (and When They Don’t)
Workspaces are excellent for:
Environment separation (dev, staging, prod)
Small-to-medium projects
Teams sharing the same codebase
They are not ideal for:
Completely different architectures per environment
Very large organizations with strict account separation
Scenarios requiring separate Terraform repos
Understanding this trade-off is part of using Terraform responsibly.
The Real Lesson of Day 7
Day 7 isn’t about memorizing workspace commands. It’s about thinking in environments.
Instead of writing different code for different environments, you design infrastructure that:
Adapts based on context
Isolates risk through state separation
Encourages consistency
That mindset is what allows Terraform to scale beyond personal labs into real systems.
Takeaway
Day 7 introduced a critical Terraform capability:
Workspaces separate state, not code
The same configuration can safely manage multiple environments
Combining workspaces with variables and remote state enables production-grade workflows
With workspaces, Terraform moves from “infrastructure provisioning” to environment management — a key milestone in any DevOps journey.




