All Articles

What is Infrastructure as Code? Explained Simply (2026)

Infrastructure as Code (IaC) explained in plain English — what it is, why every DevOps team uses it, and how to get started with Terraform and Pulumi in 2026.

DevOpsBoysMar 31, 20265 min read
Share:Tweet

If you've heard "Infrastructure as Code" but still picture someone typing terraform apply and hoping for the best — this post will clear that up.

IaC is one of those concepts that sounds complicated but is actually a very logical idea. Let's break it down.


The Problem IaC Solves

Before IaC, setting up infrastructure worked like this:

  1. Someone logs into the AWS console
  2. Clicks around to create a VPC, subnets, security groups, EC2 instances
  3. Writes down what they did (maybe)
  4. Next month, someone else does it slightly differently
  5. Production and staging are now different in ways nobody can explain
  6. Something breaks. Nobody knows why.

This is ClickOps. It works for one person, once. It doesn't scale.

With IaC:

hcl
# This file IS your infrastructure
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
 
  tags = {
    Name = "production-vpc"
  }
}
 
resource "aws_subnet" "public" {
  vpc_id     = aws_vpc.main.id
  cidr_block = "10.0.1.0/24"
}

Run terraform apply. The VPC exists. Run it again on a new account — identical VPC. Everyone on the team sees exactly what the infrastructure looks like. Git history shows who changed what and why.

That's Infrastructure as Code.


What "Code" Actually Means Here

When we say infrastructure "as code," we mean:

  • Version controlled: Your infrastructure lives in Git, just like your application code
  • Reviewable: Changes go through pull requests — team can catch mistakes before they hit production
  • Repeatable: Run the same IaC file 100 times, you get the same infrastructure
  • Auditable: Git log shows every change, who made it, and when
  • Automated: CI/CD can apply infrastructure changes automatically

The infrastructure isn't a collection of console clicks that exist in someone's memory. It's a file that can be read, reviewed, tested, and automated.


The Main IaC Tools in 2026

Terraform (HashiCorp)

The most popular IaC tool. Uses HCL (HashiCorp Configuration Language).

hcl
provider "aws" {
  region = "us-east-1"
}
 
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"
 
  tags = {
    Name = "web-server"
  }
}

Best for: Teams that manage multi-cloud infrastructure. Huge ecosystem of providers (AWS, GCP, Azure, Kubernetes, GitHub, Datadog — everything).

OpenTofu

The open-source fork of Terraform (after HashiCorp changed the license in 2023). Drop-in compatible — same HCL syntax.

Best for: Teams that don't want to depend on a commercial vendor.

Pulumi

Uses real programming languages (Python, TypeScript, Go) instead of a custom DSL.

typescript
import * as aws from "@pulumi/aws";
 
const vpc = new aws.ec2.Vpc("main", {
    cidrBlock: "10.0.0.0/16",
});
 
const subnet = new aws.ec2.Subnet("public", {
    vpcId: vpc.id,
    cidrBlock: "10.0.1.0/24",
});

Best for: Developers who prefer real code over HCL. Better for complex logic.

Ansible

More of a configuration management tool, but can provision infrastructure too. Uses YAML.

Best for: Configuring servers after they're created (install packages, manage files, run commands).

AWS CloudFormation / CDK

AWS-specific. CloudFormation uses JSON/YAML, CDK uses TypeScript/Python/Java.

Best for: Teams fully in AWS who don't need multi-cloud.


How IaC Works Step by Step

Using Terraform as an example:

1. Write the configuration

hcl
# main.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}
 
provider "aws" {
  region = "us-east-1"
}
 
resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-app-storage-2026"
}

2. Initialize

bash
terraform init
# Downloads the AWS provider plugin
# Initializes the backend (where state is stored)

3. Plan — see what will change

bash
terraform plan
 
# Plan: 1 to add, 0 to change, 0 to destroy.
# + aws_s3_bucket.my_bucket will be created

4. Apply — make it real

bash
terraform apply
# Terraform will create the S3 bucket

5. Destroy when done

bash
terraform destroy
# Removes everything Terraform created

State: The Key Concept

Terraform maintains a state file that maps your config to real infrastructure. This is how it knows what exists, what changed, and what to create/destroy.

json
// terraform.tfstate (simplified)
{
  "resources": [
    {
      "type": "aws_s3_bucket",
      "name": "my_bucket",
      "instances": [
        {
          "id": "my-app-storage-2026",
          "arn": "arn:aws:s3:::my-app-storage-2026"
        }
      ]
    }
  ]
}

In teams, always use remote state (S3 + DynamoDB for AWS, or Terraform Cloud):

hcl
terraform {
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-lock"
  }
}

This prevents two people from running terraform apply at the same time and corrupting state.


IaC Best Practices

Use modules to avoid repetition:

hcl
module "vpc" {
  source = "./modules/vpc"
 
  cidr_block   = "10.0.0.0/16"
  environment  = "production"
}

Store secrets in environment variables or secrets manager, never in code:

bash
# Wrong — never do this
resource "aws_db_instance" "main" {
  password = "my-secret-password-123"  # BAD
}
 
# Right
resource "aws_db_instance" "main" {
  password = var.db_password  # Passed via env var or secrets manager
}

Always use terraform plan before terraform apply — especially in production. Review what will be destroyed.

Run IaC through CI/CD:

yaml
# GitHub Actions
- name: Terraform Plan
  run: terraform plan -out=tfplan
 
- name: Terraform Apply
  run: terraform apply tfplan
  if: github.ref == 'refs/heads/main'

Learning Resources

IaC is one of the most in-demand DevOps skills in 2026. Worth investing time here:


Infrastructure as Code isn't just a fancy term. It's the difference between "nobody knows what's in production" and "the infrastructure is a PR away from being reviewed and deployed."

Once you write your first Terraform module, you'll never want to click through the console again.

Newsletter

Stay ahead of the curve

Get the latest DevOps, Kubernetes, AWS, and AI/ML guides delivered straight to your inbox. No spam — just practical engineering content.

Related Articles

Comments