Terraform Providers: Day2 — Explained Super Simply

This is my Day 2 of 30daysofawsterraform. Thanks to
Piyush Sachdeva for the amazing series. So, let’s begin.

Before writing Terraform code or creating any AWS resources, you must understand Terraform Providers — because providers are the heart of Terraform.

What is a Terraform Provider?

A provider is a plugin that connects Terraform with the external service you want to manage.

Think of it like a translator:

• You write Terraform in HCL (HashiCorp Configuration Language)
• AWS, Azure, GCP, Docker, Kubernetes — they don’t understand HCL
• So the provider converts your Terraform code → into the API calls that AWS/Azure/GCP understand.

Example:
If you write Terraform to create an S3 bucket, Terraform uses:

• AWS provider
• Which calls the AWS S3 API
• And creates the bucket for you So Terraform never creates resources directly — the provider does it for you.

Terraform has 3 types of providers:

1. Official Providers Maintained by HashiCorp Examples:

• AWS
• Azure
• GCP

1. Partner Providers Maintained by the official company but not HashiCorp Example:

• Cloudflare
• Datadog

1. Community Providers Maintained by the open-source community Example:

• Random
• HTTP provider
• Local provider

Where Providers Live: registry.terraform.io

When you search “Terraform AWS provider” on Google, you see:

registry.terraform.io/providers/hashicorp/aws
This page shows:

• All services supported by the AWS provider
• All available resource types (EC2, VPC, IAM, S3, etc.)
• All version numbers
• Documentation
• Example usage

How Does Terraform Download a Provider?
When you run:
terraform init
Terraform:

• Reads your provider block
• Contacts the Terraform Registry
• Downloads the correct provider version
• Stores it in a folder called .terraform

This folder contains:

• Provider plugin (binary)

• Lock files
  Based on OS, the plugin file(provider) format changes; created after “tf init”:

• Windows → .exe

• Mac → .darwin

• Linux → .linux

---

Provider Block Explained

A basic provider block looks like:

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

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

Key Points:

required_providers
Defines:

• Which providers Terraform should use
• Version of each provider

⚠️ Never hard-code AWS access key + secret key inside provider block — security risk.

---

Provider Version vs Terraform Version

There are TWO versions:

Terraform Core version
Example:
required_version = ">= 1.0"
Provider version
Example:
version = "~> 6.0"
These versions are independent, meaning:

• Terraform core is maintained by HashiCorp
• AWS provider is maintained by AWS Because both are maintained separately → compatibility issues can happen That’s why we lock provider versions.

---

Version Constraint Operators (Very Important)

You saw symbols like:

• = Equal to
• != Not equal
• > / < Greater/less

• ~> Pessimistic operator (most used)
  Most important one: ~> (tilde greater-than)
  Example:
  version = "~> 6.0"
  This means:

• Accept version 6.0.x

• Accept version 6.1, 6.2… 6.10

• ❌ BUT don’t accept 7.0+ (major version changes)
  This protects you from breaking changes.

---

Why Not Always Use Latest Provider Version?

Because:

• New versions may introduce breaking changes
• Some resources may behave differently
• Your Terraform code may break So we lock versions until we test the newer ones in a dev environment.

---

Creating Resources Using Providers

A resource example:

resource "aws_vpc" "example" {
  cidr_block = "10.0.0.0/16"
}

Explanation:

• resource → Terraform keyword
• "aws_vpc" → resource type from provider
• "example" → local Terraform name (internal reference) You can refer to this resource elsewhere:

vpc_id = aws_vpc.example.id

---

Commands Used

1. Initialize provider terraform init
2. Check what Terraform will create terraform plan Shows:

• What will be added
• What will be changed
• What will be destroyed
• Apply changes (create actual resource) terraform apply

---

Why Your Plan Failed?

It failed because:

• Your IAM user only had S3 access
• But you tried to create VPC
• So AWS denied it Terraform plan doesn’t call the API → but apply will fail.

---

Terraform State (not explained deeply here)

Terraform creates a file:
terraform.tfstate
This file:

• Tracks what resources Terraform manages
• Compares real environment vs Terraform code
• Ensures idempotency (same outcome every time) State is a very big topic — later in your series.

---

Summary (Super Easy)

---