Terraform Provider

Terraform hub

A Terraform provider is a plugin that gives Terraform the ability to create, read, update, and delete resources in a specific platform — such as AWS, GCP, Azure, or GitHub. Each provider translates your HCL configuration into real API calls for that platform.

What Is a Terraform Provider?

A Terraform provider is the bridge between your HCL configuration and a real cloud platform. When you write resource "aws_instance" "web", Terraform does not know how to talk to AWS by itself — the AWS provider plugin does. The provider handles authentication, API calls, error handling, and translating Terraform's plan into real infrastructure changes.

Think of it like a driver in your operating system. Your OS does not know how to talk to every printer — it loads the right driver for each one. Terraform loads the right provider for each platform.

◈ DIAGRAM

+------------------------------------------+
| Your HCL Configuration (.tf files)       |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Terraform Core (reads config, plans)     |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Provider Plugin (e.g., AWS Provider)     |
+------------------------------------------+
                    |
                    v
+------------------------------------------+
| Cloud Platform API (e.g., AWS EC2 API)   |
+------------------------------------------+

How to Declare a Provider

Every provider must be declared in a required_providers block and configured with a provider block:

HCL

# versions.tf — always pin your provider versions
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"   # registry address
      version = "~> 5.0"          # allow 5.x but not 6.0
    }
  }
}
 
# provider.tf — configure the provider
provider "aws" {
  region = "ap-south-1"   # Mumbai region for Indian workloads
}

Provider Authentication

Providers need credentials to call cloud APIs. Never hardcode credentials in your .tf files.

HCL

# WRONG — never do this
provider "aws" {
  region     = "ap-south-1"
  access_key = "AKIAIOSFODNN7EXAMPLE"   # hardcoded key — never
  secret_key = "wJalrXUtnFEMI/K7MDENG" # will end up in Git
}
 
# RIGHT — use environment variables or IAM roles
# export AWS_ACCESS_KEY_ID=...
# export AWS_SECRET_ACCESS_KEY=...
# Or use an EC2 instance profile / ECS task role
provider "aws" {
  region = "ap-south-1"   # credentials come from environment
}

Provider Version Pinning

Always pin provider versions. An unpinned provider will upgrade automatically and may introduce breaking changes.

HCL

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"   # ~> means >= 5.0 and < 6.0
    }
    github = {
      source  = "integrations/github"
      version = "~> 5.0"
    }
  }
}

Multiple Providers and Provider Aliases

You can use multiple providers in one configuration — or use the same provider twice with an alias (common for multi-region setups):

HCL

# Primary region
provider "aws" {
  region = "ap-south-1"   # Mumbai
}
 
# DR region — uses an alias
provider "aws" {
  alias  = "us_east"      # referenced as provider = aws.us_east
  region = "us-east-1"
}
 
# Use the aliased provider for DR resources
resource "aws_s3_bucket" "dr_backup" {
  provider = aws.us_east   # this bucket goes to US East
  bucket   = "razorpay-dr-backup-2024"
}

Where Providers Come From

When you run terraform init, Terraform downloads providers from the Terraform Registry (registry.terraform.io) into the .terraform/ directory. This directory should be in your .gitignore.

Bash

# After adding a new provider, always run:
terraform init
 
# To upgrade providers to the latest allowed version:
terraform init -upgrade

Troubleshooting Providers

Error	Cause	Fix
`Failed to query available provider packages`	No internet or registry unreachable	Check network, use `-plugin-dir` for air-gapped
`Error: Inconsistent dependency lock file`	`.terraform.lock.hcl` out of sync	Run `terraform init -upgrade`
`No valid credential sources found`	Missing AWS credentials	Set `AWS_ACCESS_KEY_ID` env var or attach IAM role
`Error: configuring Terraform AWS Provider: no valid credential sources`	Wrong region or missing profile	Check `AWS_PROFILE` or `AWS_DEFAULT_REGION`

Remember
The .terraform.lock.hcl file records the exact provider version and hash that was downloaded. Commit this file to Git so every team member uses the same provider version.

Common Mistake
Forgetting to run terraform init after adding a new provider. Terraform will error with Provider registry.terraform.io/hashicorp/X not installed until you initialise.

Frequently Asked Questions

How many resources does a typical major cloud provider plugin for Terraform support?

The AWS, Azure (azurerm), and Google (google) providers each support several hundred to well over a thousand distinct resource and data source types, covering nearly every service the cloud platform offers, and they're versioned and released independently of Terraform core itself. Providers are distributed through the Terraform Registry, and your configuration pins a version constraint for each one in a `required_providers` block so upgrades are deliberate, not automatic.

What's a common mistake with provider version constraints?

Leaving a provider version unpinned (or using a loose constraint like `>= 4.0`) in shared/production configuration — a provider major version upgrade can introduce breaking changes to resource schemas that turn a routine `terraform plan` into an unexpected destroy-and-recreate. Pin to a specific minor version range (e.g., `~> 5.10`) and upgrade deliberately after reading the provider's changelog, not as a side effect of a routine `terraform init`.