🚨 CloudFormation Error Guide: 'is in ROLLBACK_COMPLETE state and can not be updated' — Recover a Stuck Stack

Overview

CloudFormation puts a stack into ROLLBACK_COMPLETE when the initial creation of the stack failed and CloudFormation successfully rolled back (deleted) everything it had provisioned so far. This is a terminal, unusable state: the stack still exists as a named object, but it holds no resources and CloudFormation refuses to update it. Any update-stack or deploy against it fails immediately:

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

The only supported path out of ROLLBACK_COMPLETE is to delete the stack and create it fresh (or, in some cases, continue-update-rollback from the related UPDATE_ROLLBACK_FAILED state — a different state people often confuse with this one). You cannot update your way forward. The real work is figuring out why the original create failed, because deleting and recreating without fixing the root cause just reproduces the same ROLLBACK_COMPLETE.

Note the important distinction from UPDATE_ROLLBACK_COMPLETE (a stack that was already created, had a failed update rolled back, and is updatable) — this guide is about ROLLBACK_COMPLETE, which only happens after a failed create and is not updatable.

Symptoms

• aws cloudformation deploy / update-stack fails with is in ROLLBACK_COMPLETE state and can not be updated.
• The stack shows ROLLBACK_COMPLETE in the console and has zero (or almost zero) resources under its Resources tab.
• A CI pipeline that redeploys the same stack name fails on every run after the first failed create.
• CDK cdk deploy reports the same error because it calls the same UpdateStack API underneath.

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

Stack:arn:aws:cloudformation:us-east-1:123456789012:stack/my-app/abc-123 is in
ROLLBACK_COMPLETE state and can not be updated.

Common Root Causes

1. The original create failed and rolled back

This is the definition of the state, not a separate cause — but it is the framing that matters. A resource failed to create, CloudFormation rolled the stack back, and now the empty shell blocks every retry. You must find the original create failure in the events, not the update error.

CREATE_FAILED   AWS::RDS::DBInstance   MyDatabase
Resource handler returned message: "DB Subnet Group doesn't meet availability
zone coverage requirement..."

2. An IAM / permission failure during create

The most common underlying create failure: the role CloudFormation used lacked permission to create one of the resources, so that resource failed and the whole stack rolled back.

CREATE_FAILED   AWS::S3::Bucket   Assets
API: s3:CreateBucket Access Denied

3. A resource that genuinely could not be created

A globally-unique name already taken (S3 bucket), an exhausted quota (EIPs, VPCs), an invalid AMI ID for the region, or a security group referencing a VPC that does not exist. The resource create errored, triggering rollback.

CREATE_FAILED   AWS::EC2::VPC   Vpc
The maximum number of VPCs has been reached.

4. A dependency or timing failure

A custom resource Lambda timed out, a WaitCondition never received its signal, or a resource depended on another that failed. CloudFormation gives up and rolls back.

5. DisableRollback / retention leftovers

If the failed create had DeletionPolicy: Retain on some resources, those resources may still exist in the account even though the stack is empty — which then causes a name-already-exists failure on the recreate. This is the trap that makes “just delete and recreate” fail again.

Diagnostic Workflow

Step 1: Confirm the state and find the ORIGINAL failure

Do not fixate on the update error. Pull the stack events and find the first CREATE_FAILED — that is the real root cause:

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

ROLLBACK_COMPLETE

# List failures oldest-first; the FIRST CREATE_FAILED is the trigger.
aws cloudformation describe-stack-events --stack-name my-app \
  --query "reverse(StackEvents[?contains(ResourceStatus,'FAILED')].[Timestamp,LogicalResourceId,ResourceStatusReason])" \
  --output table

Step 2: Check for retained/orphaned resources

Before deleting, find resources that a Retain deletion policy may have left behind, so the recreate does not collide with them:

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

Also check the account directly for the specific globally-unique resource (e.g. the S3 bucket name) that failed.

Step 3: Validate the template and parameters

Rule out a template-level problem that will just fail again:

