Providers: The Plugin Architecture

A provider is a plugin that translates Terraform resource operations into API calls against a specific platform. The provider is the bridge between the configuration and the real world. This lesson teaches the provider architecture, the configuration, and the multi-provider patterns.

What a provider does

A provider contains:

• The resource schema (e.g. aws_instance has ami, instance_type, tags, etc.).
• The provider API client (HTTP client, auth handling, retry logic).
• The CRUD operations (create, read, update, delete) for each resource type.
• The replacement rules (which attribute changes force replacement).
• The data source implementations.

The provider is a stand-alone process. The Terraform CLI communicates with the provider over an internal RPC protocol. The provider is what owns the knowledge of the platforms API.

Declaring a provider

The required_providers block declares which providers the configuration uses:

terraform {
  required_version = ">= 1.9.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

The fields:

• source — the registry address. HashiCorps registry is registry.terraform.io. The format is <NAMESPACE>/<TYPE>.
• version — the version constraint. The ~> 5.0 means “compatible release” (5.0.x, 5.1.x, 5.2.x, but not 6.0.x).

The provider is downloaded by terraform init from the registry.

Configuring a provider

The provider block configures the provider:

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

  default_tags {
    tags = {
      Environment = "production"
      ManagedBy   = "terraform"
    }
  }
}

The fields are provider-specific. The provider documentation is the source of truth.

Multi-provider configurations

A configuration can use multiple providers:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

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

provider "azurerm" {
  features {}
}

The resources use the type prefix to disambiguate:

resource "aws_instance" "web" {
  ami = "ami-0e1bed4f"
}

resource "azurerm_virtual_machine" "web" {
  # ...
}

Provider aliases

A provider alias is a configuration that allows multiple instances of the same provider:

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

provider "aws" {
  alias  = "west"
  region = "us-west-2"
}

resource "aws_instance" "web_east" {
  provider = aws
  ami = "ami-0e1bed4f"
}

resource "aws_instance" "web_west" {
  provider = aws.west
  ami = "ami-0e1bed4f"
}

The alias is used to address the specific provider instance.

The legitimate use cases:

• Multi-region deployments.
• Multi-account deployments.
• Multi-role deployments (one for the operator, one for the application).

Provider authentication

The provider authenticates against the platform. The authentication method is provider-specific:

• AWS — IAM roles, environment variables, or AWS_PROFILE.
• Azure — service principals, managed identities, or environment variables.
• GCP — service accounts, workload identity, or environment variables.
• GitHub — personal access tokens, GitHub App tokens, or GitHub Actions tokens.

The course has a dedicated lesson on provider authentication (Part XVII).

Provider versions

The required_providers block pins the version:

required_providers {
  aws = {
    source  = "hashicorp/aws"
    version = "~> 5.0"
  }
}

The version constraint is the floor. The lockfile records the resolved version.

The lockfile is the source of truth for the actual provider version. The configuration is the source of truth for the constraint.

Provider blocks vs required_providers

The two have different roles:

The provider block may be omitted if the defaults are acceptable. The required_providers block is required for any provider that is not in the default namespace.

What comes next

The next lesson is provider version constraints — the production control for provider supply chain.

Verification