What Is Infrastructure as Code?

Every AWS service this course has covered so far could be created by clicking through the Console — and for exploring a new service or learning a concept, that's a perfectly reasonable way to work. The trouble shows up at a different point: once an environment needs to be reproduced — a second environment for testing, a disaster-recovery rebuild, or simply remembering exactly what was configured six months ago — manual, one-off Console actions become genuinely hard to reproduce exactly, hard to review before they happen, and easy to leave undocumented. Two environments built "the same way" by hand often end up subtly different without anyone intending it.

Infrastructure as Code (IaC) means defining infrastructure in a template — a file describing what AWS resources should exist and how they should be configured — instead of performing the equivalent actions by hand in the Console. That template can be version-controlled, reviewed before it's applied, and reused to create the same infrastructure again, consistently.

This is worth stating directly, because the benefits of IaC can make it feel like a complete solution on its own: a template can be reviewed, version-controlled, and repeatable, and still describe genuinely bad infrastructure. A template with an overly broad IAM policy deploys that overly broad policy every single time, consistently. A template that provisions far more capacity than a workload needs does so repeatably, not just once. Infrastructure as Code is a discipline for how infrastructure gets defined and changed — it doesn't replace the architectural, security, and cost judgment this course has spent ten modules building.

This course's central Infrastructure as Code service, covered starting next lesson, is built around a declarative model: a template describes what infrastructure should exist — an S3 bucket, a queue, an IAM role — rather than scripting the exact low-level sequence of API calls needed to create them. The deployment engine itself works out an appropriate process for creating or updating those resources, based on their dependencies and how each service actually behaves. This lesson doesn't assume that process always happens in one single fixed order — the next few lessons build up exactly how that determination gets made.