Infrastructure as Code (IaC)

Infrastructure as Code (IaC) is the practice of defining and managing cloud infrastructure — servers, networks, databases, load balancers, permissions — through machine-readable configuration files stored in version control, rather than manually clicking through a cloud provider's web console to create and configure resources by hand. Tools include Terraform (cloud-agnostic, the most widely adopted), AWS CloudFormation and CDK (AWS-specific), and Pulumi (IaC using general-purpose programming languages instead of a dedicated config format). Why it matters for AI/SaaS builders: manually configured infrastructure ("ClickOps") is fragile and unrepeatable — nobody can reliably remember or document every click that produced a working production environment, which makes disaster recovery, environment parity (staging matching production), and onboarding new team members painfully slow and error-prone. IaC solves this the same way version control solves it for application code: infrastructure changes go through a reviewable diff, a change history, and the same environment can be reliably recreated from scratch — critical for setting up a genuinely identical staging environment, or recovering quickly from a catastrophic failure in a cloud region. How it works: infrastructure is described declaratively in configuration files (Terraform's HCL, for example) — "I want an S3 bucket named X with these permissions, a Postgres RDS instance with this size, and a security group allowing traffic on port 443" — and a planning step compares this desired state against the infrastructure's actual current state, producing a diff of what will be created, changed, or destroyed. A human (or an automated pipeline) reviews and approves that plan before it's applied, at which point the tool calls the cloud provider's APIs to make reality match the declared configuration. Worked example: a SaaS team needs to spin up a new staging environment identical to production for testing a major release. Because their entire infrastructure is defined in Terraform — the VPC, the database instance size and configuration, the load balancer rules, the IAM permissions — they run `terraform plan -var environment=staging` to preview exactly what will be created, review the plan (47 resources to create), and run `terraform apply` to provision the entire environment from scratch in about ten minutes, guaranteed to match production's configuration exactly because it's generated from the identical codebase, just with a different variable set — versus days of manual, error-prone reconstruction if the environment had been built by hand originally. Because the entire configuration lives in version control alongside the application code, any accidental drift between staging and production — someone manually tweaking a security group setting through the console, for instance — shows up clearly as an unexpected diff the next time `terraform plan` runs, rather than silently causing a "works in staging, breaks in production" surprise.