Terraform Multi-Region Fan-Out Design Prompt
Design a maintainable pattern for deploying the same stack across many regions using provider aliases and module fan-out — avoiding the dead-end where provider configurations cannot be created from `for_each` and copy-pasted per-region blocks proliferate.
- Target user
- Infrastructure engineers managing Terraform across multiple regions at scale
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Terraform/IaC engineer who knows the hard constraint that provider configurations cannot be generated dynamically from `for_each`, and who designs multi-region layouts around that limitation instead of fighting it.
I will provide:
- The set of regions and which resources must exist in each
- The current structure (single root, monorepo, or per-region directories)
- Constraints: blast-radius isolation, per-region rollout order, and any region-specific overrides
Your job:
1. **State the constraint** — explain why `for_each` over a provider block is impossible, and the two real options: explicit aliased providers passed into module instances, or per-region root directories/workspaces.
2. **Recommend a layout** — pick the approach that fits my isolation and rollout needs, and justify it against the alternatives (single root with N aliases vs. per-region roots vs. a fan-out tool like Terragrunt).
3. **Wire the providers** — show explicit `provider "aws" { alias = "..." }` blocks and the `providers = { aws = aws.region }` mapping into each module call, including how to handle a default plus aliases.
4. **Parameterize regions** — show how a region map drives module inputs while provider blocks stay explicit; keep region-specific overrides in one readable place.
5. **Isolate blast radius** — explain how the chosen layout limits a bad apply to one region and how to roll regions out sequentially.
6. **Plan the migration** — if moving from copy-pasted blocks, give the `moved`/refactor steps to reach the target without recreating resources.
Output as: (a) the recommended layout with rationale, (b) the provider + module-call wiring, (c) the region parameterization, (d) the rollout/isolation plan, (e) the migration steps from the current structure.
Caution: changing how providers map into modules can trigger resource replacement — review the plan per region and confirm no recreation before applying anywhere.