Infrastructure as Code (IaC): Definition, Tools, Examples

What is Infrastructure as Code (IaC)?

Infrastructure as Code (IaC) is the practice of describing infrastructure such as servers, networks, databases, DNS records and access policies in code files, and creating or changing it by running a tool instead of clicking through a console. The files live in version control, are reviewed like application code, and are applied from a pipeline, usually as part of continuous delivery.

How IaC works

1. You write the desired infrastructure in a template or program and commit it to a repository.
2. The tool compares the code with what exists. Terraform calls this step plan; AWS CloudFormation shows it as a change set.
3. After review, the tool creates, updates or deletes resources through the provider's API.
4. The tool records what it manages, so the next run knows what to change. Terraform keeps this in a state file.

AWS describes CloudFormation in the same terms: a template lists the resources you want, and because templates are text files you can track changes the way developers track source code, and reuse a template to build the same resources in several regions.

Declarative and imperative IaC

Declarative tools such as Terraform and CloudFormation describe the end state and work out the steps. Imperative or general-purpose-language tools such as Pulumi let you write the infrastructure in a programming language; Pulumi lists TypeScript, Python, Go, .NET, Java and YAML. Declarative code is easier to review for a plan; a real language helps when you need loops, conditions or shared libraries. Most teams pick one style and stay with it.

Common tools

• Terraform by HashiCorp uses its own language, HCL, and works across many providers. On 10 August 2023 HashiCorp announced a move from the MPL 2.0 licence to the Business Source License for future releases of its products.
• OpenTofu is a Terraform fork started in response to that change by Gruntwork, Spacelift, Harness, Env0, Scalr and others, now under the Linux Foundation, per its FAQ.
• AWS CloudFormation is AWS's own service. Templates are written in JSON or YAML and deployed as stacks.
• Pulumi uses general-purpose languages and organises work into stacks, for example one per environment.

If licensing matters to you, read the current terms of whichever tool you adopt; they have changed before.

Example

This Terraform file declares an S3 bucket. Running plan shows that one resource will be created; apply creates it. Run it again and nothing changes, because the bucket already matches the code.

# main.tf
provider "aws" {
  region = "eu-west-1"
}

resource "aws_s3_bucket" "website" {
  bucket = "my-marketing-site"
  tags = {
    Environment = "production"
  }
}

terraform init
terraform plan   # preview the changes
terraform apply  # make them

Why teams use IaC

• Repeatable environments. Dev, staging and production come from the same code.
• Reviewable changes. A pull request shows what will change before it does.
• Audit trail. Version history records who changed what and when.
• Faster recovery. A lost environment can be rebuilt from code, though data still needs its own backups.

Common mistakes

• Manual console changes. They cause drift: reality no longer matches the code, and the next plan tries to undo them.
• State kept in git. State can contain secrets. Use a remote backend. For Terraform on S3, locking is opt-in via use_lockfile, and the docs say DynamoDB-based locking is deprecated.
• One state file for everything. A single mistake then affects every environment. Split by environment and by system.
• Applying without reading the plan. Pay particular attention to anything marked for destroy or replacement.
• Secrets in code. Reference a secrets manager instead.
• Unpinned versions. Pin tool and provider versions so a new release does not change a plan.

IaC, testing and monitoring

IaC makes a change easy, not safe. A new instance type, a changed scaling rule or an extra region can alter how the service behaves under traffic, so run a load test against the new environment before relying on it; the guide to validating infrastructure auto-scaling shows the idea, and CI/CD best practices covers where such checks sit in a pipeline. After release, infrastructure monitoring and synthetic monitoring show whether it keeps working.

LoadFocus does not provision infrastructure. Its monitoring as code page describes keeping monitors in Git as YAML or typed JavaScript and deploying them with the @loadfocus/monitoring command-line tool from CI. That page lists API, browser, multistep, TCP and heartbeat checks, plus alert channels, maintenance windows and status pages as resources you can manage this way.

FAQ: Infrastructure as Code

What is the difference between IaC and configuration management?

IaC provisions infrastructure such as networks, databases and servers. Configuration management tools such as Ansible set up the software inside machines that already exist. The boundary is blurry and some tools do both.

Terraform, OpenTofu or CloudFormation?

CloudFormation fits teams that use only AWS and want a managed service. Terraform and OpenTofu suit teams that work across several providers. Check the licence terms before choosing between the last two.

What is drift?

Drift is when real infrastructure differs from what the code declares, usually after a manual change. Run a plan regularly to detect it, then either update the code or revert the resource.

Where should I store Terraform state?

In a remote backend with locking, such as an S3 bucket with use_lockfile enabled, rather than in git or on a laptop.

Can I use IaC for Kubernetes?

Yes. Kubernetes is already declarative, so manifests are a form of IaC, and tools such as Terraform or Pulumi can manage the clusters and the cloud resources around them.