How do I resolve the "Custom Named Resource already exists in stack" error in AWS CloudFormation?

Last updated: 2022-08-16

My AWS CloudFormation stack fails to create a resource, and I receive an error message telling me that my resource already exists in the stack. How do I resolve this error?

Short description

When you create a custom-named resource with the same name and set to the same value as another resource, CloudFormation can't differentiate between them. You then receive the error message, "Custom Named Resource already exists in stack." Each custom-named resource has a unique Physical ID. You can't reuse the Physical ID for most resources that are defined in CloudFormation.

You can resolve this error by changing the name of the failing resource to a unique name. Or, you can choose to not define the custom name for that resource. If you don't set a custom name, then CloudFormation generates a unique name when the resource is created. This unique name won't conflict with your existing resources.

Resolution

1.    In the CloudFormation template that contains your failing resource, check if other explicitly declared resources have the same name as your failed resource.

In the following example, the stack fails because each AWS Identity and Access Management (IAM) ManagedPolicy resource (ManagedPolicyName) has the same custom name (FinalS3WritePolicy).

S3DeletePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName:
        Fn::Join:
        - _
        - - FinalS3WritePolicy
          - Ref: EnvType
      PolicyDocument:
........
........
S3WritePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName:
        Fn::Join:
        - _
        - - FinalS3WritePolicy
          - Ref: EnvType
      PolicyDocument:
........
........

2.    Update the name of any resource that has a duplicate name. For example, change the first instance of FinalS3WritePolicy in the preceding example to FinalS3DeletePolicy. Or, remove the custom name.

In the following examples, Stack A succeeds because each IAM ManagedPolicy resource has a unique custom name (FinalS3DeletePolicy and FinalS3WritePolicy). Stack B succeeds because no custom name values are set for either ManagedPolicyName properties. When the resource is created, CloudFormation automatically generates a unique name for each IAM ManagedPolicy resource in Stack B.

Stack A:

S3DeletePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName:
        Fn::Join:
        - _
        - - FinalS3DeletePolicy
          - Ref: EnvType
      PolicyDocument:
........
........
S3WritePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      ManagedPolicyName:
        Fn::Join:
        - _
        - - FinalS3WritePolicy
          - Ref: EnvType
      PolicyDocument:
........
........

Stack B:

S3DeletePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
........
........
S3WritePolicy:
    Type: AWS::IAM::ManagedPolicy
    Properties:
      PolicyDocument:
........
........

Note: You can use the resolution in this article for related errors involving resources that exist in a different stack or resources created outside of CloudFormation.


Did this article help?


Do you need billing or technical support?