Both the EC2 instance health and our HTTP health checks. If either of those failed the server would have been removed from the load balancer, but they didn't fail.
Only the external health checks that hit the system from an outside service were failing. And because those spread out the load across the AZs, only a fraction of them were failing and no good way to tell the pattern of failure.
I did have some Kubernetes pods become unhealthy but only because they relied on making calls to servers that were in a different AZ.
Browsers typically use a few connections to load a page so that it can load faster. Each of those threads has a different source port, and thus may route to a different target.
In Colm's demo, it depends which thread your browser uses when requesting the part including the CSS which decorates the object.
In my Chrome on Mac I see 6 TCP connections to the demo NLB
tcp4 0 0 192.168.100.101.49615 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49614 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49613 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49612 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49611 54.69.111.179.80 ESTABLISHED
tcp4 0 0 192.168.100.101.49610 54.69.111.179.80 ESTABLISHED
Each of those will be routed to the same target, so it's up to your browser to decide which to use for what.
Better off depends on what your workload goals are.
If you want path or host name based routing, Application load balancer may be a better fit as it natively supports WebSockets.
If your goal is long lived sessions (weeks and months, not minutes and hours), Network load balancer is probably a better fit.
Where is this documented officially ? There's very little mention of Websockets in the guides, and none at all in the ALB creation wizard, which I didn't find reassuring.
