🚨 AWS Error: 'No updates are to be performed' — Cause, Fix, and Troubleshooting Guide

Overview

CloudFormation compares the template and parameters you submit against the currently deployed stack. If it computes zero differences, it refuses the update with a ValidationError rather than performing a no-op deployment. This is usually harmless, but it fails the CLI call (non-zero exit) and can break a naive CI pipeline that treats any error as a deploy failure.

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

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

It occurs whenever the submitted template + parameters are byte-for-byte equivalent (after CloudFormation’s normalization) to what is already deployed — often because your change was to something CloudFormation doesn’t track, or because drift means “reality” changed but the template did not.

Symptoms

• update-stack / deploy fails with No updates are to be performed even though “something changed.”
• A CI job goes red on this error although the infrastructure is actually in the desired state.
• Re-running the same deploy twice: the second run fails with this message.

aws cloudformation update-stack --stack-name app --template-body file://template.yaml

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

Common Root Causes

1. The template and parameters are genuinely unchanged

You re-ran a deploy without editing anything CloudFormation tracks.

2. The change was made outside the template (drift)

Someone edited a resource in the console/CLI. Reality drifted, but the template is identical to the last deployed template, so CloudFormation sees nothing to do.

3. The change is in a resource CloudFormation ignores

Editing a comment, reformatting YAML, or changing metadata that normalizes away produces no functional diff.

4. A parameter default changed but the resolved value didn’t

You changed a default in the template while passing the same explicit --parameters, so the effective value is unchanged.

5. The change lives in a nested stack or external asset

You updated Lambda code in S3 or a nested template, but the parent stack’s tracked properties didn’t change (no new S3 key/version reference).

How to diagnose

Step 1: Diff the deployed template against your local one

aws cloudformation get-template --stack-name app \
  --query 'TemplateBody' --output json > /tmp/deployed.json
diff <(python3 -m json.tool /tmp/deployed.json) <(python3 -m json.tool template.json)

No diff confirms CloudFormation is right: nothing tracked changed.

Step 2: Preview with a change set instead of updating

aws cloudformation create-change-set --stack-name app --change-set-name preview \
  --template-body file://template.yaml
aws cloudformation describe-change-set --stack-name app --change-set-name preview \
  --query 'Changes[].ResourceChange.[Action,LogicalResourceId]' --output table

An empty Changes list is the change-set equivalent — no error, just nothing to do.

Step 3: Check for drift when reality looks wrong

aws cloudformation detect-stack-drift --stack-name app
aws cloudformation describe-stack-resource-drifts --stack-name app \
  --query "StackResourceDrifts[?StackResourceDriftStatus=='MODIFIED']" --output table

Fixes

If nothing truly changed, treat it as success in CI

Guard the CLI so the benign message doesn’t fail the pipeline:

aws cloudformation deploy --stack-name app --template-file template.yaml 2>&1 \
  | tee /tmp/out || grep -q "No updates are to be performed" /tmp/out

aws cloudformation deploy already exits 0 on no-op in current CLI versions; the guard covers older update-stack usage.

Force the intended change to be tracked

For Lambda/asset updates, reference a versioned S3 key or object version so the property actually changes:

aws cloudformation deploy --stack-name app --template-file template.yaml \
  --parameter-overrides LambdaS3Key=app-$(git rev-parse --short HEAD).zip

Re-import drifted reality

If drift caused it, either update the template to match the desired state (producing a real diff) or use import / a corrective change to bring the resource back under management.

What to watch out for

• aws cloudformation deploy and update-stack behave differently: deploy swallows the no-op, raw update-stack errors — prefer deploy in automation.
• This error means CloudFormation sees no change; it does not mean your infrastructure matches the template — always run detect-stack-drift when reality looks off.
• Passing --parameters with UsePreviousValue=true for unchanged params avoids spurious diffs but also can’t create the change you expect.
• Bumping a versioned asset key (Lambda zip, layer) is the reliable way to make code-only changes visible to CloudFormation.

Related

• AWS Error: ‘ROLLBACK_COMPLETE’ state and can not be updated — a stack that can’t be updated for a very different reason.
• AWS Error: ‘Requires capabilities: [CAPABILITY_IAM]’ — another CloudFormation gate that fails the deploy call.
• AWS Error: CloudFormation ‘Rate exceeded’ — throttling during stack operations.