Providers

You have declared providers and used them. But there is much more to providers than a single block in versions.tf. Real infrastructure spans multiple regions, multiple accounts, and multiple clouds — all in the same configuration. This lesson shows you how providers handle all of it.

How Providers Authenticate

Every provider needs some form of identity to interact with its platform. For AWS, that is IAM credentials. For Azure, it is a service principal. For Cloudflare, it is an API token. Each provider has its own authentication mechanism — but all of them follow the same principle: never hardcode credentials in your configuration files.

The AWS provider supports multiple authentication methods, checked in this order of precedence:

A Single Provider — Done Properly

Before we get to multiple providers, let us write the AWS provider block with every argument you should know. This is the complete provider configuration for a single-account, single-region AWS setup — the kind most projects start with.

New terms:

• profile — the name of an AWS named profile in ~/.aws/credentials. Named profiles let you store credentials for multiple AWS accounts in the same file and switch between them by name. The default profile has the name default.
• default_tags block — tags applied automatically to every resource the AWS provider creates in this configuration. Without this, you must add the same tags to every individual resource block. With it, tags cascade down to everything — no repetition, no forgetting.
• assume_role block — tells the AWS provider to assume an IAM role before making API calls. Used in multi-account setups where your personal credentials authenticate to one account and then assume a role in a different account. The ARN identifies which role to assume.

provider "aws" {
  region  = var.region
  profile = var.aws_profile

  default_tags {
    tags = {
      Project     = "acme-platform"
      ManagedBy   = "Terraform"
      Environment = var.environment
    }
  }
}

$ terraform apply

aws_s3_bucket.logs: Creating...
aws_instance.web: Creating...
aws_security_group.web: Creating...

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

$ aws s3api get-bucket-tagging --bucket acme-logs-prod-a3f2b1c4
{
    "TagSet": [
        { "Key": "Environment",  "Value": "prod"           },
        { "Key": "ManagedBy",    "Value": "Terraform"      },
        { "Key": "Project",      "Value": "acme-platform"  }
    ]
}

Provider Aliases — Multiple Regions in One Configuration

A common real-world requirement: your main infrastructure runs in us-east-1 but you must also create an SSL certificate in us-east-1 and a CloudFront distribution — but AWS requires ACM certificates for CloudFront to exist specifically in us-east-1 regardless of where your application runs. Or your application is deployed to two regions for high availability.

You cannot solve this with one provider block. Terraform does not allow two provider blocks for the same provider with different configurations — unless you give one of them an alias. We are about to write a configuration that deploys an S3 bucket in two AWS regions simultaneously using provider aliases.

New terms:

• alias — a unique name given to a provider configuration. When a provider has an alias, it is no longer the default for that provider type. Resources must explicitly reference it using the provider meta-argument.
• provider meta-argument — an argument available on every resource block that tells Terraform which provider configuration to use. Written as provider = aws.secondary where aws is the provider type and secondary is the alias. Resources without this argument use the default provider configuration.
• default provider — the provider block without an alias. Every provider type can have at most one default configuration. All resources that do not specify a provider argument use the default.

provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = { ManagedBy = "Terraform" }
  }
}

provider "aws" {
  alias  = "eu"
  region = "eu-west-1"

  default_tags {
    tags = { ManagedBy = "Terraform" }
  }
}

resource "aws_s3_bucket" "primary" {
  bucket = "acme-primary-us-${random_id.suffix.hex}"
}

resource "aws_s3_bucket" "replica" {
  provider = aws.eu
  bucket   = "acme-replica-eu-${random_id.suffix.hex}"
}

resource "random_id" "suffix" {
  byte_length = 4
}

$ terraform apply

Terraform will perform the following actions:

  # aws_s3_bucket.primary will be created
  + resource "aws_s3_bucket" "primary" {
      + bucket   = (known after apply)
      + provider = "provider[\"registry.terraform.io/hashicorp/aws\"]"
      + region   = "us-east-1"
    }

  # aws_s3_bucket.replica will be created
  + resource "aws_s3_bucket" "replica" {
      + bucket   = (known after apply)
      + provider = "provider[\"registry.terraform.io/hashicorp/aws\"].eu"
      + region   = "eu-west-1"
    }

Plan: 3 to add, 0 to change, 0 to destroy.

  Enter a value: yes

random_id.suffix: Creating...
random_id.suffix: Creation complete [id=a3f2b1c4]

aws_s3_bucket.primary: Creating... [provider: us-east-1]
aws_s3_bucket.replica: Creating... [provider: eu-west-1]

aws_s3_bucket.primary: Creation complete [id=acme-primary-us-a3f2b1c4]
aws_s3_bucket.replica: Creation complete [id=acme-replica-eu-a3f2b1c4]

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Multi-Account with assume_role

Enterprise AWS setups use multiple accounts — one for production, one for staging, one for shared services, one for logging. Your IAM credentials live in a central account. To manage resources in other accounts, Terraform assumes an IAM role in each target account. This is the assume_role pattern.

We are writing a configuration that manages resources in two AWS accounts simultaneously. Your credentials authenticate to account A. Terraform assumes a deployment role in account B to create resources there — all from one configuration.

New terms:

• assume_role block — instructs the provider to call AWS STS (Security Token Service) to obtain temporary credentials for the specified role before making any API calls. The temporary credentials expire after a session duration you control.
• role_arn — the Amazon Resource Name of the IAM role to assume. The role must exist in the target account and must have a trust policy that allows your IAM identity in the source account to assume it.
• session_name — a label attached to the temporary session. Appears in CloudTrail logs so you can identify which Terraform run made which API call. Always set this to something descriptive.
• external_id — an optional secret shared between the caller and the role's trust policy. Prevents the confused deputy problem — a scenario where a third party tricks your service into assuming a role on their behalf. Use it whenever an external party defines the role you assume.

