AWS CloudFormation Force Rollback, Explained

7 min read

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The announcement

• AWS What's New: AWS CloudFormation now simplifies stack update rollback operations, Oct 22 2026

Think about a kitchen renovation that goes wrong halfway through.

You tell the contractor to stop and put the old kitchen back. They start reinstalling everything. Then they hit one cabinet they cannot put back, because the landlord swapped it while the job was running. Nobody told the contractor.

Under the old rules, the whole crew downs tools. They hand you a clipboard and say: find every item we cannot restore, write each one down, and give us the list. Then we will try again. Until you do that, nobody can start any new work in that kitchen.

Under the new rules, the crew puts back everything it can, finishes the job, and leaves you a punch list. "Cabinet by the window: changed by someone else, please check before the next job." The kitchen is usable again the same day.

That second contractor is what AWS shipped for CloudFormation on October 22, 2026. It is called force rollback, and it changes how you get out of a failed update rollback.

Key takeaways

• Force rollback finishes a stuck update rollback in a single operation, instead of you identifying, listing and retrying each affected resource.
• It returns your stack to a deployable state, so you can get back to shipping.
• Resources that still need attention, like ones changed outside CloudFormation, are recorded for you to review before your next deployment.
• It works across every CloudFormation workflow: the AWS CLI, SDKs, AWS CDK and AI agents.
• It is available in all Regions at no additional cost.

What is an update rollback in CloudFormation?

When you update a CloudFormation stack and the update fails, CloudFormation tries to undo it. That undo is the update rollback. In AWS's own words, it "returns your stack to a known good state."

Most of the time this just works. The update fails, the rollback runs, and your stack is back where it was before you touched it.

The trouble starts when the rollback itself cannot finish. Some resources cannot roll back automatically. AWS gives one example in the announcement: a resource affected by a change outside CloudFormation. Someone edited it by hand, or another tool changed it, and now CloudFormation's picture of that resource no longer matches reality.

When that happens, your stack is stuck halfway. It is not on the new version and it is not fully back on the old one. Until the rollback completes, you cannot get back to deploying.

How did you fix a stuck rollback before force rollback?

The kitchen clipboard is a fair summary.

Before this release, the announcement describes the work as having to "identify, list, and retry the operation for each affected resource." In practice that means:

1. Work out which resources failed to roll back.
2. Build the list of those resources.
3. Retry the operation for them.
4. Repeat if something else turns up.

None of these steps is hard on its own. The cost is that you do them under pressure, usually right after a failed deploy, often with a team waiting on you. Every minute spent hunting for resource names is a minute nobody can ship.

How does force rollback work, step by step?

Here is the flow AWS describes, in order.

Step 1: your update fails and the rollback gets stuck. Some resources cannot roll back automatically.

Step 2: you run continue update rollback with the force rollback option. This is the operation you would already use to resume a stuck rollback, with a new option on it.

Step 3: CloudFormation finishes the rollback in one go. In the announcement's words, it "completes the update rollback and returns your stack to a deployable state in a single operation." You do not hand it a list.

Step 4: anything still broken gets recorded. Any resource that still needs attention is recorded for you to review and resolve before your next deployment. This is the punch list. Force rollback does not pretend the problem is gone. It writes it down and gets out of your way.

Step 5: you create a drift-aware change set. AWS recommends this as the follow-up, to review any configuration differences before your next deployment. This is how you surface the differences left behind by a change made outside CloudFormation.

Step 6: you review, fix, and deploy. You now know what is different, so your next deployment is a decision, not a guess.

The full details live in the "Continue rolling back an update" page of the AWS CloudFormation User Guide, which the announcement points to.

Does force rollback work with AWS CDK and AI agents?

Yes. AWS says it "works across every CloudFormation workflow, from the AWS CLI, and SDKs to AWS CDK and AI agents."

That matters more than it sounds. If you deploy with the CDK, you are still deploying through CloudFormation, so a stuck rollback hits you just as hard. And if you let an AI agent run deployments, the old identify, list and retry loop is precisely the kind of fiddly, multi-step recovery that goes wrong. One operation is easier for a person to get right, and easier for an agent too.

