CloudFormation Stack
A CloudFormation Stack is a deployed instance of a CloudFormation template — all defined resources (VPCs, EC2 instances, RDS databases, IAM roles) are created, updated, and deleted together as one managed unit. This makes infrastructure reproducible and version-controlled: the same template deployed as separate dev and prod stacks guarantees identical environments instead of manual console clicks drifting apart over time.
A fintech platform team keeps its entire VPC-plus-RDS-plus-ASG topology in one CloudFormation template, deploying it as a fresh stack for every new regional expansion so staging and production are guaranteed structurally identical.
Change Sets Before You Apply
Updating a live stack should always start with a Change Set — a preview of exactly what will be added, modified, or deleted before anything actually happens. Skipping this on a production stack is how a well-intentioned parameter tweak accidentally deletes a database.
Protect Stateful Resources
By default, deleting a stack deletes everything in it, including databases with live data. Setting DeletionPolicy: Retain or Snapshot on RDS instances, S3 buckets, and EBS volumes prevents accidental data loss.
Common MistakeManually editing a resource that CloudFormation manages, outside the template. This causes stack drift and can make the next
update-stackfail or silently overwrite your manual change.
Frequently Asked Questions
What actually happens when you delete a CloudFormation stack?
CloudFormation deletes every resource it created for that stack, in dependency-reverse order, unless a resource has a DeletionPolicy of Retain or Snapshot set in the template. This is why production RDS databases and S3 buckets holding real data should almost always carry an explicit DeletionPolicy — without it, a stack deletion (accidental or intentional) permanently destroys the underlying data along with the stack, not just the CloudFormation-managed metadata.
What's the most common CloudFormation stack mistake teams make?
Manually editing a resource in the AWS console after it was created by a stack — this causes drift, where the live resource no longer matches the template's declared state. The next stack update can then fail unexpectedly or, worse, silently revert the manual change. Run drift detection periodically, and treat the template as the only source of truth: any change should go through an update, never a console click, even for a 'quick fix.'