🚨 CloudFormation Error Guide: 'No updates are to be performed' — Force a Real Stack Change

Overview

CloudFormation compares the template and parameters you submit against the stack’s current template and parameters. If they are byte-for-byte equivalent, it refuses the update rather than doing nothing:

An error occurred (ValidationError) when calling the UpdateStack operation: No updates are to be performed.

This is not a failure of your infrastructure — it means CloudFormation sees no difference in the inputs it tracks, even if the world outside the template has changed.

Symptoms

• aws cloudformation update-stack returns ValidationError: No updates are to be performed. and exits non-zero.
• A CI/CD deploy step fails even though “nothing is wrong,” breaking the pipeline.
• You changed something that lives outside the template (an AMI’s contents, an SSM parameter’s latest value, a Lambda’s code in S3) and expected a redeploy.
• Re-running the same template after a manual console change does not revert the drift.

Common Root Causes

• Identical template and parameters — you resubmitted the same template; CloudFormation only diffs what it stores.
• Out-of-band change — a value changed in the real world (new AMI, rotated secret) but the template text is unchanged, so CloudFormation sees no diff.
• AWS::NoValue/default parameters — a parameter you think you changed resolved to the same effective value.
• Nested stack no-op — the parent template is unchanged even though you edited a child that is referenced by URL that did not change.
• Pipeline resubmitting the last-known-good template unchanged.

Diagnostic Workflow

Ask CloudFormation what it thinks the difference is, safely, with a change set instead of a blind update:

aws cloudformation create-change-set \
  --stack-name my-stack \
  --change-set-name diff-check \
  --template-body file://template.yaml \
  --parameters ParameterKey=Env,ParameterValue=prod

aws cloudformation describe-change-set \
  --stack-name my-stack --change-set-name diff-check

An empty Changes array (Status: FAILED, StatusReason: The submitted information didn't contain changes) confirms CloudFormation sees no diff.

Compare the deployed template against your local file:

aws cloudformation get-template --stack-name my-stack \
  --query TemplateBody > deployed.json

Detect real-world drift the template cannot see:

aws cloudformation detect-stack-drift --stack-name my-stack
aws cloudformation describe-stack-resource-drifts --stack-name my-stack

Example Root Cause Analysis

A pipeline deployed a Lambda whose code lived in S3 at a fixed key builds/app.zip. Engineers pushed a new build to the same key and re-ran the deploy, which failed with No updates are to be performed. The template referenced S3Key: builds/app.zip — unchanged text — so CloudFormation diffed identical inputs and refused.

The root cause was addressing the artifact by a mutable key. Because the Code.S3Key string never changed, CloudFormation had no way to know the object behind it did. The fix was to make the artifact reference change on every build: use a versioned key (builds/app-<gitsha>.zip) or pass the S3 object version as a template parameter, so each deploy presents a genuine template/parameter diff and CloudFormation performs the update.

Prevention Best Practices

• Reference build artifacts by an immutable, changing key (git SHA or object version), never a fixed key.
• Use change sets in CI and treat an empty change set as “nothing to do” (skip), not a hard failure.
• For values CloudFormation cannot see, thread them through as parameters so a change is visible in the diff.
• Run detect-stack-drift on a schedule to catch out-of-band console changes the template will not revert on its own.
• Do not resubmit the last-good template unchanged expecting a redeploy of external content.

Quick Command Reference

aws cloudformation create-change-set --stack-name S --change-set-name c --template-body file://t.yaml
aws cloudformation describe-change-set --stack-name S --change-set-name c
aws cloudformation get-template --stack-name S --query TemplateBody
aws cloudformation detect-stack-drift --stack-name S
aws cloudformation describe-stack-resource-drifts --stack-name S

Conclusion

No updates are to be performed means CloudFormation’s template-and-parameter diff came up empty — it only tracks what is written in the stack, not the mutable world your resources point at. Use change sets to see the diff safely, treat an empty change set as a no-op rather than an error, and make external changes visible by referencing artifacts through changing keys or parameters so every real change produces a real update.