cloudformation-coverage-roadmap
cloudformation-coverage-roadmap copied to clipboard
AWS::ElasticLoadBalancingV2::LoadBalancer update bug
1. Title
AWS::ElasticLoadBalancingV2::LoadBalancer update bug
2. Scope of request
When you have a deployment with a Load Balancer (v2), with a listener and an attached target group (a very common case), if a template modification requires a replacement of the ALB (for example changing the exposition mode), it will fail with the following message: "The following target groups cannot be associated with more than one load balancer: arn:aws:elasticloadbalancing:xxxxxx:xxxxxxxxxxxx:targetgroup/ALBdhqslkdhqskd/flhfkljhfsd (Service: ElasticLoadBalancingV2, Status Code: 400, Request ID: (), Extended Request ID: null)"
This is because CloudFormation doesn't detect that the initial ALB is going to be replaced, and that means the Target Group needs to be replaced as well. As a result, since CloudFormation proceeds by creating a new resource, it tries to attach the Target Group to the new ALB resource, which fails because a Target Group cannot be attached to 2 ALBs at once, and provokes a rollback of the entire stack update.
I found an occurence of this bug in the AWS forums dating back to April 2017: https://forums.aws.amazon.com/thread.jspa?threadID=254544
3. Expected behavior
During AWS::ElasticLoadBalancingV2::LoadBalancer update, if target groups are attached (via listeners) to the ALB being replaced, they should be replaced as well.
As of now, it is not possible to replace a LoadBalancer if a TG is attached to it.
4. Suggest specific test cases
Samples:
The link in the AWS support forum has a test template in YAML that helps reproduce the issue. Updating the stack and changing the LB scheme (which provokes a replacement) will trigger the issue.
5. Helpful Links to speed up research and evaluation
https://forums.aws.amazon.com/thread.jspa?threadID=254544
6. Category
Networking & Content (VPC, Route53, API GW,...)
In the mean time it would be great to get a workaround
A work-around could be to manually delete the listeners on the ELB before updating the CF template..,
In the 'helpful links' section there appears to be a workaround. Has anyone tried it? Does if definitely work or not?
In the 'helpful links' section there appears to be a workaround. Has anyone tried it? Does if definitely work or not?
It will work only if you don't define a custom Name in your LoadBalancer
still happening.
Still an issue 11/25/2023. We expect a new LB to be created after the name change(there are automation in place to update the DNS with new LB) for smooth transition and minimum downtime. This is annoying for service already deployed on production.
Still an issue with EB(w/o ALB) upgrading to ALB
Still an issue with AWS CF and ALB. Manually deleting a resource to then bypass this is not the answer.