Skip to main content

Command Palette

Search for a command to run...

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

Updated
3 min read
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:

  • dev workspace creates my-app-dev-bucket

  • prod workspace creates my-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:

  1. Workspaces separate state, not code

  2. The same configuration can safely manage multiple environments

  3. 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.