🚨 CloudFormation Error: 'CREATE_FAILED ... already exists in stack' — Cause, Fix, and Troubleshooting Guide

Overview

This error occurs when CloudFormation tries to create a resource with an explicit physical name that already exists in the account/region — so the underlying service refuses to create a duplicate. Because you gave the resource a fixed name (an S3 bucket name, an IAM role name, a DynamoDB table name, a log group), CloudFormation cannot let the service auto-generate a unique one, and the pre-existing object wins.

You will see it in stack events:

CREATE_FAILED    AppRole    Resource of type 'AWS::IAM::Role' with identifier 'app-service-role'
already exists in stack arn:aws:cloudformation:us-east-1:123456789012:stack/OtherStack/abcd1234-...

Or the service-message variant:

CREATE_FAILED    AppBucket    my-app-artifacts already exists

The root issue is always a name collision: the same physical name is owned by another stack, was left behind (orphaned) by a deleted/rolled-back stack, or was created manually outside CloudFormation. Fix the collision and the create succeeds.

Symptoms

• A CREATE_FAILED event saying a resource already exists in stack arn:aws:cloudformation:....
• The message names another stack ARN that currently owns the resource.
• Happens for resources with hard-coded names: BucketName, RoleName, TableName, LogGroupName, FunctionName, QueueName.
• A redeploy after a failed/rolled-back create fails because the resource lingered.

aws cloudformation describe-stack-events --stack-name MyAppStack --region us-east-1

ResourceStatus: CREATE_FAILED
ResourceStatusReason: app-service-role already exists in stack
arn:aws:cloudformation:us-east-1:123456789012:stack/OtherStack/...

Common Root Causes

1. The same fixed name in two stacks

Two templates hard-code the identical physical name, so whichever deploys second collides.

Resources:
  AppRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: app-service-role   # also defined in OtherStack -> collision

2. Orphaned resource from a deleted or rolled-back stack

A stack failed and rolled back but a Retain deletion policy (or a delete failure) left the named resource behind.

DeletionPolicy: Retain   # resource survives stack deletion, name stays taken

3. Resource created manually outside CloudFormation

Someone made an S3 bucket / IAM role by hand with the same name, so the stack cannot claim it.

aws iam get-role --role-name app-service-role

4. Global-namespace collision (S3, IAM)

S3 bucket names are globally unique across all AWS accounts; IAM role/user names are account-global. A name used anywhere else blocks you.

my-app-artifacts already exists   # taken by another account entirely for S3

5. Re-deploying after a partial create

The first attempt created the resource, then failed later; the resource stayed, and the retry now collides with itself.

How to Diagnose

Find which resource and name collided

aws cloudformation describe-stack-events \
  --stack-name MyAppStack --region us-east-1 \
  --query "StackEvents[?ResourceStatus=='CREATE_FAILED'].[LogicalResourceId,ResourceStatusReason]" \
  --output text

Check whether another stack owns it

The error often prints the owning stack ARN. Confirm it:

aws cloudformation describe-stack-resources \
  --stack-name OtherStack --region us-east-1 \
  --query "StackResources[?PhysicalResourceId=='app-service-role']"

Check for a manually created resource

aws iam get-role --role-name app-service-role
aws s3api head-bucket --bucket my-app-artifacts

A 200/found result means the name is already taken outside your new stack.

List all stacks that might reference the name

aws cloudformation list-stacks \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE ROLLBACK_COMPLETE

Fixes

Fix A (preferred): drop the fixed name and let CloudFormation generate one

Removing the explicit name lets CloudFormation append a unique suffix, eliminating collisions entirely.

Resources:
  AppRole:
    Type: AWS::IAM::Role
    Properties:
      # RoleName removed -> CloudFormation generates MyAppStack-AppRole-XXXXXXXX
      AssumeRolePolicyDocument: { ... }

Fix B: delete the orphaned resource, then redeploy

If nothing important owns it, remove the leftover object and retry.

aws iam delete-role --role-name app-service-role
aws cloudformation deploy --stack-name MyAppStack --template-file template.yaml

Fix C: import the existing resource into the stack

When the resource must keep its name, adopt it with a resource import instead of recreating it.

aws cloudformation create-change-set \
  --stack-name MyAppStack \
  --change-set-name import-role \
  --change-set-type IMPORT \
  --resources-to-import file://import.json \
  --template-body file://template.yaml

Fix D: make names unique per stack/environment

Suffix names with the stack name or environment so parallel stacks never collide.

    Properties:
      RoleName: !Sub "app-service-role-${AWS::StackName}"

Fix E: clean up after a global-namespace collision

For S3, pick a genuinely unique name (add account id / region), since the namespace is global.

      BucketName: !Sub "my-app-artifacts-${AWS::AccountId}-${AWS::Region}"

What to Watch Out For

• Prefer generated names; hard-coding physical names is the single biggest source of this error and blocks blue/green and multi-region deploys.
• DeletionPolicy: Retain intentionally orphans resources — track them, because their names stay reserved.
• S3 and IAM names are global; collisions can come from resources you cannot even see (other accounts for S3).
• A rolled-back stack in ROLLBACK_COMPLETE may still hold retained resources; delete the stack and the retained objects before recreating.
• Resource import lets you keep a name without deleting data — reach for it before destructive cleanup on stateful resources.

Related Guides

• CloudFormation ‘Resource handler returned message …’
• CloudFormation ROLLBACK_COMPLETE: Stack Cannot Be Updated
• CloudFormation No Updates To Be Performed