aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap

AWS::EC2::EIP - Error when deleting stack with AWS::EC2::EIP

Open
#831 2 comments 6 reactions 0 assignees View on GitHub
Coverage enhancement
Dominant language
No language data
Stars
1.1k
Forks
62
PR merge metrics
No merged PRs in 30d

Description

Hi,

I consistently get a `DELETE_FAILED` error with CloudFormation when deleting this stack:

```
AWSTemplateFormatVersion: "2010-09-09"
Description: 'ElasticIP deletion'
Parameters:
Subnet1:
Type: String
Subnet2:
Type: String
Resources:
LoadBalancer:
Type: AWS::ElasticLoadBalancingV2::LoadBalancer
Properties:
Scheme: internet-facing
Type: network
SubnetMappings:
- AllocationId: !GetAtt [ EIP1, AllocationId ]
SubnetId: !Ref Subnet1
- AllocationId: !GetAtt [ EIP2, AllocationId ]
SubnetId: !Ref Subnet2
IpAddressType: ipv4
LoadBalancerAttributes:
- Key: load_balancing.cross_zone.enabled
Value: true
EIP1:
Type: AWS::EC2::EIP
Properties:
Domain: vpc
Tags:
- Key: Name
Value: !Join [ '', [ { Ref: 'AWS::StackName' }, ' EIP1 for NLB' ] ]
EIP2:
Type: AWS::EC2::EIP
Properties:
Domain: vpc
Tags:
- Key: Name
Value: !Join [ '', [ { Ref: 'AWS::StackName' }, ' EIP2 for NLB' ] ]
```

The error in the event log for the two EIPs is:
```
API: ec2:disassociateAddress You do not have permission to access the specified resource.
```

- This error is misleading: I do have (and thus CloudFormation has) enough permissions to access the specified resources
- When retrying the stack deletion, the EIPs are deleted successfully

I suppose that there needs to be some retry logic when deleting an EIP, or a small delay after deleting a Network Load Balancer so the EIP deletion can happen successfully, because I can trigger deletion immediately after seeing the stack in `DELETE_FAILED` state. This second deletion has never failed.

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the supplied CloudFormation template with its network load balancer and two AWS::EC2::EIP resources, then inspect the DELETE_FAILED events for ec2:disassociateAddress. Compare the first deletion with the successful retry and determine whether the EIP cleanup needs retry handling or a delay after load balancer deletion. Done means the stack deletes successfully on the first attempt without the misleading permission error.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws
Domain
cloud, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.