🌍 Terraform Basics & Setup

What Is Terraform?

Terraform is an open-source IaC tool from HashiCorp that lets you provision infrastructure across hundreds of platforms — AWS, Azure, Google Cloud, Cloudflare, GitHub, Datadog, and many more — using one consistent, declarative language called HCL (HashiCorp Configuration Language). You describe the resources you want in .tf files, and Terraform makes the API calls to create them.

Its superpower is being provider-agnostic: the same workflow and mental model apply whether you're spinning up an AWS server or a DNS record at Cloudflare. Learn Terraform once, and you can automate almost any cloud.

Installing & Verifying

Terraform ships as a single binary. Pick the line for your platform:

# macOS (Homebrew)
brew tap hashicorp/tap
brew install hashicorp/tap/terraform

# Windows (Chocolatey)
choco install terraform

# Ubuntu / Debian
wget -O- https://apt.releases.hashicorp.com/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install terraform

Confirm the install by checking the version:

terraform version

Terraform v1.9.5
on linux_amd64

HCL: Providers & Resources

HCL is built from blocks. Each block has a type, optional labels, and a body of arguments. The two you'll write most are provider and resource.

Providers — the plugins that talk to a platform

A provider is what teaches Terraform how to speak a given platform's API. You declare which providers you need and configure them:

# Declare required providers and pin their versions for reproducibility.
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"   # allow 5.x, but not 6.0 — predictable upgrades
    }
  }
  required_version = ">= 1.5.0"
}

# Configure the AWS provider (credentials come from your environment/CLI).
provider "aws" {
  region = "us-west-2"
}

Resources — the things you actually create

A resource block describes one piece of infrastructure. The two labels are the resource type and a local name you use to reference it elsewhere.

# resource "<TYPE>" "<LOCAL NAME>" { ...arguments... }
resource "aws_instance" "web_server" {
  ami           = "ami-0c55b159cbfafe1f0"  # machine image
  instance_type = "t3.micro"               # VM size

  tags = {
    Name        = "WebServer"
    Environment = "Production"
  }
}

# Reference one resource from another to build a dependency.
resource "aws_eip" "web_ip" {
  instance = aws_instance.web_server.id   # Terraform infers the order
}

Data sources — read without creating

When you need to look up something that already exists rather than create it, use a data block:

# Look up the latest Amazon Linux AMI instead of hardcoding an ID.
data "aws_ami" "amazon_linux" {
  most_recent = true
  owners      = ["amazon"]

  filter {
    name   = "name"
    values = ["al2023-ami-*-x86_64"]
  }
}

resource "aws_instance" "web" {
  ami           = data.aws_ami.amazon_linux.id   # use the looked-up value
  instance_type = "t3.micro"
}

Variables & Outputs

Hardcoding values makes configs rigid. Variables are the inputs that parameterize your code; outputs are the values you expose after an apply.

Input variables

# variables.tf — declare inputs with types, defaults, and validation.
variable "region" {
  description = "AWS region to deploy into"
  type        = string
  default     = "us-west-2"
}

variable "instance_count" {
  description = "How many web servers to create"
  type        = number
  default     = 2
}

variable "environment" {
  description = "Deployment environment"
  type        = string
  default     = "development"

  validation {
    condition     = contains(["development", "staging", "production"], var.environment)
    error_message = "Environment must be development, staging, or production."
  }
}

Reference variables with var.<name>:

# main.tf — use the variables.
provider "aws" {
  region = var.region
}

resource "aws_instance" "server" {
  count         = var.instance_count                # make N copies
  ami           = data.aws_ami.amazon_linux.id
  # A ternary picks a bigger box in production:
  instance_type = var.environment == "production" ? "t3.medium" : "t3.micro"

  tags = {
    Name        = "server-${count.index + 1}"
    Environment = var.environment
  }
}

Outputs

Outputs surface useful values — an IP, a URL, an ARN — after Terraform runs:

# outputs.tf
output "instance_ips" {
  description = "Public IPs of the created servers"
  value       = aws_instance.server[*].public_ip
}

output "db_connection" {
  description = "Database connection string"
  value       = aws_db_instance.main.endpoint
  sensitive   = true   # hides the value in CLI output
}

The init / plan / apply Cycle

