Choosing an AWS load balancer is not a contest between Application Load Balancer and Network Load Balancer feature lists. The decision starts with the traffic itself: which protocol the client speaks, where TLS should terminate, whether routing needs application context, whether source addresses must be preserved, how targets scale, and whether the “load balancer” is actually an insertion point for security appliances.
These distinctions are relevant to SAA-C03 because load balancing participates in resilient and high-performing design. A wrong choice can also create operational debt. Teams may compensate for a missing routing capability with custom proxies, or choose a low-level transport load balancer and later discover that the application needs host-based routing, authentication integration, or web-application controls.
The reusable method is to define the connection before selecting the service. Identify the client protocol, target protocol, required routing intelligence, security boundary, failure behavior, address requirements, and observability. Once those constraints are visible, the appropriate Elastic Load Balancing family usually becomes much clearer.
Application Load Balancer earns its place when HTTP semantics matter
An Application Load Balancer operates at the application layer for HTTP and HTTPS workloads. It can route requests using host names, paths, headers, methods, query strings, and other request attributes, which makes it well suited to web applications, APIs, container services, and architectures where several services share one entry point.
This capability is more than convenience. Routing at the HTTP layer can reduce the number of separate endpoints a platform needs and can make blue/green or service-by-service migration easier. It also means the load balancer becomes part of the application security boundary, because TLS termination, listener rules, authentication integrations, and web application firewall placement can affect how requests are trusted.
Network Load Balancer belongs where transport behavior is the requirement
A Network Load Balancer handles connections at the transport layer and is designed for very high performance with TCP, UDP, and TLS traffic. It is a strong fit when the protocol is not HTTP-aware, when the application requires a transport-level endpoint, or when static addressing and source-network behavior are more important than content-based routing.
The trade-off is that the load balancer cannot make decisions based on an HTTP path or host header in the way an ALB can. If the team chooses NLB only because “it is faster,” it may push application-routing logic back into targets or another proxy layer. Performance should be measured against the workload requirement, not assumed from the service name.
Gateway Load Balancer solves an appliance insertion problem
Gateway Load Balancer is different from the ordinary application-entry pattern. It is intended to distribute IP traffic across virtual appliances such as firewalls, intrusion-prevention systems, and deep-packet-inspection platforms. Traffic reaches appliances through a transparent network path using Gateway Load Balancer endpoints and route-table integration.
That makes GWLB an architecture tool for centralized or distributed inspection, not a substitute for an ALB in front of a web application. The distinction matters because the failure domain and operational ownership are different. A team using GWLB needs to reason about appliance health, symmetric flows, route-table dependencies, endpoint placement, and what happens to application traffic when the inspection fleet is degraded.
Health checks define what the platform considers safe traffic
Load balancing only improves availability if health checks represent the application’s ability to serve useful requests. A check that verifies a process is listening may stay green while the application has lost its database, exhausted a dependency pool, or cannot complete the transaction users actually need. A check that is too deep can create the opposite problem by removing healthy targets during a transient dependency issue.
The broader load-balancing model is therefore inseparable from health design. Target thresholds, deregistration delay, warm-up behavior, and application readiness determine whether traffic shifts smoothly or amplifies an outage. The check should answer a specific question: is this target safe to receive new work right now?
Availability Zone design matters after the load balancer is chosen
Elastic Load Balancing can distribute traffic to targets in multiple Availability Zones, but the architecture still needs sufficient healthy capacity in those zones. A load balancer cannot create resilience if all stateful dependencies sit in one zone or if the surviving targets lack headroom when another zone fails.
Capacity planning should test the reduced-zone condition. If one zone disappears, can remaining targets handle the load without triggering a cascade? The difference between high availability and fault tolerance helps frame the answer. Some systems tolerate brief degradation while capacity recovers; others need active redundancy that remains within service targets immediately.
TLS placement changes both trust and operations
TLS can terminate at the load balancer, pass through to targets in some designs, or be re-encrypted between the load balancer and application. Each choice changes certificate ownership, observability, compliance boundaries, and the ability to inspect or route application requests. Central termination simplifies certificate management, but sensitive environments may also require encryption on the backend connection.
The important question is where the organization wants the trust boundary. If the load balancer terminates TLS, it becomes a point where plaintext application traffic exists and where security controls may inspect requests. If TLS remains end to end, the application retains more control but some load-balancer features may no longer be available. The choice should be deliberate rather than inherited from a default template.
DNS and load balancing solve adjacent but different problems
DNS decides which endpoint name resolves for a client; a load balancer distributes traffic after the client reaches that endpoint. Route 53 routing policies and health evaluation can steer users between Regions or endpoints, while an ALB or NLB distributes traffic among targets inside the selected architecture. Treating DNS failover and load balancing as the same mechanism can create slow or confusing recovery behavior.
The interaction with Amazon Route 53 becomes important for multi-Region applications. DNS TTLs, resolver caching, endpoint health, and failover policy determine how quickly clients move, while the regional load balancer handles local target health. Resilience depends on both layers behaving as expected.
Operational evidence should determine whether the choice still fits
After deployment, watch the metrics that reflect the chosen architecture: healthy target count, target response time, rejected or reset connections, HTTP status patterns, TLS errors, connection volume, processed bytes, and application-level latency. Logs should let operators trace a user request through the load-balancing boundary without guessing which target received it.
Architects preparing for AWS Certified Solutions Architect – Associate should carry forward one framework: protocol, routing intelligence, security boundary, availability, addressing, and observability. ALB is usually the natural choice when HTTP context drives routing, NLB when transport behavior drives the requirement, and GWLB when virtual appliances must sit in the traffic path. The correct answer changes when the constraint changes.
Target type is another practical constraint. Depending on the load balancer and target group, targets may be instances, IP addresses, containers reached through those abstractions, or other supported endpoints. This affects how the load balancer reaches workloads across VPC and service boundaries. It also affects health-check ownership and whether an application can move between compute platforms without changing the public entry point.
Client source information deserves explicit treatment. Some architectures need the original client IP for policy, logging, or fraud analysis, while others are comfortable using forwarded headers or proxy-protocol style metadata. The mechanism varies with the load balancer and protocol. If downstream security rules assume the transport source address will always be the end user, the design can break when a proxy or load-balancing layer is inserted.
Cross-zone behavior and zonal capacity should be reviewed together. Distributing traffic evenly does not guarantee each zone has enough healthy targets, and uneven target placement can create surprising data paths or costs. During a zone failure, the remaining zones need both load-balancer reachability and application capacity. Architects should model the reduced-zone condition rather than assume the managed load balancer makes every dependency multi-zone automatically.
Application-layer controls can also make ALB the natural enforcement point. Web application firewall integration, HTTP redirects, header-based routing, and authentication-related patterns can simplify the edge architecture. Those features are useful only when the organization wants the load balancer to own that responsibility. If another gateway or service already owns it, duplicating the control can create inconsistent policy and harder troubleshooting.
Cost should be modeled from traffic behavior, not only from the hourly presence of a load balancer. Connection volume, processed bytes, rule evaluation, and other dimensions vary by family and workload. A design with many small services behind shared routing may have a different economic profile from one with sustained high-throughput TCP streams. The cheapest service on a quiet test environment may not remain cheapest after production traffic and cross-zone patterns appear.
Migration strategy also matters when changing load-balancer families. An application that moves from NLB to ALB, or the reverse, may change endpoint addresses, TLS behavior, health checks, security-group relationships, logging, and client-IP handling. The safest migration exposes both paths long enough to compare behavior and move traffic deliberately. Treating the load balancer as a replaceable front door is easier when DNS, certificates, target registration, and observability are already automated.
IPv6 and dual-stack requirements should be included early as well. A public endpoint that must serve both address families may require different subnet and security assumptions from an IPv4-only design. Client networks, allow lists, logging pipelines, and backend targets should be tested with both families. The load-balancer selection is correct only if the entire connection path supports the address model the service promises.
Private and internal load balancers should be reviewed with the same care as internet-facing ones. Internal endpoints can become shared trust boundaries between applications, accounts, or network segments. Security groups, listener configuration, target registration, and DNS naming should reflect which callers are actually authorized, rather than assuming that private addressing alone makes the service trusted.
