Terraform Immutability: When Changes Are Safe — and When They Aren’t

1. What Is Immutable Infrastructure?

Immutable Infrastructure is an approach where infrastructure components are never modified after they are created.

Instead of changing a running server or resource:

• You create a new version
• Deploy it
• Replace the old one

Core principle

Build → Deploy → Replace Never SSH → Patch → Fix

Traditional (Mutable) Infrastructure

In a mutable model:

• Servers are manually updated
• Configurations drift over time
• Rollbacks are difficult
• Debugging becomes unpredictable

This often results in:

• “Snowflake” servers
• Hidden changes
• Security risks
• Poor auditability

Immutable Infrastructure Model

In an immutable model:

• All changes are defined in code
• Infrastructure is replaced, not patched
• Rollback means reverting to a previous version
• No manual changes are allowed

This model is the foundation of:

• Containers
• Kubernetes
• Infrastructure as Code (IaC)

2. Why Immutable Infrastructure Matters

Immutable infrastructure provides:

• Predictability — same code produces the same environment
• Security — no manual access or hotfixes
• Auditability — every change is versioned in Git
• Easy rollback — revert to a known good state
• Scalability — works naturally with autoscaling systems

3. Immutable Infrastructure in Terraform

Terraform implements immutability at the infrastructure level.

Terraform does not “fix” running infrastructure manually. It compares:

• Desired state (code)
• Current state (Terraform state)

Then it decides how to apply the change.

4. Terraform Change Types: The Core Concept

Terraform changes fall into two categories:

4.1 In-Place Modify (Safe Update)

Terraform updates the existing resource without deleting it.

• Resource ID stays the same
• No data loss
• Uses cloud provider “modify” APIs

Terraform plan shows:

~ update in-place

Examples (AWS RDS)

• Change instance class
• Increase storage size
• Enable Multi-AZ
• Change backup retention
• Update parameter group
• Enable performance insights

These changes are safe and supported by AWS.

4.2 FORCE Replacement (Destroy & Recreate)

Terraform must destroy and create a new resource.

• Resource ID changes
• Data loss risk (for stateful resources)
• Happens only when the provider does not support in-place updates

Terraform plan shows:

-/+ replace

Examples (AWS RDS)

• Change database engine (Postgres → MySQL)
• Change DB identifier
• Change subnet group
• Some encryption or KMS changes
• Some major engine version changes

Terraform will always show this clearly in the plan before applying.

5. Important Clarification: Terraform Is Selectively Immutable

Terraform is not blindly destructive.

• Stateless resources (compute, ASG, nodes): mostly replace
• Stateful services (RDS, storage): updated in place when possible

This balance exists by design to protect data and availability.

6. Protecting Critical Resources (Best Practice)

For production databases and critical services, you should explicitly prevent destruction.

Recommended Terraform configuration

lifecycle {
  prevent_destroy = true
}

This ensures:

• Any forced replacement will fail the apply
• Human review is required
• Accidental data loss is prevented

This is considered a production-grade Terraform control.