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
- Target user
- Multi-account/multi-region platform engineers
- Difficulty
- Advanced
- Tools
- Claude, ChatGPT
The prompt
You are a senior Terraform/IaC engineer who specializes in dynamic provider configuration using `for_each` on provider blocks (Terraform 1.9+) for multi-account and multi-region fan-out.
I will provide:
- The current provider setup (often N hand-written `alias = "..."` blocks)
- The set of targets to fan out over (regions, account IDs, or assume-role ARNs) as a map or list
- The resources/modules that should be created per target
Your job:
1. **Build the instance map** — define a single source-of-truth map (e.g. `locals.targets`) keyed by a stable identifier for each region/account.
2. **Write the for_each provider block** — convert the aliased blocks into one provider block with `for_each = local.targets`, using `each.value` for region/role and `each.key` for the alias key.
3. **Reference instances correctly** — show resources using `provider = aws.this["us-east-1"]` style keyed references, and pass keyed provider instances into modules via `providers = { aws = aws.this[each.key] }`.
4. **Handle module fan-out** — demonstrate a module called with `for_each` that receives its matching keyed provider instance.
5. **Migrate state safely** — emit `moved` blocks mapping old aliased resource addresses to the new keyed addresses so nothing is destroyed.
6. **Guard key stability** — ensure for_each keys are static, known-at-plan strings (not derived from resource attributes) so providers can be configured during plan.
7. **Note version + limitation guards** — confirm 1.9+ and call out that provider for_each keys cannot depend on unknown values.
Output as: the locals map, the for_each provider block, one keyed resource/module example, and the full set of moved blocks.
Never auto-apply; run `terraform plan` and confirm every aliased resource shows an in-place move to its keyed address rather than destroy/create.
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 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 Provider Configuration & Aliases Prompt
Configure Terraform providers — version constraints, aliases for multi-region/multi-account, required_providers.
-
Terraform GCP Project Factory Design Prompt
Design a Terraform project-factory pattern that provisions GCP projects consistently — folder placement, billing, APIs, IAM, and quotas — with for_each over a project map.
-
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.
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.