What it is
AWS CloudFormation describes infrastructure as code. You write a template, in YAML or JSON, listing the resources you want and how they connect: functions, tables, roles, alarms. CloudFormation creates them together as one stack, works out the order they must be built in, and on the next deploy changes only what changed in the file.
If an update fails, the stack rolls back to the last good state. Parameters let one template serve different settings, outputs pass values like URLs to scripts, and change sets show what a deploy will do before it does it. Deleting the stack removes everything it created, so nothing is left running by accident.
How I use it
- The dynamic half of mervinc.com is one template, deployed by one script, which also wires the API routes into CloudFront.
- It defines the DynamoDB table, the Lambda functions and their URLs, one least-privilege IAM role per function, and the origin access control.
- It also holds the CloudWatch alarms, the Bedrock guardrail, the WebSocket API, the edge KeyValueStore and an AWS Budgets alarm.
- Response headers policies, including the hash-only Content Security Policy, are in the template, so security headers change through review like everything else.
CloudFormation is the right tool when a system has more than a few AWS resources and needs to be rebuilt the same way twice. It turns a console session nobody can repeat into a file that is reviewed and versioned. I use it so the whole live stack is reproducible and every permission is written down.
Questions
Why use infrastructure as code for a small project?
So it can be rebuilt exactly and every permission is written down. My whole live stack is one template, and the template is the documentation.
Can a CloudFormation deploy break production?
A failed update rolls back to the last good state on its own. I still deploy through a script with its own checks rather than from the console.