Terraform's entire day-to-day boils down to four commands. Master this rhythm and you've mastered the tool.

terraform init — prepare the directory

Downloads the providers and modules your config needs and sets up the backend. Run it once per project and again whenever you add a provider or module.

terraform init            # download providers, set up backend
terraform init -upgrade   # pull newer allowed provider versions

terraform plan — preview the diff

The safety step. Terraform compares your code to recorded state and shows exactly what it would change — nothing is touched yet.

terraform plan                  # print the diff
terraform plan -out=tfplan      # save the plan to apply later, verbatim

Terraform will perform the following actions:

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

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

terraform apply — make it real

Executes the plan. By default it shows the diff again and waits for you to type yes.

terraform apply             # prompts for confirmation
terraform apply tfplan      # apply a saved plan with no prompt
terraform apply -auto-approve   # skip the prompt (use only in CI)

terraform destroy — tear it all down

Removes every resource this configuration manages. Priceless for cleaning up practice environments so you don't get billed.

terraform destroy   # prompts before deleting everything managed here

State: The Heart of Terraform

Terraform keeps a state file (terraform.tfstate) that maps your code to the real resources it created. State is how Terraform knows that aws_instance.web in your code corresponds to instance i-0abc123 in AWS — and therefore what to change on the next apply.

Local vs. remote state

By default state is a local file — fine for solo experiments, dangerous for teams. Two people running apply against separate local state files will clobber each other. The fix is remote state stored in a shared, encrypted backend, with state locking so only one apply runs at a time.

# backend.tf — store state in S3, lock with DynamoDB.
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "production/network/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true               # encrypt sensitive values at rest
    dynamodb_table = "terraform-locks"  # prevents concurrent applies
  }
}

Handy state commands

terraform state list                 # list resources Terraform tracks
terraform state show aws_instance.web # inspect one resource in detail
terraform output                      # print output values

Modules

A module is a reusable package of resources with its own inputs and outputs — the IaC equivalent of a function. Instead of copy-pasting the same VPC definition into every project, you write it once and call it wherever you need it.

# Call a module: pass inputs, receive outputs.
module "vpc" {
  source = "./modules/vpc"    # local path, Git URL, or the public Registry

  name               = "main-vpc"
  cidr_block         = "10.0.0.0/16"
  availability_zones = ["us-west-2a", "us-west-2b"]
}

# Use a module output just like any other reference.
resource "aws_instance" "app" {
  ami           = data.aws_ami.amazon_linux.id
  instance_type = "t3.micro"
  subnet_id     = module.vpc.private_subnet_ids[0]
}

Modules can come from a local folder, a Git repository, or the public Terraform Registry, which hosts thousands of community-maintained modules for common patterns.

Practice & Quiz

resource "aws_s3_bucket" "assets" {
  bucket = "app-assets"
}

# variables.tf
variable "bucket_name" {
  description = "Name of the assets bucket"
  type        = string
  default     = "app-assets"
}

# main.tf
resource "aws_s3_bucket" "assets" {
  bucket = var.bucket_name
}

Best Practices & Pitfalls

✅ Do

• Run terraform fmt and terraform validate before committing
• Always plan and read the diff before apply
• Use remote state with locking for anything a team touches
• Pin provider and module versions for reproducible builds
• Split configs into main.tf, variables.tf, outputs.tf for readability

❌ Don't

• Commit *.tfstate or *.tfvars containing secrets to Git
• Hardcode credentials in .tf files — use environment variables or a secrets manager
• Use -auto-approve on production without a reviewed plan
• Edit resources by hand in the console — that reintroduces drift
• Overuse -target; it can skip dependencies and leave state inconsistent

# .gitignore for Terraform projects
**/.terraform/*
*.tfstate
*.tfstate.*
*.tfvars      # often holds secrets
crash.log

Summary

📚 Additional Resources

• HashiCorp — Get Started with Terraform on AWS
• Terraform — the configuration language (docs)
• Terraform — state documentation
• Terraform Registry — providers & modules

🚀 What's Next?

Terraform is provider-agnostic, but AWS also has its own native IaC service that's deeply integrated with its ecosystem. Next up: AWS CloudFormation — YAML/JSON templates, stacks, change sets, and drift detection, and how it compares to what you just learned.