Questions tagged with Elastic Load Balancing

Content language: English

Sort by most recent

Browse through the questions and answers listed below or filter and sort to narrow down your results.

[AWS BUG?] NLB stops working during blue/green deployment with code-deploy.

I have a Fargate + ECS service, with an NLB with a TCP listener in 443 port and a TCP test listener in port 9443. We use NLB with TCP to do TLS termination the hosts (containers). I also have a second Target Group for blue/green deployments. All target types are setup to IPv4, and the service is working as expected outside deployments. I've run the following experiments: 1. When I run my integration tests outside of a deployment (both listeners are pointing to the same target group) all tests pass against both listeners (443 and 9443). 2. When I run them in the context of a deployment, in the AfterAllowTraffic hook (both listeners pointing to the replacement target group), all tests pass against both listeners (443 and 9443). 3. When I run the tests in the context of a deployment, in the AfterAllowTestTraffic hook, after I checked that listener 443 points to the blue target group, and the listener 9443 points to the green target group with a healthy container, neither of them pass, they fail to establish connection. However, If I run the tests directly against the container instances by targeting their IP, then all tests pass. 4. If I manually replicate the blue/green deployment setup, and point the test listener to other target group, so listener in 443 keeps pointing at a target group and then listener 9443 points to another target group, then both listeners STOP WORKING! 5. If in the experiment #4, I delete the listener on 9443, so there is only one listener in 443 targeting the blue target group, then it starts working again. Is this a misconfiguration on my side? It seems likely this is a problem in AWS-NLB side?
1
answers
0
votes
37
views
asked 20 days ago

HTTPAPI ALB integration over VPCLink to TargetGroup return 500 error

Hi, Here is my configuration mydomain.com -> API GW Custom Domain -> HTTPAPI -> Route (/api/{+proxy}) -> VPCLink -> ALB -> HTTPS Listener -> TargetGroup (Type: Instance) -> ECS Fargate Service HTTPAPI integration has the following parameter mapping: path -> overwrite -> /$request.path.proxy (I want to get rid of "api" part in the url) when I make below request I got 500 errors https://mydomain.com/api/otherPath I have enabled access logs on HTTPAPI but they show very limited information. ALB logs are sent to S3 bucket so it is almost impossible to track request. As far I see requests are not hitting the Fargate Service but I am not sure. Sample access log from API GW HTTP API: ``` { "requestId": "some_req_id=", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36", "sourceIp": "176.232.**.**", "requestTime": "01/Nov/2022:09:25:37 +0000", "requestTimeEpoch": "1667294737", "httpMethod": "GET", "path": "/otherPath", "status": "500", "protocol": "HTTP/1.1", "responseLength": "35", "domainName": "mydomain.com", "error_Message": "Internal Server Error", "integrationErrorMessage": "-", "integration_Error": "-", "integrationStatus": "200", "integration_Status": "-", "integration_IntegrationStatus": "200", "integrationLatency": "5" } ``` What am I missing? Why is it sooooo hard to find what is causing the error? I think configuration is fine but somehow it is really hard to make it work. Unbelievable!
1
answers
0
votes
17
views
asked a month ago