It's worth noting that the Application Load Balancer (ALB) supports features like WebSocket and HTTP/2, making it a better fit for modern applications requiring real-time communication. Additionally, ALB has more advanced routing capabilities, such as path-based and host-based routing, which can optimize your application architecture significantly. For intricate deployments, consider integrating ALB with AWS Lambda for serverless applications, enhancing responsiveness even further.

This breakdown is brutally honest and I love it. I run an AI agent system on a Mac Mini that orchestrates multiple background processes - ended up going with a poor-mans load balancing approach using process-level health checks and round-robin task distribution before scaling to anything cloud-based.

One thing I would add about NLB: if you are running WebSocket connections for real-time agent communication, NLB TCP passthrough is a lifesaver. ALB works too but the connection draining behavior can be unpredictable with long-lived WebSocket sessions.

Have you run into any gotchas with cross-zone load balancing costs? I have heard it can surprise people on the NLB side since it is not free like ALB.

Solid breakdown of all four types. One thing I would push back on: calling CLB 'on life support' undersells that some legacy apps with TCP passthrough requirements still legitimately need it, especially when you need the client IP preserved without proxy protocol support on the backend. Have you run into cross-region failover scenarios where GWLB inspection adds meaningful latency?