Infrastructure as Code (IaC)

Infrastructure as Code means managing and provisioning cloud resources through machine-readable configuration files rather than manual processes or interactive dashboards. Terraform, by HashiCorp, is the industry-standard IaC tool — it lets you describe any cloud resource in HCL (HashiCorp Configuration Language) and apply that description to AWS, Azure, GCP, or any of 3,000+ providers.

Why IaC Changed How Teams Build Infrastructure

Before IaC, engineers clicked through cloud consoles to spin up servers, configure networks, and attach storage. Every environment was slightly different, onboarding took days, and recreating a lost environment from memory was a nightmare.

IaC solves all of this:

Problem	IaC Solution
Environments drift apart	All envs share the same code; drift is detected and fixable
No audit trail for infra changes	Every change is a git commit with author and timestamp
Slow manual provisioning	One command (`terraform apply`) provisions hundreds of resources
Hard to replicate environments	Copy the config, change a variable, done
Team silos around infra	Any developer can read and propose infra changes

The Terraform Workflow

Write HCL → terraform init → terraform plan → terraform apply → (change) → terraform destroy

1. Write HCL Configuration

# main.tf — Provision an AWS S3 bucket
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  required_version = ">= 1.6"
}

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

resource "aws_s3_bucket" "data_lake" {
  bucket = "my-company-data-lake-2025"
  tags = {
    Environment = "production"
    Team        = "data-engineering"
  }
}

2. Initialize

terraform init
# Downloads the AWS provider plugin
# Creates .terraform/ directory and .terraform.lock.hcl

3. Plan

terraform plan
# Shows: 1 to add, 0 to change, 0 to destroy
# No real changes made — safe to review

4. Apply

terraform apply
# Terraform shows the plan again and asks for confirmation
# Type 'yes' to proceed

HCL Basics Every Terraform User Should Know

# Strings — use double quotes
name = "production"

# Numbers — no quotes
port = 8080
count = 3

# Booleans
enabled = true

# Lists
availability_zones = ["us-east-1a", "us-east-1b", "us-east-1c"]

# Maps / objects
tags = {
  Environment = "prod"
  Owner       = "platform-team"
}

# Multiline strings
user_data = <<-EOF
  #!/bin/bash
  apt-get update
  apt-get install -y nginx
EOF

IaC vs. Traditional Approaches

Manual (ClickOps)
→ Slow, error-prone, not auditable, irreproducible

Scripts (Bash / Python)
→ Procedural: "run these steps in order"
→ Fragile: can't detect current state, no rollback

Terraform (IaC)
→ Declarative: "here is what I want the world to look like"
→ Idempotent: re-running produces the same result
→ Stateful: Terraform tracks what it created and updates only what changed

Real-World IaC Patterns in 2025

Multi-environment with workspaces or directories:

infra/
├── modules/           # Reusable building blocks
│   ├── vpc/
│   ├── ecs-service/
│   └── rds-postgres/
├── environments/
│   ├── dev/
│   │   └── main.tf   # uses modules, sets dev vars
│   ├── staging/
│   └── production/
└── .github/
    └── workflows/
        └── terraform.yml  # CI/CD pipeline

GitOps-driven IaC:
Changes to Terraform code in the main branch trigger automated plan in CI; merging to production branch triggers apply. No human ever runs Terraform locally against production.

Key Terraform Concepts at a Glance

Concept	What it is
Provider	Plugin that knows how to talk to a cloud API (AWS, Azure, GCP, etc.)
Resource	A single infrastructure object (EC2 instance, S3 bucket, VPC)
Data source	Read-only lookup of existing resources not managed by Terraform
Variable	Input parameter that makes config reusable
Output	Value exported after `apply` (IP address, ARN, etc.)
Module	Reusable group of resources packaged together
State	JSON file tracking what Terraform has provisioned
Backend	Where state is stored (local, S3, Terraform Cloud)

IaC Benefits Summary

Speed — provision a complete VPC + ECS cluster + RDS in minutes
Consistency — dev, staging, and production are guaranteed identical (except the vars you change deliberately)
Version control — infra changes reviewed in pull requests like any other code
Collaboration — no single person holds the tribal knowledge of “how the infra is set up”
Cost visibility — infracost integrates with Terraform to show cost estimates before apply
Disaster recovery — losing a region is recoverable in minutes by applying the same config to a new region