How much does force rollback cost?

Nothing extra. The announcement says force rollback "is available in all Regions at no additional cost." AWS points to its Region table for service availability details.

When should you use force rollback?

Use it when your goal is to get the stack deployable again and deal with the leftovers separately. Good fits:

• A rollback is stuck on a resource someone changed by hand. This is the exact case AWS calls out.
• You are blocked from deploying and the team is waiting. One operation beats a manual hunt through resource names.
• Your deployments run through automation. CI pipelines, the CDK or an AI agent all benefit from a recovery path that is a single operation.

When should you not reach for it straight away?

Force rollback gets your stack moving. It does not fix the resources that could not roll back. Those are recorded for review, which means the work is postponed, not removed.

So slow down when:

• You do not understand why the rollback failed. Finishing the rollback first is fine, but read the recorded resources before you deploy again. AWS's own advice is to review and resolve them before your next deployment.
• You plan to deploy again immediately without looking. Skipping the drift-aware change set throws away the point of the punch list. The differences are still there.
• The outside change was deliberate. If someone changed a resource on purpose, for example as an emergency fix, you need to decide whether to keep that change and bring your template in line, or overwrite it. Force rollback will not make that call for you.

A simple rule: force rollback is for unblocking, the change set is for understanding. Use both.

What does a force rollback look like in practice?

Here is a small diagram in words. Picture a stack with three resources: a queue, a function and a database. You push an update that touches all three.

BEFORE THE UPDATE        known good state
  queue      v1
  function   v1
  database   v1

UPDATE FAILS             CloudFormation starts the rollback
  queue      v2 -> v1    rolled back
  function   v2 -> v1    rolled back
  database   v2 -> ??    cannot roll back (changed outside CloudFormation)

STACK IS STUCK           you cannot get back to deploying

OLD WAY
  you identify "database", list it, retry the operation
  repeat for anything else that turns up

NEW WAY
  continue update rollback + force rollback option
  -> rollback completes in one operation
  -> stack is deployable again
  -> "database" is recorded as needing attention

NEXT
  create a drift-aware change set
  -> review how the database differs
  -> resolve it, then deploy

The queue and the function behaved. The database is the cabinet the landlord swapped. Under the old flow, that one resource held up the whole stack until you dealt with it by hand. Under the new flow, the stack moves on and the database waits on your punch list.

I like this design because it is honest. It does not mark a broken resource as fine. It just stops one broken resource from freezing everything around it.

What should you change in your runbook today?

If your team keeps a runbook for failed deploys, this release is worth a 10-minute edit.

• Add force rollback as the first move for a stuck update rollback.
• Make the drift-aware change set a required second step, not an optional one.
• Note who reviews the recorded resources, so the punch list does not quietly rot.
• If you deploy with the CDK or an agent, check that your recovery path uses the new option rather than a hand-built list.

FAQ

What does force rollback do in AWS CloudFormation?

It completes a stuck update rollback in a single operation. Instead of you identifying, listing and retrying each resource that could not roll back, CloudFormation finishes the rollback and returns the stack to a deployable state. Resources that still need attention are recorded for you to review.

Does force rollback fix the resources that failed?

No. It records them so you can review and resolve them before your next deployment. AWS recommends creating a drift-aware change set afterwards to review any configuration differences, such as those left by a change made outside CloudFormation.

Can I use force rollback with AWS CDK?

Yes. AWS says force rollback works across every CloudFormation workflow, including the AWS CLI, SDKs, AWS CDK and AI agents.

Is force rollback available in my Region, and what does it cost?

AWS says it is available in all Regions at no additional cost. For service availability details, AWS points to its Region table.

Add force rollback and a drift-aware change set to your failed-deploy runbook this week, and grab the free tools on Art of Code for the small jobs around it. If you work on infrastructure like this, the Art of Code jobs board is worth a look.

Written by Adithya Guttha, Founder of Art of Code.