In Terraform, why can't you choose a provider alias from a variable — for example provider = aws[var.region] — and how do you deploy the same module across a list of regions instead?

## The layering reason Almost everything in HCL is an expression, which is why the restriction feels arbitrary until you see where provider configurations live. Terraform must resolve, for every resource in the configuration, **which provider configuration manages it** — before it can construct the dependency graph and before it can compare the configuration against state, where that association is recorded. That resolution is structural, not evaluated. Consequently: - `provider = aws.eu` is a **reference to a configuration**, in the same family as a resource address, not a string and not an expression. - `provider = aws[var.region]`, `provider = "aws.${var.env}"` and `provider = local.chosen` are all invalid. - There is no `for_each` on a `provider` block, so you cannot manufacture one configuration per element of a collection. The part people miss is that this restriction applies to *selecting* a configuration, not to *configuring* one. A provider block's arguments are ordinary expressions: ```hcl provider "aws" { region = var.region # perfectly legal } ``` That single fact is the escape hatch, and it points straight at the second pattern below. ## Pattern 1 — repeat the module block When a handful of regions must be created and changed together, write them out: ```hcl provider "aws" { alias = "us", region = "us-east-1" } provider "aws" { alias = "eu", region = "eu-west-1" } module "edge_us" { source = "./modules/edge" providers = { aws = aws.us } } module "edge_eu" { source = "./modules/edge" providers = { aws = aws.eu } } ``` It is repetitive, and that repetition is the honest cost of a static provider layer. In exchange, the plan shows both regions at once, cross-region references work naturally, and review is trivial because every region is visible in the file. It does not scale: at fifteen regions this is fifteen near-identical blocks and one enormous state file where a single failing API call blocks every region's apply. Note this pattern *requires* the module to be provider-clean. If `./modules/edge` contained its own `provider` block you could not even use `for_each` on it, and you would be forced into copies anyway. ## Pattern 2 — one root module, run per region The scaling answer inverts the problem. Make the root module single-region, with one default provider configured from a variable, and let the *runner* supply the region: ```hcl provider "aws" { region = var.region } ``` Each region then gets its own state — separate backend keys, separate directories, or a workspace per region — and the pipeline iterates: a matrix job per region, or a small wrapper that applies each in turn. What you gain is substantial: independent state and locks, a blast radius of one region, the ability to roll a change out region by region and stop when the third one fails, and no giant plan. What you lose is the single-plan view and easy cross-region references, which now have to go through published outputs or data sources. ## Pattern 3 — generate the configuration Some teams template the root modules from a list of regions with a small script, Terragrunt, or a CI step, so the repetition exists on disk but not in the source of truth. This is legitimate at scale, but it adds a build step in front of `terraform plan`, and reviewers now diff generated code. Reach for it when the count of near-identical roots genuinely becomes unmanageable, not as a default. ## Choosing Ask whether the regions are one system or many copies of a system. An active-active pair with a replication link between them is one system: keep them in one root module with two aliases and accept the repetition. Twelve edge regions running the same stack independently are copies: one parameterised root module, applied twelve times, with twelve states. The static provider layer pushes you toward the second answer as the estate grows, and that pressure is generally healthy — it is the same pressure that keeps state files small. ## What to say in the room Lead with the reason, not the rule: provider configurations are resolved before expressions are evaluated because the resource-to-provider binding is part of the graph and part of state. Then give both patterns and say which one you would pick at two regions and which at twelve. Candidates who only know "you can't do that" sound stuck; the reason plus the two shapes sounds like someone who has hit it.