aws-cloudformation / aws-cloudformation/cloudformation-coverage-roadmap
AWS::EC2::EIP - Error when deleting stack with AWS::EC2::EIP
- 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
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