aws cloudformation validate-template --template-body file://template.yaml

Step 4: Delete the stuck stack

ROLLBACK_COMPLETE cannot be updated — delete it:

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

If deletion itself fails (a retained resource blocks it), delete with a retain list or remove the orphaned resource first:

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

Step 5: Recreate only after fixing the root cause

Fix the original failure (add IAM permissions, choose a free bucket name, raise the quota) and redeploy:

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

Example Root Cause Analysis

A pipeline creating a new my-app stack failed on first deploy and every subsequent deploy returned is in ROLLBACK_COMPLETE state and can not be updated. The team’s instinct was to keep re-running the pipeline, which changed nothing.

They pulled the events oldest-first to find the original failure rather than the update error:

aws cloudformation describe-stack-events --stack-name my-app \
  --query "reverse(StackEvents[?contains(ResourceStatus,'FAILED')].[Timestamp,LogicalResourceId,ResourceStatusReason])" \
  --output table

2026-07-08T09:14:02Z  Assets   API: s3:CreateBucket Access Denied

The CloudFormation execution role was missing s3:CreateBucket, so the bucket create failed and the whole stack rolled back to the empty ROLLBACK_COMPLETE shell. Re-running could never succeed because (a) the state was un-updatable and (b) the permission was still missing.

The fix was three steps in order: add the missing permission to the execution role, delete the stuck stack, then redeploy.

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

Successfully created/updated stack - my-app

The recreate succeeded once the permission was in place. To prevent recurrence, the team pre-flighted the execution-role permissions and started using change sets so a create failure is caught before it strands a stack.

Prevention Best Practices

• Fix the original CREATE_FAILED reason before recreating; deleting and redeploying without it just reproduces ROLLBACK_COMPLETE. See our infrastructure-as-code guides.
• Scope and test the CloudFormation execution role’s permissions up front; IAM Access Denied during create is the single most common trigger.
• Use unique, generated names (or let CloudFormation name resources) so globally-unique collisions on recreate cannot occur.
• Deploy new stacks with change sets so you preview and catch failures before a bad create strands the stack.
• Be deliberate with DeletionPolicy: Retain — retained resources survive a rollback and can block both delete and recreate.
• In CI, detect ROLLBACK_COMPLETE and auto-delete the empty stack before retrying, so a first-attempt failure does not wedge the pipeline.

Quick Command Reference

# Confirm the stack is in the un-updatable state
aws cloudformation describe-stacks --stack-name STACK \
  --query 'Stacks[0].StackStatus' --output text

# Find the ORIGINAL create failure (oldest failed event first)
aws cloudformation describe-stack-events --stack-name STACK \
  --query "reverse(StackEvents[?contains(ResourceStatus,'FAILED')].[Timestamp,LogicalResourceId,ResourceStatusReason])" \
  --output table

# Check for retained/orphaned resources before deleting
aws cloudformation list-stack-resources --stack-name STACK --output table

# Delete the stuck stack (the only way out of ROLLBACK_COMPLETE)
aws cloudformation delete-stack --stack-name STACK
aws cloudformation wait stack-delete-complete --stack-name STACK

# Recreate after fixing the root cause
aws cloudformation deploy --stack-name STACK --template-file template.yaml \
  --capabilities CAPABILITY_NAMED_IAM

Conclusion

is in ROLLBACK_COMPLETE state and can not be updated means a stack’s initial create failed, CloudFormation rolled it back to an empty shell, and that shell cannot be updated — only deleted. The usual underlying triggers:

1. The original create failed (find the first CREATE_FAILED in events).
2. An IAM Access Denied on the execution role during create.
3. A resource that could not be created (name collision, quota, invalid AMI).
4. A dependency/timeout failure (custom resource, wait condition).
5. Retained resources that later block the recreate.

Read the original failure from the events, fix it, delete the stuck stack, and redeploy. Prevent recurrence with pre-flighted execution-role permissions, change sets, unique naming, and CI that auto-deletes an empty ROLLBACK_COMPLETE stack before retrying.