Reputation: 335
From observer's perspective, symptoms are identical to the issue here Scenario is the same as well: Angular app which sends preflight requests to REST api, and preflight requests take in roughly 50% of times up to 1.3 seconds (illustration is the same as in the linked question).
Also, websocket was frequently timing out until socket-io finally succeeded in establishing connection. Problem was more pronounced in Chrome and less in Safari/Firefox.
However, we are using ALB and not ELB, and all our subnets are public.
Upvotes: 1
Views: 2941
Reputation: 3
We also have been facing the same problem, and we found out that we had one public subnet in one zone and private subnet in other zone of the ALB. We fixed it by selecting public subnet in both availability zone. In general for public facing ALBs all the subnets should be a public subnet though traffic where you are redirecting (EC2, lambda) could be in private subnet as well.
Upvotes: 0
Reputation: 430
Had a similiar issue. The LB has to be set up to use at least 2 availability zones. You have to select which subnetwork in each AZ it should use. In my case, one of the networks had bad ACL settings that basically denied all traffic. This would mean that the service would seem to go down for a minute or so whenever DNS decided to give you the IP address of the non-functioning LB interface. It would then start working again after the DNS cache expired and you got the IP for the functioning interface.
Upvotes: 2
Reputation: 335
Solution we found working was that all subnets needed to go through same internet gateway - same route table was applied to all subnets.
When that was done, all requests started going through faster and websocket connects immediately without reconnecting.
Upvotes: 5