🚨 CloudFormation Error: 'Stack [MyStack] does not exist' — Cause, Fix, and Troubleshooting Guide

Overview

This error means the CloudFormation API could not find a stack with the name (or ARN) you referenced in the region and account your CLI call was routed to. It surfaces on any operation that targets an existing stack by name — describe-stacks, update-stack, delete-stack, describe-stack-events, get-template, and so on. CreateStack is the exception: it fails with AlreadyExistsException when a stack does exist, and never with this message.

The literal text substitutes the operation name and your stack name:

An error occurred (ValidationError) when calling the DescribeStacks operation: Stack [MyStack] does not exist

Ninety percent of the time this is not a “the stack was deleted” problem. It is a targeting problem: the right stack exists, but your call landed in the wrong region, the wrong account, or you typed a name that does not exactly match. CloudFormation is regional and case-sensitive, and a DELETE_COMPLETE stack is invisible by name, so all of these look identical from the CLI.

Symptoms

• aws cloudformation describe-stacks --stack-name MyStack returns ValidationError ... Stack [MyStack] does not exist.
• update-stack or delete-stack fails with the same message even though you deployed the stack earlier today.
• The stack is clearly visible in the AWS Console, but the CLI (or CI job) cannot see it.
• A pipeline step that worked in one region fails in another with this error.
• CI deletes the wrong thing, or a “does the stack exist?” check returns false when it should be true.

Common Root Causes

1. Wrong region

CloudFormation stacks live in a single region. A call to us-east-1 cannot see a stack created in us-west-2. This is the single most common cause, especially in CI where the region comes from an env var or a profile you did not expect.

aws cloudformation describe-stacks --stack-name MyStack --region us-east-1
# Stack was actually created in us-west-2 -> "does not exist"

2. Stack name typo or case mismatch

Stack names are case-sensitive. MyStack, mystack, and my-stack are three different stacks. A trailing space, a copy-paste newline, or an environment prefix (prod-MyStack) that is only applied in some pipelines will all miss.

Intended:  prod-MyStack
Requested: MyStack        -> "does not exist"

3. Wrong AWS account or profile

If your shell is assuming a role or using a profile pointed at the sandbox account while the stack lives in production, every call resolves against an account where the stack genuinely does not exist.

aws sts get-caller-identity   # confirm which account you are actually in

4. The stack was deleted (DELETE_COMPLETE)

Once a stack reaches DELETE_COMPLETE, it can no longer be referenced by name — only by its full ARN, and only for a limited retention window. describe-stacks --stack-name MyStack will report it as non-existent even though it shows in the console’s deleted-stacks filter.

# Deleted stacks are only addressable by ARN:
aws cloudformation describe-stacks \
  --stack-name arn:aws:cloudformation:us-east-1:123456789012:stack/MyStack/abc123

5. Nested/child stack referenced directly

Nested stacks created by a parent get auto-generated names like parent-ChildResource-XXXXXXXX. If you try to update or delete the child by the logical name you used in the template, it will not resolve — nested stacks are managed through the parent.

6. Race condition during create/delete

If a check runs while a stack is mid-CREATE_IN_PROGRESS and then rolls back to DELETE_COMPLETE, or if two pipeline runs overlap, a describe can legitimately catch a window where the stack is gone.

How to Diagnose

Step 1: Confirm the account and identity

aws sts get-caller-identity
# Check the "Account" field matches where the stack should live.

Step 2: List every stack in the region you are targeting

aws cloudformation list-stacks \
  --region us-east-1 \
  --query "StackSummaries[?StackStatus!='DELETE_COMPLETE'].[StackName,StackStatus]" \
  --output table

If your stack is not in this list, it does not exist in this region. Repeat for other regions.

Step 3: Sweep all regions for the name

for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  found=$(aws cloudformation describe-stacks --stack-name MyStack --region "$r" \
            --query "Stacks[0].StackName" --output text 2>/dev/null)
  [ -n "$found" ] && echo "Found MyStack in $r"
done

Step 4: Check deleted stacks explicitly

aws cloudformation list-stacks \
  --stack-status-filter DELETE_COMPLETE \
  --query "StackSummaries[?StackName=='MyStack'].[StackName,DeletionTime]" \
  --output table

If it shows here, the stack was deleted — the “does not exist” message is accurate.

Fixes

Set the region explicitly on every call

Do not rely on ambient defaults in CI. Pass --region or set AWS_REGION at the top of the job.

export AWS_REGION=us-west-2
aws cloudformation describe-stacks --stack-name MyStack

Pin the exact name (including prefixes)

Match environment prefixes consistently. If production stacks are prod-MyStack, reference that everywhere and drive it from one variable.

STACK_NAME="prod-MyStack"
aws cloudformation describe-stacks --stack-name "$STACK_NAME"

Confirm the right account/profile

aws cloudformation describe-stacks --stack-name MyStack --profile prod

Make existence checks tolerant

For “create or update” logic, treat the error as “does not exist -> create” rather than a hard failure:

if aws cloudformation describe-stacks --stack-name "$STACK_NAME" >/dev/null 2>&1; then
  aws cloudformation update-stack --stack-name "$STACK_NAME" --template-body file://template.yaml
else
  aws cloudformation create-stack --stack-name "$STACK_NAME" --template-body file://template.yaml
fi

Or sidestep the whole branch with deploy, which creates or updates as needed:

aws cloudformation deploy \
  --stack-name "$STACK_NAME" \
  --template-file template.yaml

Recover a deleted stack

There is no undelete. Redeploy from the template and re-import or restore any retained resources (S3 buckets, RDS snapshots) that had a DeletionPolicy: Retain.

What to Watch Out For

• Region and account are the first two things to check — not the template. This error is almost never about template contents.
• Centralize the stack name and region in one place (a variable, a config file) so every pipeline stage agrees.
• Guard existence checks with 2>/dev/null and exit-code branching so a legitimate “not found” does not abort the whole job.
• Never reference nested/child stacks by their logical name — operate through the parent stack.
• Set DeletionPolicy: Retain on stateful resources so an accidental delete does not destroy data you cannot recover.
• In multi-region deployments, log the region on every CloudFormation call so failures are traceable.

Related Guides

• CloudFormation UPDATE_ROLLBACK_FAILED
• CloudFormation ROLLBACK_COMPLETE: Stack Cannot Be Updated
• CloudFormation No Updates To Be Performed