Infrastructure as Code

Before IaC, you provisioned infrastructure by logging into a cloud console and clicking buttons, or by SSHing into a server and running setup commands. That works once. The problem is repeating it. Six months later nobody remembers the exact 40 steps, the staging environment drifts away from production, and rebuilding after an outage takes a frantic afternoon of guessing.

IaC fixes this by putting the whole environment in text files that live in Git next to your application code. A file might say: one VPC, three subnets, an autoscaling group of five t3.medium instances, a Postgres database with 100 GB of storage, and a load balancer in front. You commit it, review it like any other code, and a tool turns it into reality.

Most modern IaC is declarative. You describe the end state you want, not the steps to get there. The tool figures out the difference between what exists and what you asked for, then makes only the changes needed. This is different from a shell script, which runs the same commands every time whether or not they are needed.

A declarative tool keeps a record of what it believes already exists, called state. Terraform stores this in a terraform.tfstate file, usually kept in an S3 bucket or Terraform Cloud rather than on a laptop. When you run a plan, the tool compares three things: the desired state in your files, the recorded state, and the live state queried from the cloud API.

From that comparison it builds an execution plan: create these two resources, modify that one, delete this orphan. You review the plan, approve it, and the tool calls the provider APIs (AWS, GCP, Azure, Cloudflare, and so on) in dependency order. It knows the database must exist before the app that connects to it, so it builds a graph and walks it.

Idempotency is the key property. Running apply twice with no file changes produces zero changes the second time, because the live state already matches. This is what makes IaC safe to run repeatedly and safe to automate inside a CI/CD pipeline.

Pulumi works the same way but lets you write the definitions in TypeScript, Python, Go, or C# instead of a custom language, so you get loops, functions, and real package management. CloudFormation and Azure Bicep are the cloud-vendor-native equivalents, scoped to one provider.

Use IaC the moment you have more than one environment, more than one engineer, or anything you would hate to rebuild from memory. It gives you repeatable environments, code review on infrastructure changes, a Git history of who changed what, and disaster recovery that is a single apply away. Spinning up an identical staging copy becomes a one-line change instead of a day of clicking.

The costs are real. There is a learning curve, the state file becomes a critical artifact you must back up and lock so two people do not apply at once, and a careless plan can propose deleting your production database. Always read the plan before approving. Drift is the other trap: if someone makes a manual change in the console, the live state no longer matches your files, and the next apply may revert it.

IaC handles provisioning, which is creating the infrastructure. It is usually paired with configuration management tools like Ansible or with container orchestration like Kubernetes, which handle what runs inside the machines once they exist. The common pattern is Terraform to build the cluster, then Helm or Kubernetes manifests to deploy apps onto it.

Say a team launches a new region for their product. With IaC, they copy the existing region module, change a few variables (region name, CIDR block, instance count), and run terraform plan. The plan shows 60 resources to add. They review it, run apply, and 8 minutes later the new region has the same network layout, the same security groups, the same database configuration, and the same monitoring as the original. No step was forgotten because every step lives in the file.

Six months on, an engineer needs to bump every web server from 5 instances to 8 and add a read replica to the database. That is a three-line diff in a pull request. A teammate reviews it, CI runs the plan automatically and posts it as a comment, and after approval the pipeline applies it. The change is documented, reversible, and applied identically across every environment that uses the module.