provider "aws" {
  region  = "us-east-1"
  profile = "shared-services"
}

provider "aws" {
  alias   = "production"
  region  = "us-east-1"
  profile = "shared-services"

  assume_role {
    role_arn     = "arn:aws:iam::111122223333:role/TerraformDeployRole"
    session_name = "terraform-production-deploy"
    external_id  = var.assume_role_external_id
  }
}

resource "aws_s3_bucket" "shared_artifacts" {
  bucket = "acme-shared-artifacts"
}

resource "aws_s3_bucket" "prod_data" {
  provider = aws.production
  bucket   = "acme-prod-data"
}

$ terraform apply

Terraform will perform the following actions:

  # aws_s3_bucket.shared_artifacts will be created
  + resource "aws_s3_bucket" "shared_artifacts" {
      + bucket = "acme-shared-artifacts"
    }
    # Using profile: shared-services (account 999988887777)

  # aws_s3_bucket.prod_data will be created
  + resource "aws_s3_bucket" "prod_data" {
      + bucket = "acme-prod-data"
    }
    # Assuming role in account 111122223333

Plan: 2 to add, 0 to change, 0 to destroy.

  Enter a value: yes

aws_s3_bucket.shared_artifacts: Creating... [account: 999988887777]
aws_s3_bucket.prod_data: Creating... [account: 111122223333]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Multiple Different Providers — AWS and Cloudflare Together

One of Terraform's most powerful capabilities is managing completely different platforms in a single configuration. Here is a practical example: you deploy a web application to AWS and then automatically update the Cloudflare DNS record to point to it — all in one apply.

We are writing a configuration that creates an EC2 instance on AWS and a Cloudflare DNS A record pointing to its public IP. When the instance IP changes — for example after a destroy and recreate — the DNS record updates automatically on the next apply.

New terms:

• cloudflare provider — the Terraform provider for Cloudflare, maintained by Cloudflare themselves. Authenticates via an API token scoped to specific zones and permissions. Never uses username/password.
• cloudflare_record resource — creates or manages a DNS record in a Cloudflare zone. The zone_id identifies which domain the record belongs to. The value is what the record resolves to — in this case, the EC2 instance's public IP.
• cross-provider reference — when the value argument of a resource in one provider references an attribute of a resource in a different provider. aws_instance.web.public_ip inside a cloudflare_record resource is a cross-provider reference. Terraform resolves the dependency automatically — the EC2 instance is created first, then the DNS record uses its IP.
• proxied — a Cloudflare-specific argument. When true, traffic to this DNS record flows through Cloudflare's network first — enabling CDN, DDoS protection, and WAF. When false, the record is a plain DNS record with no Cloudflare proxy.

provider "aws" {
  region = "us-east-1"
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name      = "web-server"
    ManagedBy = "Terraform"
  }
}

resource "cloudflare_record" "web" {
  zone_id = var.cloudflare_zone_id
  name    = "app"
  type    = "A"
  value   = aws_instance.web.public_ip
  proxied = true
  ttl     = 1
}

$ terraform apply

Terraform will perform the following actions:

  # aws_instance.web will be created
  + resource "aws_instance" "web" {
      + ami           = "ami-0c55b159cbfafe1f0"
      + instance_type = "t3.micro"
      + public_ip     = (known after apply)
    }

  # cloudflare_record.web will be created
  + resource "cloudflare_record" "web" {
      + name    = "app"
      + proxied = true
      + type    = "A"
      + value   = (known after apply)
      + zone_id = "abc123def456"
    }

Plan: 2 to add, 0 to change, 0 to destroy.

  Enter a value: yes

aws_instance.web: Creating...
aws_instance.web: Creation complete after 32s [id=i-0abc123def456789]
  public_ip = "54.211.89.132"

cloudflare_record.web: Creating...
cloudflare_record.web: Creation complete after 1s [id=cf-record-xyz]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Provider Version Management

Provider versions matter more than most beginners realise. A major provider version bump — AWS provider 4.x to 5.x — can introduce breaking changes that rename arguments, remove resources, or change behaviour. Understanding how to manage this is a production-critical skill.

We are writing the version constraint patterns you will use in every project and the command to upgrade providers safely.

New terms:

• ~> (pessimistic constraint operator) — allows only the rightmost version component to increment. ~> 5.0 allows 5.x but not 6.0. ~> 5.31 allows 5.31.x but not 5.32. The more specific you are, the tighter the constraint.
• terraform init -upgrade — re-resolves all provider versions against the current constraints and downloads newer versions if available. Updates the lock file with the new versions. Run this deliberately when you want to upgrade — not automatically.
• terraform providers lock — regenerates the lock file with checksums for multiple platforms. Use this when your local machine is macOS but your CI runs on Linux — the lock file needs checksums for both platforms so terraform init works on both without failing checksum verification.

terraform {
  required_version = ">= 1.5.0, < 2.0.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.31"
    }
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = ">= 4.0.0, < 5.0.0"
    }
  }
}

$ terraform init -upgrade

Initializing provider plugins...
- Finding hashicorp/aws versions matching "~> 5.31"...
- Finding cloudflare/cloudflare versions matching ">= 4.0.0, < 5.0.0"...
- Installing hashicorp/aws v5.35.0...
- Installing cloudflare/cloudflare v4.20.0...

Terraform has made some changes to the provider lock file:

  - hashicorp/aws: previous version was 5.31.0, new version is 5.35.0
  - cloudflare/cloudflare: version unchanged at 4.20.0

$ terraform providers lock -platform=linux/amd64 -platform=darwin/arm64

Providers locked for:
  - linux/amd64
  - darwin/arm64

Common Mistakes

Practice Questions

Quiz