Multiple Provider Configurations

Scenario: A deployment genuinely needs to create objects in two separate regions, but every resource in the configuration silently ends up using the same single default provider configuration.

By default, a provider "fakecloud" {} block defines one configuration (one set of credentials, one region/endpoint) that every resource of that provider type uses automatically. A provider alias lets you define a second, named configuration of the same provider - typically for a different region, account, endpoint, or role - and then a resource opts into that alternate configuration explicitly with the provider = fakecloud.dr meta-argument. Without that explicit opt-in, a resource silently falls back to the default (unaliased) configuration, which is exactly the trap in the scenario above: defining a second provider block does nothing on its own unless something actually references it.

When a reusable child module needs to work with more than one provider configuration, it must declare that need explicitly via configuration_aliases in its own required_providers block, and the calling module then wires real aliases to those names through the module block's providers argument. Keep this topology static and explicit in your configuration - avoid trying to compute which alias to use dynamically from a variable, since Terraform needs provider configuration resolved early and predictably, before most values are known.

Analogy: Provider aliases are labeled electrical panels in a building - a "Primary" panel and a "Backup Generator" panel. Wiring a new circuit into the building does not automatically connect it to the generator panel; an electrician has to explicitly run that circuit to the correct panel, exactly the way the provider = argument explicitly wires a resource to a specific aliased configuration.

A worked configuration

provider "fakecloud" { alias = "primary" }
provider "fakecloud" { alias = "dr" }

resource "fakecloud_server" "replica" {
  provider = fakecloud.dr
  name     = "api-dr"
}

Cross-account or cross-region aliases concentrate real operational risk in one root module: a single mistaken provider = reference can create or destroy resources in the wrong account entirely. Give each aliased configuration credentials scoped to only what it needs (least privilege), make the account/region visible right in resource and alias names so a reviewer doesn't have to go hunting, and where the provider supports it, add automated checks that refuse to let anything tagged "production" resolve through a development-scoped alias.

Common mistakes in production

• Defining an aliased provider block and assuming resources will "just know" to use it - only an explicit provider = fakecloud.alias_name argument routes a resource to a non-default configuration.
• Giving every aliased provider configuration the same broad credentials "to keep things simple" - this turns one misdirected resource into a cross-account or cross-region incident.

Goal: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it. Reinforce this lesson in the tf-certificate-renewal Terraform lab. Open /labs/terraform and choose slug tf-certificate-renewal; the lab runs real Terraform against the offline FakeCloud provider.