Infrastructure as Code with Terraform

Clicking through the console is fine for learning, but it cannot be reviewed, repeated or rolled back. Infrastructure as Code (IaC) describes resources in files kept in Git, so environments are reproducible and every change goes through a pull request.

A first configuration

main.tf:

terraform {
  required_providers {
    aws = { source = "hashicorp/aws", version = "~> 5.0" }
  }
  backend "s3" {
    bucket         = "pandadev-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "eu-central-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

provider "aws" {
  region = var.region
  default_tags { tags = { project = "pandadev", environment = var.environment } }
}

resource "aws_s3_bucket" "uploads" {
  bucket = "pandadev-uploads-${var.environment}"
}

resource "aws_s3_bucket_public_access_block" "uploads" {
  bucket                  = aws_s3_bucket.uploads.id
  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_versioning" "uploads" {
  bucket = aws_s3_bucket.uploads.id
  versioning_configuration { status = "Enabled" }
}

variables.tf:

variable "region"      { default = "eu-central-1" }
variable "environment" { type = string }

The workflow

terraform init                                # download providers, connect to state
terraform fmt && terraform validate
terraform plan -var environment=prod          # show exactly what would change
terraform apply -var environment=prod         # make the changes after you confirm

Always read the plan. A line marked -/+ (destroy and recreate) on a database means data loss. Protect critical resources:

resource "aws_db_instance" "main" {
  # ...
  deletion_protection = true
  lifecycle { prevent_destroy = true }
}

State

Terraform records what it created in a state file. Keep it in a remote, encrypted, versioned S3 bucket with locking (the backend "s3" block above) so two people cannot apply at once. State can contain secrets: restrict who can read the bucket, and never commit state to Git.

Modules and environments

Put reusable pieces (a VPC, a web service, a database) into modules, then instantiate them per environment with different variables. Staging and production then differ only in sizes and names, so what works in staging works in production.

IaC in CI

On every pull request, run terraform fmt -check, validate and plan, and post the plan as a comment for review. Apply only from main, ideally through OIDC with a role that only the pipeline can assume. Tools like tfsec or checkov scan for insecure settings such as public buckets or open security groups before anything is created.

Final project

Using Terraform only: create a VPC with public and private subnets in two AZs, an ALB with an ACM certificate, a container service on ECS Fargate running a small Flask app, an RDS PostgreSQL database in private subnets with Multi-AZ and encryption, a private S3 bucket for uploads served through presigned URLs, CloudWatch alarms for 5xx errors and database storage, and a monthly budget alert. Then run terraform destroy and confirm nothing is left running, which is also a lesson in cost control.