Best practices for websocket deployment

Customize health checks to accurately reflect server load and capacity. Default health checks might not be suitable for WebSocket connections which primarily rely on I/O operations. https://aws.amazon.com/blogs/compute/using-websockets-and-load-balancers-part-two/

Set up ALB listeners properly. Listeners are essential for handling incoming connection requests. You must define at least one listener for your ALB to manage traffic. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html

Utilize forwarding actions and weighted target groups to distribute traffic. You can route requests to multiple target groups with assigned weights, influencing how traffic is distributed among them. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html

Be aware that ALBs don't immediately detect an unhealthy node. If a WebSocket server restarts or goes down, the ALB may continue routing connections to it until it is marked unhealthy. https://aws.amazon.com/blogs/compute/using-websockets-and-load-balancers-part-two/

ALBs provide metrics like NewConnectionCount, representing the total number of new TCP connections established, and RejectedConnectionCount, indicating connections rejected due to the load balancer reaching its maximum connection limit. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html#:~:text=,the%20load%20balancer%20to%20targets

You may want to use different ALBs for WebSocket and API servers, depending on your architecture and traffic patterns. This can provide greater management and tuning according to the needs of each service.