A utilities API needs only TCP load balancing without HTTP routing, WAF integration, or path-based rules. How should the architect choose a load balancer with cost in mind?
Select an answer to reveal the explanation.
Short Explanation
Don't buy the Swiss-army ALB when all you need is a TCP crowbar. Match ALB vs NLB to the features you actually use—Layer-4 TCP leans NLB; fancy HTTP routing earns the ALB.
Full Explanation
Selecting a Network Load Balancer for Layer-4 TCP needs is the correct cost-aware choice when a utilities API needs only TCP load balancing without HTTP routing, WAF integration, or path-based rules, because NLB matches Layer-4 requirements without paying for unused Application Load Balancer Layer-7 features. Conversely, when HTTP routing is required, ALB is the fit—feature match drives cost discipline. Always deploying an ALB plus AWS WAF even when Layer-7 features are unused fails by purchasing capabilities and WAF association the workload does not need. Using Amazon API Gateway private integrations for raw TCP megabit streams fails conceptually: API Gateway is an HTTP/WebSocket-oriented API front door, not a general-purpose raw TCP load balancer for megabit streams. Fronting every flow with AWS Global Accelerator exclusively fails because Global Accelerator is a networking accelerator/entrypoint pattern, not a substitute that provides the same LB feature economics for simple VPC TCP balancing. Exam caveat: match NLB versus ALB to Layer-4 versus Layer-7 needs; do not default to ALB+WAF, API Gateway, or Global Accelerator when only TCP LB is required. Operational check: document required protocols and features for the utilities API; choose NLB for TCP-only; skip WAF/ALB unless HTTP rules appear; load-test failover; and review monthly LB line items so unused Layer-7 services are not quietly reintroduced.