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.
Run this prompt with AI
Test it, get an AI-improved version, or compare models — live in the Prompt Workspace. No copy-paste.
Related prompts
-
Terraform for_each Set vs Map Keys Prompt
Decide whether a `for_each` should iterate a set of strings or a map of objects so instance keys stay stable, readable, and free of churn when the collection changes.
-
Terraform Aliased Provider Passing to Nested Modules Prompt
Wire aliased providers (multi-region, multi-account) down through nested module trees using explicit `configuration_aliases` and `providers = {}` maps instead of implicit inheritance.
-
Terraform Module Passed Provider Configuration Prompt
Correctly pass aliased provider configurations into a child module via configuration_aliases so multi-region or multi-account modules work without hidden provider inheritance.
-
Dynamic Multi-Instance Provider Configuration with for_each Prompt
Use for_each on provider configurations (Terraform 1.9+) to fan resources out across many accounts or regions without hand-written aliases
More Terraform prompts & error guides
Browse every Terraform prompt and troubleshooting guide in one place.
Reading prompts? Get all 500 in one free PDF
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.