🚨 AWS Error: 'is in ROLLBACK_COMPLETE state and can not be updated' — Cause, Fix, and Troubleshooting Guide

Overview

ROLLBACK_COMPLETE is the terminal state a CloudFormation stack lands in when its very first create attempt fails and CloudFormation rolls every resource back. The stack still exists as an empty shell, but it can never be updated — the only forward path is to delete it and create it again. Any update-stack or deploy against it is rejected.

You will see it surface from the CLI or a CI pipeline:

An error occurred (ValidationError) when calling the UpdateStack operation: Stack:arn:aws:cloudformation:us-east-1:111122223333:stack/my-app/REDACTED is in ROLLBACK_COMPLETE state and can not be updated.

It occurs after a failed create-stack where at least one resource could not be created (bad IAM, name collision, quota, invalid property), so CloudFormation rolled back and left the stack in this dead-end state.

Symptoms

• update-stack / deploy fails with ... is in ROLLBACK_COMPLETE state and can not be updated.
• The stack shows in the console with a red ROLLBACK_COMPLETE status and (usually) zero live resources.
• This only happens on a brand-new stack; an existing stack that fails an update goes to UPDATE_ROLLBACK_COMPLETE (which is updatable) instead.

aws cloudformation describe-stacks --stack-name my-app \
  --query 'Stacks[0].StackStatus' --output text

ROLLBACK_COMPLETE

Common Root Causes

The state itself is a symptom — the real cause is whatever made the initial create fail:

1. Insufficient IAM permissions to create a resource

The deploying principal (or the stack service role) lacked permission for one resource, so its creation failed.

2. A name or resource that already exists

A hardcoded bucket name, IAM role name, or log group already exists, so CREATE_FAILED fired on that resource.

3. A service quota or capacity limit

An EIP, VPC, NAT gateway, or instance-limit ceiling blocked a resource.

4. An invalid property or bad reference

A typo’d AMI ID, a Ref to a resource that failed, or a property value the API rejected.

5. A missing capability or dependency timeout

A custom resource that never signaled success, or a dependency that timed out waiting.

How to diagnose

Step 1: Find the resource that actually failed

The failure reason from the original create is preserved in the events. Filter for the failure:

aws cloudformation describe-stack-events --stack-name my-app \
  --query "StackEvents[?ResourceStatus=='CREATE_FAILED'].[LogicalResourceId,ResourceStatusReason]" \
  --output table

-------------------------------------------------------------------------
| AppBucket | app-artifacts (bucket) already exists                     |
-------------------------------------------------------------------------

The first CREATE_FAILED (not the cascade of “resource creation cancelled” that follows) names the true root cause.

Step 2: Confirm the stack is genuinely empty

aws cloudformation list-stack-resources --stack-name my-app \
  --query 'StackResourceSummaries[].[LogicalResourceId,ResourceStatus]' --output table

ROLLBACK_COMPLETE stacks normally have no CREATE_COMPLETE resources, so deleting is safe.

Fixes

Delete the failed stack, then recreate

aws cloudformation delete-stack --stack-name my-app
aws cloudformation wait stack-delete-complete --stack-name my-app

Then fix the root cause from Step 1 and create again:

aws cloudformation deploy --stack-name my-app --template-file template.yaml \
  --capabilities CAPABILITY_NAMED_IAM

If a rollback-retained resource blocks deletion

Occasionally a resource is retained and its real-world twin (e.g. a bucket) blocks recreation. Delete or rename the conflicting real resource, or pass --retain-resources on delete for stuck logical IDs:

aws cloudformation delete-stack --stack-name my-app \
  --retain-resources AppBucket

Prevent the next one with a change set / disabled rollback

For iterative first deploys, create with --disable-rollback (or --on-failure DO_NOTHING) so a failed create leaves resources in place for inspection instead of dropping you into ROLLBACK_COMPLETE.

What to watch out for

• Deleting a ROLLBACK_COMPLETE stack is safe only because it has no live resources — always confirm with list-stack-resources first.
• Read the first CREATE_FAILED event; the later “resource creation cancelled” lines are just the rollback cascade.
• In CI, treat ROLLBACK_COMPLETE as “delete-then-recreate,” not “retry update” — retrying deploy will loop on the same can not be updated error.
• --disable-rollback leaves half-built resources you must clean up manually if the create still fails.

Related

• AWS Error: CloudFormation ‘UPDATE_ROLLBACK_FAILED’ — the sibling failure on an existing stack’s update.
• AWS Error: ‘Requires capabilities: [CAPABILITY_IAM]’ — a common reason the initial create fails.
• AWS Error: ‘No updates are to be performed’ — the opposite end of the CloudFormation update lifecycle.