A stack policy is a fail-safe that blocks accidental updates to chosen resources during a stack update. It is not access control. AWS says to use IAM to control access to resources and actions. Use IAM to decide who can update a stack, and a stack policy to protect critical resources from the update itself.
What a stack policy does
A stack policy is a JSON document listing the update actions allowed or denied on named resources. Once you set one, all resources are protected by default and updates must be explicitly allowed. A Deny always overrides an Allow, so protect a resource with an explicit Deny.
The actions are Update:Modify, Update:Replace, Update:Delete and Update:* for all of them. Resources can be matched by logical ID, with wildcards, or by resource type through a condition. The Principal element is required but accepts only a wildcard, so the policy applies to everyone updating the stack.
What it does not do
- It applies only during stack updates.
- It cannot differ per user.
- It does not stop someone changing the resource directly in the service, outside CloudFormation.
- It does not grant or limit permissions.
That last point matters. A person with the right IAM permissions can modify a database directly, and the stack policy never sees it.
Using them together
| Question | Tool |
|---|---|
| Who may update this stack? | IAM |
| Who may change the policy? | IAM, SetStackPolicy permission |
| Should this update replace the database? | Stack policy |
| Who can edit the database outside the stack? | IAM, and a service role |
A service role helps. AWS notes that a service role separates the permissions of the user from those of the CloudFormation service, which uses the role's policy to make calls.
A good first policy
Allow everything, then deny the dangerous actions on the resources that hold state. For example, deny Update:Replace and Update:Delete on the production database by logical ID, and deny updates to the resource type of your key store.
Avoid NotResource with Allow as a way of protecting a resource. The documentation warns that it does not reliably prevent updates, because stack policies are evaluated against both the logical ID and the resource type, and the type remains allowed. Use an explicit Deny.
Overriding it deliberately
To update a protected resource, supply a temporary override policy for that one update. It does not permanently change the stack policy. You need SetStackPolicy permission to do it, which makes a natural approval point for risky changes.
You cannot delete a stack policy once set. To remove protection, modify it to allow all actions.
Review checks
- Does every production stack have a policy denying replacement of stateful resources?
- Who holds SetStackPolicy permission, and is that group small?
- Does the pipeline role also have direct access that bypasses the stack?
Quick check
Does a stack policy stop console edits to a resource?
No. It only applies during CloudFormation stack updates. Direct changes in the service need IAM controls and drift checks.
Can I attach different stack policies to different users?
No. A stack policy applies to everyone who updates the stack.
Sources
- Prevent updates to stack resources (AWS CloudFormation)
- Security best practices for CloudFormation (AWS)
Last reviewed: 19 October 2026.
