Skip to main content
Welcome to this lesson on the provider block in Terraform. Provider blocks are the bridge between Terraform Core and the APIs of the platforms you manage. Terraform Core handles state, planning, and graphing, but it relies on providers — separate plugins — to perform platform-specific API calls and authentication. Terraform Core reads your configuration, constructs the resource graph, and creates execution plans. Providers implement the platform logic and authentication so Terraform can create, update, and delete resources on your behalf.
The image illustrates Terraform providers, including various cloud platforms and other services, connected to Terraform. Examples include AWS, Azure, Kubernetes, Google Cloud, Infoblox, and GitHub.
In a typical architecture diagram, cloud platforms (AWS, Azure, Google Cloud, Kubernetes, etc.) appear on one side while other services (GitHub, DNS providers, monitoring systems) appear on the other. Providers encapsulate all platform-specific behavior so Terraform Core can remain focused on orchestration.
The image illustrates Terraform providers, showing its core connected to various cloud platforms (such as Kubernetes, AWS, Azure, Google Cloud) and other services (like Infoblox and GitHub).
Because providers are independent plugins, Terraform stays modular: provider authors maintain platform APIs and Terraform Core manages lifecycle and orchestration.

​
What a provider block does

A provider block (written in HCL like the rest of your Terraform) specifies how Terraform authenticates to and communicates with a platform. Typical configuration options include:
  • Endpoints and regions
  • Authentication credentials or identity sources
  • API version or feature toggles
  • Provider-specific behavior and defaults
Where to put provider blocks: Many teams use a providers.tf file for clarity, but Terraform reads any *.tf file in the working directory. File placement is a convention, not a requirement.

​
Provider block structure and examples

  • The syntax is provider "<name>" { ... }. The provider label must match the provider name registered in the Terraform Registry (for example: aws, azurerm, github).
  • Each provider exposes its own arguments — consult the provider’s Registry page for exact options.
Example: AWS provider (using a named profile) 
provider "aws" {
  region  = "us-east-2"
  profile = "prd-workload"
}
Example: Azure Resource Manager provider (the Azure provider requires an empty features {} block; authentication fields shown as placeholders) 
provider "azurerm" {
  features {}

  tenant_id       = "tenant-id"
  subscription_id = "sub-id"
  client_id       = "client-id"
  client_secret   = "client-secret"
}
These examples show explicit credentials only for clarity. In production, avoid embedding secrets in Terraform files — use environment variables, shared credential files, IAM roles/instance profiles, managed identities, Vault, or other secret stores.
Use secure secret management and the principle of least privilege. Avoid storing credentials or secrets directly in .tf files or version control.
Providers evolve independently from Terraform Core. To ensure consistent, reproducible deployments and to avoid unexpected breaking changes, pin provider versions with the required_providers block inside terraform {}. Example: pinning AWS and Azure providers 
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

​
Authentication methods by provider

Different providers support different authentication mechanisms. The table below summarizes common approaches and recommended best practices.
ProviderCommon authentication methodsBest practice
AWSaccess key/secret, shared credentials file, instance profile / IAM rolePrefer IAM roles (instance profiles) or environment credentials; use least privilege
Azureservice principal (client_id/client_secret), managed identityUse managed identity where possible; rotate service principals regularly
Google Cloud (GCP)service account keys, workload identityUse workload identity or short-lived tokens instead of long-lived keys
GitHubpersonal access tokens (PAT), OAuth appsUse fine-scoped tokens and rotate regularly
Treat provider credentials as highly sensitive: store them in secret stores, rotate them, and grant only the permissions Terraform requires.
Never commit credentials, client secrets, or service account keys into version control. Doing so risks accidental exposure.

​
Provider lifecycle and initialization

When you run terraform init, Terraform performs the following provider-related steps:
  • Reads provider requirements from your configuration (required_providers).
  • Checks local cache for provider binaries; if missing, downloads required provider plugins from the Terraform Registry (https://registry.terraform.io).
  • Verifies downloads using cryptographic checksums and installs plugins locally.
  • Initializes providers with the configuration you provided.
This ensures team members use the same provider versions and that providers are securely downloaded and verified.

​
Using multiple provider configurations

A single provider configuration can manage many resource types for that platform (for example, one aws provider can manage compute, storage, networking, and databases). You only need one provider block per account/region/scope. If you must target multiple accounts, regions, or scopes, create multiple provider configurations and use alias to reference them in resources. Example flow:
  • Define the default provider for the main account.
  • Define an aliased provider for the secondary account or other region.
  • Reference the aliased provider from resources with provider = aws.secondary.

​
Where to find providers and documentation

Primary sources:
  • Terraform Registry: https://registry.terraform.io — provider pages include resource types, arguments, data sources, authentication examples, and change logs.
  • Provider GitHub repositories — useful for release notes, issues, and deep dives.
  • Official cloud provider docs for platform-specific details.
Useful links and references:

​
Summary

  • Provider blocks configure how Terraform talks to platform APIs (regions, endpoints, credentials, features).
  • Providers are independent plugins — pin versions with required_providers to keep deployments stable.
  • Never store secrets in .tf files; use secret management and least privilege.
  • Run terraform init to download and initialize providers; Terraform verifies provider binaries automatically.
  • Consult the Terraform Registry for provider documentation, examples, and versioning information.
This concludes the deep dive into provider blocks. A hands-on lab is recommended to practice writing provider blocks and creating resources using those providers. In the next sections we’ll build on this foundation and create actual resources with these providers.

Watch Video

Practice Lab