Multiple Provider Configurations

Scenario: A deployment must create objects in two regions, but every resource silently uses the default provider configuration.

Provider aliases represent distinct configurations of the same provider—often regions, accounts, endpoints, or roles. Resources select an alias with the provider meta-argument. Child modules receive mappings through the module block's providers argument and declare configuration_aliases when needed. Avoid computing provider configurations dynamically; model the topology explicitly.

Analogy: Aliases are named electrical panels. A circuit must explicitly connect to the correct panel; merely having two panels does not route power.

A worked configuration

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

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

Cross-account aliases concentrate risk. Give each configuration least-privilege credentials, make account and region visible in names, and add checks that prevent production resources from using a development identity.

Note: Treat the plan as a change contract: understand every create, update, replacement, and destroy before approving it.

Goal: 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.