AWS offers several Elastic Load Balancing options because the traffic decision itself can happen at different layers. An architect choosing between Application Load Balancer (ALB), Network Load Balancer (NLB), and Gateway Load Balancer (GWLB) should begin with the protocol, the information that must be inspected, the target type, and whether the goal is application delivery or transparent appliance insertion.
This distinction matters for the current AWS Certified Solutions Architect – Associate exam because a scenario may describe the requirement indirectly: host-based routing suggests an application-layer decision, fixed IP requirements point toward a network-layer design, and centralized firewall insertion is a different problem again. Choosing the service by name recognition instead of traffic behavior is the common mistake.
Start with the layer and purpose of the traffic decision
A useful way to frame cloud load balancing is that the load balancer accepts traffic on a stable front end and distributes it to healthy back-end targets. AWS then specializes that basic function.
ALB understands HTTP and HTTPS semantics. It can inspect request attributes and make Layer 7 routing decisions. NLB handles transport-layer connections and flows, including TCP, UDP, TCP_UDP, and TLS listeners, without needing to interpret an HTTP request. GWLB is designed for a service chain in which traffic must pass through virtual network appliances such as firewalls or intrusion-prevention systems.
That means the first design question should not be “Which load balancer is fastest?” It should be “What decision must the load balancer make?” If the answer is based on a hostname or URL path, use an HTTP-aware service. If it is based on a transport connection and stable network addressing, use a Layer 4 service. If the application server is not the target at all and an inspection appliance must see the flow, evaluate GWLB.
Use ALB when routing depends on the HTTP request
Application Load Balancer is the normal choice for web applications, APIs, container services, and other HTTP or HTTPS workloads that need request-aware routing. Listener rules can evaluate conditions such as host headers, URL paths, HTTP headers, query strings, source IP addresses, and request methods. A single front end can therefore route api.example.com to one target group, admin.example.com to another, and /images/* to a separate service.
That capability is especially useful in microservice architectures because a stable listener can front several independently scaled services. ALB target groups can use instance IDs, private IP addresses, or a Lambda function as the target type. With IP targets, the destination does not have to be tied to a specific EC2 instance identity, which fits containers and hybrid patterns. ALB can also communicate with supported target groups using HTTP/1.1, HTTP/2, or gRPC protocol versions.
ALB also centralizes features that belong close to the application edge: TLS termination, certificate selection through AWS Certificate Manager, redirects, authentication integrations, sticky sessions where appropriate, and detailed health checks. None of those capabilities eliminates the need for sound application design, but they make ALB much more than a simple round-robin distributor.
Treat health checks and target groups as part of the ALB design
A load balancer is useful only if it can keep traffic away from unhealthy targets. ALB health checks run against each target group, and routing is based on target health within the enabled Availability Zones. The health check path, success codes, thresholds, timeout, and interval should match the application’s real readiness behavior rather than merely testing whether a process can open a socket.
For example, an application may return HTTP 200 from / while its database dependency is unavailable. If the load balancer checks only that path, it can continue sending production traffic to an instance that cannot complete user requests. A deliberately designed readiness endpoint gives a more meaningful signal. Conversely, making the health check depend on too many remote services can remove every target during a shared dependency failure.
Security groups also matter. ALBs support security groups, so the listener should accept only required client traffic and the targets should normally accept application traffic from the ALB security group rather than from broad CIDR ranges. This creates a clearer trust boundary and makes later troubleshooting easier.
Use NLB for Layer 4 traffic, static addressing, and PrivateLink patterns
Network Load Balancer is appropriate when the requirement is transport-layer distribution rather than HTTP-aware routing. Common examples include custom TCP services, UDP applications, high-throughput connection handling, TLS listeners, and architectures where clients or partner systems require stable IP addresses.
An NLB creates a node in each enabled Availability Zone. For an internet-facing NLB, an Elastic IP address can be associated with each enabled zone, giving the architecture predictable public addressing. This can be important when a partner allowlists fixed destination IPs or when a legacy client cannot comfortably follow changing DNS-resolved addresses. The static-address requirement should be genuine, however; it is not a reason to give up ALB’s Layer 7 features when the application actually needs them.
NLB is also central to AWS PrivateLink endpoint services. A service provider can place an NLB in front of the service and expose it privately to consumer VPCs through interface endpoints. That allows private service consumption without requiring broad VPC peering or routing between the participating networks.
Know what NLB does not replace
A Network Load Balancer does not provide host-based or path-based routing just because it can terminate TLS. TLS termination and HTTP request inspection are different capabilities. If a scenario needs example.com/api and example.com/store to reach different services, ALB is the natural fit. If it needs raw TCP on port 443 with predictable addresses, NLB may be the better fit.
Target design also differs. NLB supports instance and IP target types, and can use an ALB as a target, but it does not support Lambda as a target type. Client IP preservation, source address behavior, cross-zone load balancing, security groups, and target health should all be checked against the specific listener and target configuration instead of inferred from another load balancer family.
This matters operationally because moving from ALB to NLB is not a cosmetic change. Monitoring, target registration, health checks, source-address expectations, and application routing responsibilities may all change.
Chain NLB and ALB only when the requirements justify both
AWS supports registering a single ALB as the target of an NLB target group. This pattern lets the NLB provide capabilities such as static IP addresses or PrivateLink-compatible service exposure while the ALB performs the Layer 7 request routing after traffic reaches it.
The design can be valuable when the requirements genuinely span both layers. For example, a private service may need to be consumed through PrivateLink while still routing /orders and /catalog to separate application services. The NLB satisfies the private network-service requirement and the ALB satisfies the HTTP-routing requirement.
The tradeoff is another component in the path. Troubleshooting must distinguish NLB listener and target health from ALB listener rules and application target health. Metrics, logs, certificates, timeouts, and failure domains exist at both layers. If one load balancer can meet the requirement cleanly, adding a second merely for architectural symmetry increases cost and operational surface without adding value.
Use GWLB when the target is a network appliance
Gateway Load Balancer addresses a different class of problem. It is designed to distribute flows across virtual appliances while acting as a transparent gateway in the network path. Typical targets include third-party firewalls, intrusion detection or prevention systems, deep-packet inspection appliances, and other network-security services.
GWLB uses the GENEVE protocol between the load balancer and appliance targets. Consumer VPCs connect to the appliance service through Gateway Load Balancer endpoints, which are powered by AWS PrivateLink. Routes can then steer selected traffic through those endpoints so that inspection happens without every workload VPC operating its own independent appliance fleet.
This model is useful for centralized inspection architectures. A security team can manage the appliance fleet in a dedicated service VPC while application VPCs route ingress, egress, or east-west traffic through the inspection service according to the design. The important distinction is that GWLB is not selecting which web application should answer a request; it is selecting which appliance should process a network flow transparently.
Design for zones, failover, and the whole request path
The load balancer type is only one part of availability. Enabled Availability Zones, target distribution, health checks, DNS behavior, target capacity, and cross-zone settings determine how the design behaves during a zonal failure or uneven load. An architect should be able to trace the complete path from client to listener to target group to application or appliance.
For internet-facing services, also consider whether AWS Global Accelerator, CloudFront, Route 53, or another edge component is part of the path. Those services solve different problems from Elastic Load Balancing. A load balancer distributes traffic to targets; it does not automatically provide global DNS policy, CDN caching, or anycast acceleration unless another service is added.
Classic Load Balancer can still appear in existing environments, but new designs normally begin by evaluating ALB, NLB, or GWLB. Treat Classic Load Balancer as a legacy compatibility consideration rather than a default fourth option.
Choose from the workload requirement, not a memorized hierarchy
A reliable selection process is straightforward. Choose ALB when HTTP or HTTPS request attributes drive routing, when web-oriented integrations matter, or when Lambda and modern application target groups are useful. Choose NLB when the requirement is TCP, UDP, TCP_UDP, or TLS transport behavior, very high connection handling, stable per-zone IP addressing, or PrivateLink service exposure. Choose GWLB when traffic must be inserted transparently into a scalable fleet of network appliances.
Then validate the second-order requirements: target type, health-check semantics, TLS termination point, source IP expectations, security groups, Availability Zones, cross-zone behavior, logging, and the operational failure path. Two architectures can both “use a load balancer” while having completely different reliability and troubleshooting characteristics.
Suppose the application must route by HTTP host and path, preserve long-running TCP connections or inspect traffic through a third-party security appliance. Those are different load-balancing jobs: Application Load Balancer handles application-layer routing, Network Load Balancer handles transport-level connection distribution, and Gateway Load Balancer enables appliance insertion. An SAA-C03 load-balancing case should specify the required protocol and failure behavior before selecting ALB, NLB or GWLB. Picking solely by the number of backends misses the decision.