Use ALB or NLB for Websocket?

[leon cao]

In the question:

“An edtech company is preparing to launch a new virtual learning environment (VLE) hosted on Amazon EC2 instances. To support students and educators around the globe, the platform must be deployed across three AWS Regions: us-east-1, eu-west-1, and ap-southeast-1. Key components of the system, such as student progress tracking, resource availability, and real-time collaboration events, must remain consistent and synchronized across all Regions.

To support real-time interactivity, the VLE uses more than just standard HTTP and HTTPS ports. WebSocket connections run on port 5000 for live quizzes, and the interactive whiteboard feature communicates over port 8080. To ensure optimal user experience, the platform must direct learners to the AWS Region with the lowest latency. Additionally, the architecture must be designed so that any single Region can dynamically scale to accommodate traffic from all others, should the need arise.

A solutions architect must define an infrastructure strategy that delivers global availability, seamless scalability, and low-latency access, all while keeping operational overhead to a minimum.

What solution best satisfies these needs while reducing operational management effort?“

The answer suggests using NLB for websocket, it is true that as a layer 4 load balancer, NLB can be used for Websocket, but according to the doc: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html, “Application Load Balancers provide native support for WebSockets”. I think ALB is more suitable for this scenario.

So the question is, why here choose NLB instead of ALB for the Websocket solution?

[HalukO]

Correct, it should be the ALB option since ‘the VLE uses more than just standard HTTP/S’.
ALB does HTTP+Websocket. NLB does not do HTTP

[leon cao]

Yes that’s also the point why I choosed ALB.

[Irene-TutorialsDojo]

Good day leon cao,

Thank you for raising this concern. You are correct that Application Load Balancers (ALBs) support WebSockets.

However, ALBs are designed for HTTP and HTTPS traffic only and support WebSockets when they are running over those protocols, typically on ports 80 and 443. In the given scenario, the Virtual Learning Environment (VLE) requires WebSockets on port 5000 and additional interactive features on port 8080. Since these are non-standard TCP ports, an ALB cannot be used to handle this traffic.

Accordingly, Network Load Balancers (NLBs) operate at Layer 4 and can forward traffic on any TCP or UDP port, making them suitable for workloads that use custom ports such as 5000 and 8080. This is why the recommended solution uses an NLB in each Region to handle both the WebSocket and whiteboard traffic, combined with Route 53 latency-based routing for global user redirection and DynamoDB global tables for multi-Region data consistency.

If you have further questions or need additional clarification, please don’t hesitate to contact us.

Best,

Irene @ Tutorials Dojo

[reubendevries]

Irene, I’m not the original poster, but I’m going to push back on this answer here:

First the ALB uses the 7th Layer of the OSI model (usually referred as the presentation layer), meaning it can do EVERYTHING the NLB can do, along with presenting using HTTP/HTTPS protocol. The benefit of the NLB is that if something is LOWER on the OSI layers, then it can perform FASTER then something that is HIGHER on the OSI Layers. So if all you need is TCP/UDP and not anything from the presentation/application layer like the HTTPS protocol and speed is a major requirement then you’ll want to use an NLB over an ALB. The ALB can and will be able to communicate on ports other than 80 and 443. That’s simply an incorrect statement.

Finally I concur with the poster because the questions specifically says the VLE uses MORE than just standard HTTP/HTTPS ports, which in my understanding means it uses NOT ONLY HTTP/HTTPS but it uses other ports such as port 5000 for live quizes and the interactive white board feature (all which would need a load balancer with a PRESENTATION LAYER) communicating on port 8080.

To be honest the only possible or plausible answer is ALB if that information is correct. Please double check with Jon or someone else.

[Irene-TutorialsDojo]

Hello Everyone,

Thank you for taking the time to share your perspective. This is a great technical discussion, and I appreciate the detailed reasoning! Let me clarify a few key points to address the confusion around ALB vs NLB and their behavior with WebSockets and custom ports.

First, a quick correction on terminology: the Application Load Balancer (ALB) operates at Layer 7 (Application Layer) of the OSI model, not the presentation layer. It is designed to process HTTP and HTTPS requests and natively supports WebSockets only when the handshake occurs over HTTP/S (ws:// or wss://). While ALBs can indeed listen on ports other than 80 or 443, those listeners must still carry HTTP/S traffic. If the application uses raw TCP connections or non-HTTP protocols, an ALB cannot process that traffic.

In contrast, the Network Load Balancer (NLB) functions at Layer 4 (Transport Layer) and can forward any TCP or UDP traffic on any port. It doesn’t inspect application-layer data — it simply passes connections through. In this question’s scenario, the Virtual Learning Environment (VLE) uses WebSockets on port 5000 and another feature communicating over port 8080, both of which are non-standard TCP ports with no clear indication of HTTP/S usage. Because of that, the most reliable and compatible solution is to use an NLB, which can handle both custom and potentially non-HTTP traffic seamlessly.

If you have further questions or need additional clarification, please don’t hesitate to contact us.

Best,

Irene @ Tutorials Dojo

[leon cao]

Hi, Irene

Sorry, I still stick to the viewpoints of myself and other replies. As a developer with over ten years of experience, I clearly understand the difference between Layer 4 and Layer 7 communication. Ports are just the labels for inter-process remote communication.

ALB can work on non-80 and 443 ports, whether it’s listener or target group. As long as the content of the communication protocol message complies with HTTP/HTTPS, it is fine.

However, this question has never stated from beginning to end that communication can be carried out on non-HTTP /HTTPS protocols (WS/WSS is merely a long connection form of HTTP/HTTPS). If one insists on saying something, Only one sentence can roughly and vaguely infer your point of view: “and the interactive whiteboard feature communicates over port 8080”, however, port 8080 is often used by us programmers as a non-standard HTTP port.

Therefore, in my opinion, this question is highly misleading. If it is indeed a scenario that requires the use of NLB, it can be clearly stated in the question that some protocols only operate at the TCP/IP layer. If it is such a vague expression, there will definitely be great controversy