Skip to main content
In this lesson we’ll cover the Terraform provider meta-argument and how to configure multiple provider instances within a single configuration. For reference, see the official provider meta-argument docs: https://developer.hashicorp.com/terraform/language/meta-arguments/provider. A provider block tells Terraform how to authenticate and interact with a target platform (for example, AWS, Azure, GitHub, Vault). When managing resources across different accounts, regions, or platform settings, you can declare more than one provider block of the same provider type. Add an alias to additional provider blocks to create named configurations, and then select the desired configuration inside a resource using the provider meta-argument. Why this matters:
  • Provides precise control over where each resource is created.
  • Enables multi-account and multi-region deployments from a single Terraform configuration.
  • Facilitates using different credentials, roles, or regions for specific resources.

​
How it works — step by step

  1. Define one or more provider blocks. Any provider block without an alias is the default configuration and is used by resources that do not explicitly set a provider.
  2. Add alias = "<name>" to create additional named configurations.
  3. In a resource block, set provider = <provider_name>.<alias> to target a specific provider configuration.
Example rules:
  • If at least one provider block has no alias, it becomes the default. Resources without an explicit provider will use that default.
  • If all provider blocks are aliased (no default), every resource must explicitly set the provider meta-argument.

​
Quick example

  • The first provider block below is the default AWS provider (used by resources that do not specify a provider).
  • The second provider block is an aliased configuration named prod for a different region (or different credentials).
provider "aws" {
  region = "us-east-1"
}

provider "aws" {
  alias  = "prod"
  region = "us-west-1"
}

resource "aws_s3_bucket" "dev_bucket" {
  bucket = "my-dev-bucket"
}

resource "aws_s3_bucket" "prod_bucket" {
  provider = aws.prod
  bucket   = "my-prod-bucket"
}
Explanation:
  • provider "aws" { region = "us-east-1" } — default provider configuration. aws_s3_bucket.dev_bucket will be created using this configuration.
  • provider "aws" { alias = "prod" region = "us-west-1" } — named provider configuration aws.prod, which can point to a different region or use different credentials/role.
  • resource "aws_s3_bucket" "prod_bucket" { provider = aws.prod ... } — creates prod_bucket using the aliased aws.prod provider (so it will be created in us-west-1).

​
Common scenarios and examples

ScenarioUse caseExample
Separate accountsDeploy dev vs production into different AWS accountsUse different credentials for provider "aws" blocks and alias the production provider
Multiple regionsCreate resources in us-east-1 and us-west-1provider "aws" { region = "us-east-1" } and provider "aws" { alias = "west" region = "us-west-1" }
Assume role / different credentialsUse different IAM roles or API tokens for different resourcesConfigure assume_role or credentials per provider block and reference via alias
Cross-region replicationSource S3 bucket in one region and destination in anotherCreate two aws_s3_bucket resources each using the appropriate provider configuration

​
Best practices

  • Keep provider configuration and credentials secure (environment variables, shared credentials file, or Terraform Cloud variables).
  • Use clear alias names (for example, prod, staging, europe) to make intent obvious.
  • Minimize mixing too many provider instances in a single file; group related resources into modules when appropriate.
  • When all provider blocks are aliased, the configuration requires explicit provider assignments for every resource — consider adding a sensible default to reduce repetition.
If you define only aliased provider blocks (i.e., every provider block has an alias), then no default provider exists and every resource must explicitly set the provider meta-argument. Conversely, if you leave at least one provider block without an alias, that block becomes the default and resources without an explicit provider will use it.
Be careful with credentials and roles: each provider block can have its own authentication settings. Ensure the credentials or role configured for an alias have the required permissions for the resources you intend to create in that account/region.

​
Use cases (expanded)

  • Cross-region replication: create a source S3 bucket in one region and a destination bucket in another, then configure replication.
  • Multi-account deployments: assign different credentials to each provider block (via environment variables, credentials blocks, or assume_role) and use aliases to deploy resources into the intended account.
  • Mixed environments: deploy some resources to a default/dev account and others to production without splitting into multiple Terraform configurations—use aliases and the provider meta-argument to control placement.
That’s the core idea behind the provider meta-argument: it allows precise selection of which provider configuration Terraform uses per resource, enabling flexible multi-account, multi-region, and multi-cloud workflows. Let’s proceed to a quick demo.

Watch Video