Infrastructure as Code
Also called: IaC
Defining servers, networks and databases in version-controlled files instead of clicking through a cloud console, so environments can be reproduced exactly.
What is Infrastructure as Code?
Infrastructure as Code (IaC) is the practice of managing cloud infrastructure—servers, networks, databases, firewalls, DNS, permissions, and more—through code stored in version control rather than through manual console clicks. Infrastructure definitions live in files (using tools like Terraform, CloudFormation, or Pulumi), are reviewed in pull requests, and are applied consistently across environments. This moves infrastructure from a manual, undocumented process into the same change-management workflow as application code.
How Infrastructure as Code Works
Define infrastructure. Write your servers, networks, databases, permissions, DNS, and policies as code in declarative files — typically HCL (Terraform), YAML (CloudFormation, Bicep), or your preferred programming language (Pulumi).
Store in version control. Commit infrastructure definitions to Git. Every change has history, authorship, and a commit message.
Review and approve. Infrastructure changes go through pull request review just like code. A network rule, firewall policy, or database schema change is seen by a second person before it hits production.
Apply through tooling. The IaC tool reads the state you declared and reconciles it with what exists. It plans the changes, shows you what will happen, and applies them consistently.
Detect and manage drift. Run a diff command to see if reality matches your code. If someone made a manual change in the console, drift detection surfaces it so you can codify or revert it.
Why it matters more than it sounds
Reproducibility. You can recreate the environment exactly. This is what makes a disaster recovery plan credible rather than aspirational.
Review. Infrastructure changes go through pull request review like any other change, so a network rule that opens something to the internet gets seen by a second person.
Documentation that is true. The code is the current state. Architecture diagrams drift within months; the code cannot.
Rollback. A bad change is reverted by reverting a commit.
The trap
Partial adoption. If half the estate is in code and half was created by hand, you have the overhead of both and the confidence of neither — and the hand-made half is invariably the part that breaks under pressure.
The fix is not a rebuild. Existing resources can be imported into code incrementally, which is how we normally take over an estate.
Drift
Someone will eventually change something in a console at 2am during an incident. That is fine and often correct. What matters is that the drift is detected afterwards and either codified or reverted, rather than quietly becoming permanent undocumented state.
Infrastructure as Code vs Manual Infrastructure
| Aspect | Manual | Infrastructure as Code |
|---|---|---|
| Changes | Made in console | Versioned in Git |
| Reproducibility | Hard to recreate exactly | Fully reproducible |
| Review process | Difficult to audit | Pull-request review |
| Drift detection | Manual checking | Automatic diff commands |
| Recovery | Manual restoration | Recreate from code |
| Knowledge | Lives in one person's head | Documented in files |
| Scaling | Error-prone repetition | Consistent across environments |
Popular IaC Tools
Infrastructure as Code is implemented by several tools. The choice depends on your cloud strategy and team preferences.
Terraform (cloud-agnostic, HCL) — A widely adopted, cloud-agnostic IaC tool. Supports AWS, Azure, GCP, and hundreds of other providers. Best for multi-cloud infrastructure and when you need fine-grained control.
OpenTofu (cloud-agnostic, HCL) — Open-source fork of Terraform with the same syntax. Exists because Terraform moved to a source-available license. Interchangeable with Terraform for most use cases.
Pulumi (Python, Go, TypeScript, C#) — Modern alternative that lets you write infrastructure in familiar programming languages instead of a domain-specific syntax. Useful if your team is already polyglot.
AWS CloudFormation (AWS-native, JSON/YAML) — Built into AWS. Simpler onboarding if you're AWS-only, but less portable to other clouds.
Azure Bicep (Azure-native, Bicep) — Azure's modern IaC tool. Cleaner syntax than ARM templates. Good choice if Azure is your primary cloud.
Choice depends on: Are you multi-cloud (Terraform or OpenTofu) or single-cloud (CloudFormation or Bicep)? Do you want to code in a familiar language (Pulumi) or learn domain-specific syntax (Terraform)? Most teams reach for Terraform first unless they are AWS-only or Azure-only.
Infrastructure as Code for AI Infrastructure
Infrastructure as Code is especially valuable for AI applications. The infrastructure for ML systems is complex, resource-intensive, and needs to be reproducible across teams and multiple deployments. IaC lets you:
- Provision GPU resources — Allocate compute capacity for model training and serving consistently across environments.
- Orchestrate with Kubernetes — Define clusters and networking for containerized AI workloads with repeatable RBAC policies and resource constraints.
- Build model serving infrastructure — Configure load balancers, autoscaling policies, and monitoring for inference endpoints.
- Define data pipelines — Version storage architecture, ETL orchestration, feature stores, and data lakes.
- Standardize observability — Provision logging, metrics, tracing, and alerting infrastructure for production AI systems.
Using IaC for AI infrastructure means your experiments are reproducible, your team can spin up training environments on demand, and your model serving infrastructure is versioned and auditable. This is especially important for regulated industries and multi-team deployments.
The Adoption Path
You don't need to infrastructure-from-scratch. Start by importing existing resources into code—cloud providers provide tools to reverse-engineer your current setup into Terraform or CloudFormation definitions. From there, all new infrastructure goes through code, and old resources migrate over time. This eliminates the false choice between "rebuilt or never versioned."
The key discipline: once something is codified, don't change it in the console. If you must (incident at 2am), drift detection catches it, and you codify or revert afterwards. This keeps your source of truth aligned with reality.