When I first joined Patterson UTI as a cloud architect, the infrastructure team was managing hundreds of EC2 instances through a mix of hand-clicked AWS Console actions and homegrown Bash scripts. Rebuilding the same stack in a disaster recovery scenario took two engineers three days. After we moved to Terraform, that rebuild became a fifteen-minute terraform apply.
That is the promise of Infrastructure as Code -- not a theoretical improvement, but a concrete operational shift that changes how your team recovers, scales, and audits.
What Terraform Is (And What It Is Not)
Terraform is an open-source Infrastructure as Code tool built by HashiCorp. You describe the infrastructure you want in HCL files, and Terraform figures out what to create, modify, or destroy to reach that desired state. It is declarative -- you describe the end state, not the steps to get there.
Terraform is not a configuration management tool. It does not install software inside your servers. That is the job of Ansible, Chef, or a user-data script. Terraform creates and wires together infrastructure components: compute instances, networks, storage buckets, IAM roles, DNS records, and more.
In 2026, the Terraform ecosystem has over 3,000 providers. For most teams starting out, AWS is the right place to begin.
Your First HCL File: The AWS Provider
Every Terraform project starts with a provider configuration:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "us-east-1"
}
Creating an S3 Bucket
resource "aws_s3_bucket" "my_bucket" {
bucket = "my-terraform-demo-bucket-2026"
tags = {
Environment = "dev"
ManagedBy = "terraform"
}
}
Run these three commands:
terraform init # Download the AWS provider
terraform plan # Preview what Terraform will create
terraform apply # Create the resources
terraform plan shows you exactly what will happen before anything changes. This is Terraform's superpower: infrastructure changes are reviewed before they execute, just like code changes are reviewed before they merge.
State: Terraform's Memory
Terraform stores the current state of your infrastructure in a state file (terraform.tfstate). This file maps your HCL configuration to real AWS resources. Without it, Terraform cannot know what already exists.
Critical rule: never edit the state file manually. Never commit it to Git without encryption. In production, store state remotely in S3 with DynamoDB locking:
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
Variables and Outputs
Hardcoded values make Terraform code brittle. Use variables:
variable "environment" {
description = "Deployment environment"
type = string
default = "dev"
}
variable "instance_type" {
description = "EC2 instance type"
type = string
default = "t3.micro"
}
Outputs let you extract values from your infrastructure:
output "bucket_arn" {
value = aws_s3_bucket.my_bucket.arn
}
Originally published at Citadel Cloud Management. 17 free cloud courses available -- no credit card required.