A TCP-based GIS streaming service must handle extreme concurrent connection counts from sensors and thick clients with ultra-low latency at layer 4. Which load balancer is the better fit?
Select an answer to reveal the explanation.
Short Explanation
Millions of skinny TCP sockets are an NLB problem—layer 4, connection-heavy, low fuss. Do not force that firehose through HTTP-only front doors.
Full Explanation
A TCP-based GIS streaming service that must handle extreme concurrent connection counts from sensors and thick clients with ultra-low latency at Layer 4 fits a Network Load Balancer (NLB). NLBs operate at L4, preserve high connection scale and low latency for TCP (and UDP) workloads, and are the standard choice when the protocol is not HTTP path routing but raw streaming sockets from field sensors and desktop GIS clients.
An Application Load Balancer alone expects HTTP/HTTPS semantics and path/host rules; forcing every binary TCP stream into HTTP path rules mismatches the protocol. A Classic Load Balancer in a single AZ with no modern scaling model is outdated relative to NLB for extreme connection counts and AZ design. Amazon API Gateway HTTP APIs front HTTP APIs—not raw TCP sockets from sensors—so they cannot be a mandatory front for this streaming service.
Exam caveat: choose ALB for L7 HTTP microservices routing, NLB for L4 TCP/UDP scale and static IPs/private link scenarios, and Gateway Load Balancer for inline appliance insertion. Do not pick NLB merely because it “sounds faster” when the stem is about HTTP path-based apps.
Operational check: place NLB listeners on the GIS TCP ports across multiple AZs; load-test hundreds of thousands of concurrent sensor connections; verify target health and connection twinning behavior meet SLA; and confirm security groups allow sensor CIDRs only to the NLB, not directly to every instance unnecessarily.