Terraform for the cloud

Why Terraform

CloudFormation only speaks AWS. Many companies use more than one cloud, plus services like GitHub, Cloudflare or Datadog. Terraform uses one language and one workflow for all of them. You write files ending in .tf in HCL (HashiCorp Configuration Language), a simple block-based language. OpenTofu, the open-source fork, reads the same files with the command tofu instead of terraform, so almost everything in this lesson applies to both.

The building blocks

• Provider: a plugin that knows one platform's API, such as hashicorp/aws or hashicorp/azurerm. terraform init downloads it.
• Resource: something Terraform creates and manages, such as aws_s3_bucket. It has a type and a local name.
• Data source: something Terraform only reads, such as the current account ID or an existing VPC. It never creates it.
• Variable: an input, like a parameter, with a type and an optional default.
• Output: a value printed after apply, or read by other configurations.
• Module: a folder of .tf files that you reuse, like a function.

The same versioned bucket in HCL

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"   # pin a major version; check the registry for the current one
    }
  }
}

provider "aws" {
  region = "ap-south-1"   # Mumbai
}

variable "env" {
  type        = string
  description = "Environment name: dev or prod"
  default     = "dev"
}

data "aws_caller_identity" "current" {}

resource "aws_s3_bucket" "results" {
  bucket = "results-${var.env}-${data.aws_caller_identity.current.account_id}"
  tags = {
    env = var.env
  }
}

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

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

output "bucket_name" {
  value = aws_s3_bucket.results.bucket
}

output "bucket_arn" {
  value = aws_s3_bucket.results.arn
}

Read references from left to right: aws_s3_bucket.results.id means "the id attribute of the resource of type aws_s3_bucket named results". Because the versioning resource uses that reference, Terraform knows it must create the bucket first. You rarely need to set the order by hand.

The workflow

terraform init                 # download providers, set up the backend (run once per folder, and after changes)
terraform fmt                  # format the files neatly
terraform validate             # check syntax and references
terraform plan -out=tfplan     # preview the changes and save the plan
terraform apply tfplan         # make exactly the saved changes
terraform output bucket_name   # read an output
terraform destroy              # delete everything in this configuration (asks for confirmation)

The plan uses symbols: + create, ~ update in place, - destroy, and -/+ destroy and then create a replacement. It ends with a summary such as "Plan: 3 to add, 0 to change, 0 to destroy." A replacement counts as one add and one destroy. Read every -/+ carefully: replacing a database means a new, empty database unless you planned for it.

The state file

Terraform keeps a state file (terraform.tfstate), a JSON record that maps each resource in your code to the real object in the cloud, such as aws_s3_bucket.results to the bucket results-dev-123456789012. Without it Terraform would not know what it already built. The state can contain secrets in plain text, such as database passwords, so never commit it to Git.

On a team, state must be shared and locked. Shared, so everyone plans against the same truth. Locked, so two people cannot apply at the same moment and corrupt it. A common AWS setup stores state in an S3 bucket with versioning and encryption. Newer Terraform versions can lock using a lock file in the same S3 bucket (use_lockfile); older setups used a DynamoDB table for locking. Check the current backend documentation before you choose.

terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "results/dev/terraform.tfstate"
    region       = "ap-south-1"
    encrypt      = true
    use_lockfile = true   # S3-native locking in newer versions; older setups used dynamodb_table
  }
}

Modules

Once the bucket code works, wrap it in a module (a folder such as modules/results-bucket with its own variables and outputs) and call it for each use: module "results" { source = "./modules/results-bucket" env = "prod" }. The public Terraform Registry also has well-tested community modules, for example for a whole VPC. Pin module versions just like provider versions.

Terraform or CloudFormation?