IaC Fundamentals

Infrastructure as Code (IaC) manages infrastructure through machine-readable configuration files instead of manual processes.

Declarative describes the desired end state. You say what you want, and the tool figures out how to get there. If the resource exists with different properties, the tool updates it. If it does not exist, the tool creates it. Declarative tools are idempotent by nature.

Imperative describes the steps to reach the desired state. You write explicit commands that create, modify, or delete resources. Imperative gives you full control over sequencing but requires handling every edge case. Most modern IaC tools are declarative with imperative extensions.

Real-world example: Provisioning a VPC. Declarative IaC defines the VPC, subnets, route tables, and internet gateway in a single template. The tool compares current state with desired state and makes minimal changes. Manual provisioning requires clicking through the console for each resource, which is error-prone and not repeatable.

Idempotency means applying the same configuration multiple times produces the same result. If you run your IaC tool twice with the same template, the infrastructure should not change on the second run.

This is critical for reliability. Without idempotency, you cannot safely re-run deployments after failures, and you cannot use CI/CD pipelines that might retry.

Drift detection identifies when actual infrastructure has diverged from the declared configuration. Drift happens when someone manually changes resources via the console or CLI outside of IaC.

Drift is dangerous because your IaC no longer reflects reality. A deployment might overwrite manual changes, or a destroy might remove resources someone depends on. Regular drift detection catches these issues early.

Best practice: Never make manual changes to production infrastructure. All changes go through IaC with peer review and CI/CD.

IaC transforms infrastructure from a manual, undocumented process into a disciplined engineering practice.

Version control: Infrastructure templates live in Git alongside application code. Every change is committed, reviewed, and auditable. You can see who changed what, when, and why. You can revert to a previous state by checking out an older commit.

Reproducibility: Deploy identical infrastructure across environments with parameterized templates. Eliminate configuration drift between dev, staging, and prod.

Peer review: Infrastructure changes go through pull requests. Team members review templates for security, cost, and correctness before deployment. This catches issues like overly permissive security groups before they reach production.

Documentation: The template is the documentation. Reading a CloudFormation or Terraform template tells you exactly what resources exist, their configuration, and how they relate.

Disaster recovery: If an environment is destroyed, re-running the IaC pipeline recreates it exactly. This is impossible with manual provisioning unless you have detailed runbooks.

AWS provides multiple IaC tools, each with different strengths.

CloudFormation: AWS-native, declarative JSON/YAML templates. Deep integration with AWS services. Uses Change Sets for preview and Stack Sets for multi-account deployments. Best when infrastructure is purely AWS.

Terraform: Cloud-agnostic, HCL syntax. Supports AWS, Azure, GCP, and hundreds of providers. Module ecosystem for reusable components. State management with backends. Best for multi-cloud or when you need the module ecosystem.

AWS CDK: Write infrastructure in TypeScript, Python, Java, or Go. Generates CloudFormation templates. Best for developers who prefer programming over YAML.

Pulumi: Like CDK but cloud-agnostic. Write in TypeScript, Python, Go, or C#. Uses real programming languages for loops, conditions, and abstractions.

When to use what: Pure AWS with YAML familiarity goes to CloudFormation. Multi-cloud or module ecosystem goes to Terraform. Developers preferring code over config goes to CDK or Pulumi.