What is Terraform? Infrastructure as Code Explained
Every cloud resource you create manually through a web console carries hidden risk: it is undocumented, unrepeatable, and impossible to review in a pull request. Terraform eliminates that risk by letting you describe your infrastructure as code -- files that live in Git, go through code review, and can be applied identically to development, staging, and production environments.
Terraform was created by HashiCorp and open-sourced in 2014. In 2023, HashiCorp changed the license to BSL 1.1, which prompted the community to fork it as OpenTofu -- an open-source drop-in replacement maintained by the Linux Foundation. The two are still largely compatible, and most of what you learn applies to both.
How Terraform Works
Terraform follows a declarative model. You write HCL (HashiCorp Configuration Language) files describing the desired end state, not the steps to get there. Terraform's job is to calculate the difference between what exists and what you want, then make the minimum changes needed.
The workflow has three commands:
# See what Terraform would change without touching anything
terraform plan
# Apply the changes shown in the plan
terraform apply
# Tear everything down
terraform destroy
A Real Example: AWS S3 Bucket with Versioning
provider "aws" {
region = "us-east-1"
}
resource "aws_s3_bucket" "app_assets" {
bucket = "mycompany-app-assets-prod"
tags = {
Environment = "production"
Team = "platform"
}
}
resource "aws_s3_bucket_versioning" "app_assets" {
bucket = aws_s3_bucket.app_assets.id
versioning_configuration {
status = "Enabled"
}
}
Notice that aws_s3_bucket_versioning references aws_s3_bucket.app_assets.id -- Terraform automatically determines the order of operations from these dependency references. You do not write "create the bucket first, then enable versioning." Terraform infers it.
State: The Heart of Terraform
Terraform maintains a state file (terraform.tfstate) that maps your HCL configuration to the real-world resources it manages. This is how Terraform knows what already exists. Without state, it cannot calculate diffs.
For any serious use, store state remotely -- not on a developer's laptop. The standard approach is an S3 bucket with a DynamoDB table for state locking:
terraform {
backend "s3" {
bucket = "mycompany-terraform-state"
key = "prod/main.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-state-lock"
encrypt = true
}
}
State locking via DynamoDB prevents two engineers from running terraform apply at the same time and corrupting the state file.
Modules
As your infrastructure grows, raw HCL files become repetitive. Modules let you create reusable components. A module is simply a directory of .tf files that accepts input variables and produces output values. HashiCorp's public registry has modules for common patterns: VPCs, EKS clusters, RDS instances.
module "vpc" {
source = "terraform-aws-modules/vpc/aws"
version = "5.1.2"
name = "production"
cidr = "10.0.0.0/16"
azs = ["us-east-1a", "us-east-1b", "us-east-1c"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
public_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
enable_nat_gateway = true
}
Using community modules for well-solved problems (VPCs, EKS clusters) and writing your own for company-specific patterns is the right balance.
Terraform in a DevOps Workflow
Terraform fits naturally into a CI/CD guide pipeline. The common pattern: terraform plan runs on pull requests (output posted as a comment for review), and terraform apply runs automatically when a PR merges to the main branch. Tools like Atlantis and Terraform Cloud provide this workflow out of the box.
Terraform provisions the infrastructure that your Docker containers and Kubernetes clusters run on. It is one layer below the application -- the foundation everything else depends on.
Understanding infrastructure as code principles is a prerequisite to using Terraform well. The DevOps tools guide covers how Terraform fits alongside configuration management tools like Ansible.