- Create a minimal CloudFormation policy
- Attach it to a user
- Attempt a stack update, observe authorization errors
- Iteratively add the CloudFormation (and S3) actions required to complete an update
- Verify the update and review best practices
Step 1 — Create a minimal custom CloudFormation policy
Start with a very small policy that allows the user to list and describe stacks so they can see stacks and basic stack metadata.limited-user-cf). After attaching, confirm the policy appears in IAM.
Permission changes can take a few moments to propagate in the console. If the limited user cannot see stacks right away, refresh the CloudFormation or IAM pages.
Step 2 — Attempt to update a stack and identify missing actions
When the limited user attempts to update a stack (Update stack → Make a direct update → Replace existing template), CloudFormation will try to load the stack policy and other metadata. If the user lacks required actions, the console will show errors such as “Failed to load stack policy.”
- cloudformation:GetStackPolicy
Step 3 — Uploading templates: CreateUploadBucket and S3 access
If you choose “Upload a template file” or CloudFormation needs to stage a large template, CloudFormation may try to create a temporary S3 upload bucket. If the user lacks this permission, you’ll see: User is not authorized to perform: cloudformation:CreateUploadBucket Add cloudformation:CreateUploadBucket. In addition, CloudFormation uses S3 APIs (for example, to put the template object into a bucket). If S3 permissions are missing, uploads will fail. For the demo we allow all S3 actions; in production you should scope these to specific buckets and actions. Add CreateUploadBucket and S3 full access:
Step 4 — Add GetTemplateSummary for template inspection
When you upload or reference a template URL, the console calls cloudformation:GetTemplateSummary to parse the template and display parameters, defaults, and metadata. If this action is missing, you’ll receive: User is not authorized to perform: cloudformation:GetTemplateSummary Add cloudformation:GetTemplateSummary to the policy. Policy after adding GetTemplateSummary:
Step 5 — Grant UpdateStack to perform the update
To actually submit an update, include cloudformation:UpdateStack. Without this action, you can walk through the update wizard, but the final submission will be rejected. Final example policy for the demo (consolidated):Common CloudFormation + S3 actions and why they’re needed
| Action | Resource | Purpose / When the console/API needs it |
|---|---|---|
| cloudformation:ListStacks | * | Show stack list in the console |
| cloudformation:DescribeStacks | * | View stack details and status |
| cloudformation:GetStackPolicy | * | Retrieve the stack policy to load during updates |
| cloudformation:CreateUploadBucket | * | Allow CloudFormation to create a temporary S3 bucket for uploads |
| cloudformation:GetTemplateSummary | * | Parse template to list parameters and metadata |
| cloudformation:UpdateStack | * | Submit the actual stack update |
| s3:PutObject, s3:GetObject, s3:ListBucket (or s3:*) | specific bucket ARNs | Upload templates to staging buckets and read uploaded templates |
The examples above use broad S3 permissions (s3:* and Resource ”*”) purely for demonstration. In production, follow the principle of least privilege: limit S3 actions and resources to only the buckets and operations required (for example, s3:PutObject, s3:GetObject, s3:ListBucket on specific bucket ARNs).
Troubleshooting UI authorization errors
While testing, the console UI may still show “not authorized” banners for specific read actions if those actions are not allowed (for example, DescribeStackEvents). If a console view is missing data, add the corresponding read actions to your policy:- cloudformation:DescribeStackEvents
- cloudformation:DescribeChangeSet
- cloudformation:GetTemplate
- cloudformation:ListChangeSets
Confirming the update and validating resource changes
After a successful update, verify any expected resource changes in the service consoles (for example, S3 bucket tags or properties).
Best practices and next steps
- Principle of least privilege: narrow S3 and CloudFormation permissions to only what is necessary (bucket ARNs and specific S3 actions such as s3:PutObject, s3:GetObject, s3:ListBucket).
- Iteratively add actions: observe the console/API errors, then add only the actions required for your workflow.
- To fully populate the CloudFormation UI (events, change sets, templates), grant the relevant read actions (for example: cloudformation:DescribeStackEvents, cloudformation:DescribeChangeSet, cloudformation:GetTemplate).
- Audit and version your customer-managed policies and use IAM Access Analyzer or simulate policies to validate expected behavior.