What is Infrastructure as Code, and why does immutable infrastructure matter?

#Infrastructure as Code is what makes "how was this server configured?" an answerable question

Infrastructure as Code (IaC) means your servers, networks, load balancers, and DNS records are defined in version-controlled configuration files — Terraform, Pulumi, CloudFormation, Bicep — and created or changed by running that configuration through an automated tool, never by a human clicking through a cloud console or SSHing in to run a one-off command. The config file is the source of truth; the running infrastructure is just its current, disposable rendering. That single shift changes almost everything about how a team operates infrastructure.

#What you actually get from treating infra as code

• Reproducibility — standing up a second identical environment (staging that actually matches production, or disaster recovery in a new region) is running the same configuration again, not reverse-engineering what someone did by hand eighteen months ago.
• Review and audit trail — an infrastructure change goes through a pull request like application code: a diff, a reviewer, a commit history that says who changed what and why, instead of a console action logged (if you're lucky) in a CloudTrail entry nobody reads until an incident forces them to.
• Drift detection — running terraform plan shows you exactly where reality has diverged from the declared configuration, which is otherwise invisible until something breaks.
• Faster, safer disaster recovery — if a region disappears, IaC is the difference between "run apply against a new region" and "hope someone remembers the manual steps."

#A real Terraform example

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  backend "s3" {
    bucket         = "acme-terraform-state"
    key            = "prod/api/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "acme-terraform-locks"
    encrypt        = true
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_launch_template" "api" {
  name_prefix   = "api-"
  image_id      = var.api_ami_id   # a golden AMI baked by CI on every merge to main
  instance_type = "t3.medium"

  lifecycle {
    create_before_destroy = true   # never mutate a running template in place
  }
}

resource "aws_autoscaling_group" "api" {
  name                = "api-asg"
  desired_capacity    = 3
  min_size            = 2
  max_size            = 6
  vpc_zone_identifier = var.private_subnet_ids

  launch_template {
    id      = aws_launch_template.api.id
    version = "$Latest"
  }

  instance_refresh {
    strategy = "Rolling"
    preferences {
      min_healthy_percentage = 50
    }
  }

  tag {
    key                 = "Name"
    value               = "api"
    propagate_at_launch = true
  }
}

Two details here carry the whole lesson. First, backend "s3" with a dynamodb_table isn't decoration — Terraform's state file is the map of "what exists and what Terraform thinks it looks like," and if two people run apply from their own laptops with local state, they will eventually corrupt each other's changes or double-create resources. A remote backend with a lock table makes apply mutually exclusive across the whole team. Second, instance_refresh on the autoscaling group is the immutable-infrastructure pattern in one block: when api_ami_id changes, Terraform doesn't patch the running instances — it rolls out entirely new ones built from the new AMI, replacing the old ones a controlled percentage at a time, and never touches a live instance's disk.

#Mutable vs. immutable infrastructure

The old model — SSH into a running server, apt upgrade it, edit a config file by hand, restart a service — is mutable infrastructure. Every server that's been patched a slightly different number of times, by a slightly different sequence of people, slowly drifts into a "snowflake": a machine nobody can exactly reproduce, whose configuration lives partly in a config management tool, partly in someone's shell history, and partly in nobody's memory at all.

Immutable infrastructure makes a rule out of the opposite: once an instance (or a container image) is running, it is never modified. A code or config change means building a new image or AMI, and replacing the running instance wholesale rather than patching it in place. If something's wrong with a running instance, you don't debug it live — you terminate it and let the autoscaling group (or Kubernetes?) start a fresh one from the known-good image. This turns "is this server configured correctly?" from an investigation into a tautology: it's running the image, so yes, by definition.

#Why this matters beyond tidiness

Immutability isn't just aesthetic preference — it removes an entire class of production incidents that only exist because a fix was possible in place. Config drift, "it works on the box that's been up for 400 days," and manual hotfixes that never made it back into version control are all symptoms of mutable infrastructure. Immutable infrastructure forces every change through the same reviewed, versioned, reproducible path, which is exactly the same argument as CI/CD for application code, applied one layer down.