Every company has one: the server nobody wants to touch. It was set up years ago by clicking through the AWS console. It has a security group with rules nobody can explain, a cron job someone added over SSH, and a disk that was resized "temporarily". It works. Nobody knows exactly why.

Now imagine it disappears tomorrow. Could you rebuild it, exactly, from memory?

Infrastructure as Code (IaC) exists so the answer is "yes, in one command". Here's how it works, set out as the questions people actually ask when they first meet it.

So what is it, in one sentence?

You describe your infrastructure (servers, networks, databases, buckets, DNS records, permissions) in text files, keep them in Git, and a tool makes the real cloud match the files.

The key word is describe. Most IaC tools are declarative: you write what should exist, not the steps to create it. That's the big difference from a folder of Bash scripts. A script says "create a bucket", and fails or duplicates on the second run. A declaration says "there is a bucket with versioning on", and running it twice changes nothing the second time.

What does it look like?

Here's a small piece of Terraform, the most widely used multi-cloud IaC tool. It describes an S3 bucket for uploads with versioning enabled:

resource "aws_s3_bucket" "uploads" {
  bucket = "example-app-uploads"

  tags = {
    Environment = "production"
  }
}

resource "aws_s3_bucket_versioning" "uploads" {
  bucket = aws_s3_bucket.uploads.id

  versioning_configuration {
    status = "Enabled"
  }
}

Notice aws_s3_bucket.uploads.id. Resources can reference each other, so Terraform works out the order: the bucket first, then its versioning setting. You never write that order down.

What happens when I run it?

Three commands carry most of the workflow:

1. terraform init downloads the providers (the plugins that talk to AWS, Cloudflare and so on).
2. terraform plan compares your files with reality and prints what it would do.
3. terraform apply does it, after showing the plan again and asking you to confirm.

The plan is the best part. It reads like a diff for your infrastructure:

  # aws_s3_bucket_versioning.uploads will be created
  + resource "aws_s3_bucket_versioning" "uploads" {
      + bucket = "example-app-uploads"
      ...
    }

Plan: 1 to add, 0 to change, 0 to destroy.

In a good setup, that plan is posted on the pull request. A teammate reviews the infrastructure change the same way they review code, before anything touches production.

What is "state", and why does everyone warn me about it?

Terraform needs to remember which real thing belongs to which block in your files: "this resource is bucket example-app-uploads, this one is instance i-0abc...". That mapping is the state file.

Three rules keep state from hurting you:

• Store it remotely, not on someone's laptop. An S3 bucket backend is the common choice on AWS.
• Turn on locking, so two people can't apply at the same time and corrupt it.
• Treat it as sensitive. State can contain values like database passwords in plain text. Encrypt it and restrict who can read it.

terraform {
  backend "s3" {
    bucket  = "example-terraform-state"
    key     = "production/terraform.tfstate"
    region  = "eu-west-1"
    encrypt = true
  }
}

AWS CloudFormation, by contrast, keeps the state for you inside AWS (as a "stack"). That's one less thing to manage, at the cost of only working with AWS.

What is drift?

Drift is when reality and your files disagree. Somebody opens a port in the console during an incident "just for now". Someone resizes a database by hand. The code says one thing, the cloud says another.

The next terraform plan will show the difference and offer to put it back. That's either a safety net or a surprise outage, depending on whether the manual change was important. CloudFormation has a drift detection feature for the same reason.

Terraform, CloudFormation, or something else?

My take: if you're all-in on AWS and want the least to manage, CloudFormation or CDK is reasonable. If you use more than one provider (say AWS plus a DNS or CDN provider), Terraform or OpenTofu lets you describe all of it in one place. The concepts transfer either way.

Isn't this overkill for a small team?

Not if you start small. You don't have to codify everything on day one. Start with what would hurt most to rebuild by hand: networking and security groups, the database, the buckets, DNS. Even a few hundred lines that describe your production environment are worth it, because they double as documentation that can't go out of date.

And it's not the same thing as Docker. A Dockerfile describes what's inside the box; IaC describes the boxes, the network between them and who's allowed in.

The traps that bite

• Not reading the plan. Changing some attributes forces Terraform to destroy and recreate a resource. The plan says so (-/+, "must be replaced"). On a database, that line deserves your full attention.
• No guard on precious resources. Add lifecycle { prevent_destroy = true } to the things that must never be deleted by accident.
• Secrets in the repo. Pass them in from a secrets manager or environment variables, never hard-code them in .tf files.
• One giant state for everything. Split by environment and by area, so a mistake in staging can't touch production.

The short version

IaC turns infrastructure into something you can review, repeat and rebuild. Files in Git, a plan before every change, state stored safely, and no clicking in the console.

What's the one piece of your infrastructure you'd be most nervous to rebuild from memory?