AWS::EC2::EIP Adding tags to existing EIP is forcing ec2:disassociateAddress behavior

[damnhandy]

1. Title

Updating an existing AWS::EC2::EIP with new tags should require no interruption and not force a replacement.

2. Scope of request

We have been creating EIPs in a separate CloudFormation template so that they are not part of the typical application deployment lifecycle and we avoid the risk of loosing the IP addresses. With the recent addition of being able to add tagging to an EIP via CloudFormation, we attempted to introduce tags on these EIP resources. We adding tags to an existing AWS::EC2::EIP, Cloudformation will fail while performing a ec2:disassociateAddress and not update the EIP resource.

3. Expected behavior

Per the documentation for EIP tags, this operation should cause no interruption. With CloudFormation, it seems to always attempt a replacement rather than an update. If I add a tag to an existing EIP that is in use via the console or aws cli, it succeeds with no problem.

4. Suggest specific test cases

In our initial template, we declare the EIP like so:

  SomeEIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc

We added tags to the EIP resource this:

  SomeEIP:
    Type: AWS::EC2::EIP
    Properties:
      Domain: vpc
      Tags:
        - Key: Name
          Value: "Some EIP for App X"

When we make this change via Cloudformation via the AWS CLI, we get the following error:

UPDATE_FAILED: API: ec2:disassociateAddress You do not have permission to access the specified resource.

It should be noted that we are performing the deployment with admin privileges. Thus, it seems that merely adding tags are attempting force a drop and replace of the EIP rather than simply adding the tags to an existing EIP. Again, adding the tag via the console does not exhibit this behavior.

5. Helpful Links to speed up research and evaluation

According to the documentation for EIP tags, this operation should cause no interruption. This behavior appears to be forcing a replacement of the EIP.

6. Category

Compute (EC2, ECS, EKS, Lambda...)

[norbinsh]

this is actually breaking our deployments after upgrading CDK version, that now adds the "Name" tag to an EIP resource.
how is this not labeled as a bug @luiseduardocolon?
As a temp workaround, adding the following as offered here, stops the tag from being added:

    cdk.Tag.remove(this.vpc, "Name", {
      includeResourceTypes: ["AWS::EC2::EIP"]
    });

[rehanvdm]

This has been fixed (kind of), tested it now and this related CDK issue also confirms it. It still changes the association when updating the tags but it should not be breaking with this error anymore.

Now the interesting part, the nature of CFN is to first create and then destroy. But in this scenario, it seems it is doing the opposite, probably because there can only be one EC2 <=> EIP association that exists, I assume there is a uniqueness check.

This means that changing tags will dissociate the IP from whatever it is attached to for a few seconds. Not good for production and you will definitely feel it for high-volume traffic, 4 seconds can mean a lot of traffic is potentially dropped.