I'm starting to manage infrastructure across multiple environments (dev, staging, prod) and AWS accounts. My current Terraform setup feels messy, and I'm trying to decide on a clearer pattern before scaling further.
I see three main approaches: using Terragrunt to keep DRY configurations, using native Terraform workspaces with a single state per environment, or just maintaining completely separate Terraform projects per env/account. For those who have migrated between these styles, what was the biggest pain point? Did moving to Terragrunt's layered config simplify things enough to justify adding another tool?
Still learning.
I'm a data engineer at a mid-size retail company, and we manage about 20 AWS services and 5 Snowflake databases with Terraform across three environments in separate accounts.
1. **DRY Code vs. Complexity:** Terragrunt's greatest strength is forcing you into a DRY structure, so you define a module once and call it with different inputs per environment. The specific cost is that you add another layer of HCL and dependency management. In my previous setup, debugging meant tracing issues through both Terragrunt and Terraform layers, which could add 15-30 minutes to troubleshooting a misconfigured variable.
2. **State Isolation Safety:** Separate projects per environment is the safest and simplest pattern. Each directory has its own state file and backend config. The trade-off is clear: you get absolute isolation to prevent accidental prod changes, but you pay with copy-pasted code. For us, that meant updating the same variable in four different `terraform.tfvars` files.
3. **Workspace Pitfall - Shared Backend:** Native workspaces use a single backend configuration but separate state files within it. The concrete danger is that all your environments, including prod, depend on one S3 bucket and DynamoDB lock table. If that backend has an outage, you can't change any environment. We also saw team members forget to switch workspaces, nearly applying dev changes to prod.
4. **Learning Curve and Team Onboarding:** Separate projects have almost no learning curve. Terragrunt requires the team to learn its specific commands and `terragrunt.hcl` syntax. When we adopted it, we spent about two weeks of collective team time getting everyone comfortable and rewriting our CI/CD pipelines to use `terragrunt run-all` commands.
My pick is to start with separate Terraform projects per environment. It's the easiest to reason about and audit. I'd only move to Terragrunt if you have over 10 similar environments or are managing more than 30 distinct modules, as that's where the copy-paste overhead becomes a real drag. To make a clean call, tell us the size of your team and how many AWS accounts you'll have in a year.
null