What Is a Load Balancer? Understanding AWS Load Balancer Types

A load balancer is a system that distributes incoming network or application traffic across multiple healthy targets. Those targets may include virtual machines, containers, IP addresses, serverless functions, microservices, or network-security appliances.

Instead of exposing one application resource as the only destination for client requests, a load balancer creates a managed entry point. It evaluates each request or connection and forwards it to an eligible target according to health status, configured rules, protocol information, and the load balancer's operating model.

The architectural value extends beyond traffic distribution. Load balancing improves availability by routing around unhealthy targets, supports horizontal scalability by allowing capacity to be added or removed, and increases resilience by distributing workloads across multiple Availability Zones. It can also centralize TLS certificates, health checks, access logging, authentication, and security controls.

For technology leaders, the objective is operational continuity. A well-designed load-balancing layer reduces the likelihood that an instance failure, deployment issue, traffic spike, or localized infrastructure event will make an entire service unavailable.

Load balancers do not eliminate the need for resilient application design. If every target depends on the same failing database, external API, or configuration service, distributing requests will not resolve the underlying dependency failure. Load balancing must therefore be combined with redundancy, observability, autoscaling, controlled deployments, and tested recovery procedures.

Load balancers are commonly distinguished by the layer of the Open Systems Interconnection model at which they make traffic-distribution decisions.

Layer 4 load balancing

Layer 4 load balancing uses transport and connection information such as source and destination IP addresses, ports, and protocols. It is appropriate when the platform needs efficient TCP, UDP, or TLS connection handling without examining HTTP request content.

Layer 7 load balancing

Layer 7 load balancing understands application protocols. For HTTP-based services, it can inspect hostnames, URL paths, headers, methods, and query parameters before selecting a target. This enables one endpoint to support multiple applications, APIs, versions, tenants, or microservices.

Network-gateway-based distribution

A third model combines gateway functionality with load distribution for IP traffic. Rather than delivering conventional application requests, it inserts virtual appliances such as firewalls or inspection systems into a traffic path.

The correct model depends on four questions: Which protocols are involved? How much routing intelligence is required? What performance and addressing characteristics are mandatory? Where must security inspection and policy enforcement occur?

AWS Elastic Load Balancing automatically distributes traffic across registered targets, monitors their health, and routes traffic to targets considered healthy. Its principal modern options are Application Load Balancer, Network Load Balancer, and Gateway Load Balancer.

• Application Load Balancer: Layer 7 routing for HTTP, HTTPS, and gRPC.
• Network Load Balancer: Layer 4 handling for TCP, UDP, and TLS.
• Gateway Load Balancer: Transparent distribution of IP traffic across virtual appliances.

Classic Load Balancer is an earlier-generation service. It remains relevant mainly to legacy environments that already depend on it, but new designs should normally be evaluated against the modern load balancer types.

AWS recommends choosing a load balancer according to the application's protocol, routing, performance, and infrastructure requirements. Selecting by familiarity alone can create unnecessary cost, operational complexity, or missing capabilities.

An Application Load Balancer operates at Layer 7 and is designed for HTTP, HTTPS, and gRPC application traffic. Because it understands the request, it can make routing decisions using hostnames, paths, HTTP headers, request methods, query strings, and source IP conditions.

Requests for api.example.com can be routed to an API target group while portal.example.com is sent to a user-interface service. The path /billing/* can be forwarded to a billing microservice, while /accounts/* is handled by an identity or customer-domain service.

ALB is particularly effective for web applications, REST or GraphQL APIs, microservices, Kubernetes and Amazon ECS workloads, host-based routing, path-based routing, and multiple services sharing a common entry point.

Its targets may include EC2 instances, IP addresses, containers, and AWS Lambda functions. A Lambda-backed route can support lightweight serverless HTTP functionality without requiring a permanent server fleet.

ALB can centralize web-traffic controls. It supports TLS termination, integration with AWS WAF, and user authentication through compatible OpenID Connect identity providers or Amazon Cognito. Listener actions can also perform redirects and return fixed responses before traffic reaches application code.

From an operating-model perspective, this centralization can reduce duplicated routing and security logic across services. It can also make policies easier to audit because certificates, listener rules, WAF associations, and authentication configuration are managed at an explicit ingress layer.

A Network Load Balancer operates at Layer 4 and is designed for TCP, UDP, and TLS traffic. It makes forwarding decisions using connection-level information rather than HTTP request content.

NLB is suited to services that require high-throughput connection handling, low-latency transport, static entry-point addresses, Elastic IP addresses, non-HTTP protocols, or preservation of the client source IP.

Typical uses include real-time systems, messaging platforms, gaming services, telemetry ingestion, private service connectivity, database proxies, and applications that use custom TCP or UDP protocols.

NLB can terminate TLS or pass encrypted traffic through to targets. This gives architecture teams flexibility over where certificates and encryption responsibilities are managed.

An Application Load Balancer can also be registered as an NLB target. This pattern can combine NLB capabilities such as static addressing or PrivateLink connectivity with ALB Layer 7 routing.

A Gateway Load Balancer combines a Layer 3 network gateway with Layer 4 load balancing. It listens for IP packets and distributes traffic across a fleet of compatible virtual network appliances.

GWLB and its appliance targets exchange traffic through the GENEVE protocol on port 6081. GENEVE encapsulation allows the original packet and flow context to reach an appliance for processing before traffic continues through the architecture.

When to use a Gateway Load Balancer

• Centralized virtual firewalls
• Intrusion detection and prevention systems
• Deep packet inspection
• Traffic-monitoring appliances
• Security services shared across multiple VPCs
• Scalable insertion of third-party network appliances

A common enterprise pattern uses Gateway Load Balancer endpoints in application VPCs to steer traffic toward appliances hosted in a centralized inspection VPC. This can standardize inspection policies and reduce the operational overhead of deploying a separate appliance stack in every workload VPC.

The design still requires careful routing. Both directions of a flow must pass through the expected inspection path so that stateful appliances can maintain connection context. Transit Gateway appliance mode, route-table design, Availability Zone alignment, and failure behavior may all affect flow symmetry.

No AWS load balancer is universally superior. Each service gains its value by specializing in a particular architectural layer.

Application Load Balancer limitations

ALB is primarily for HTTP, HTTPS, and gRPC workloads. It is not appropriate for general UDP traffic or arbitrary non-HTTP protocols, and it does not provide the same static-addressing model as NLB. Its advanced Layer 7 rules can also add unnecessary complexity when a system only needs straightforward connection forwarding.

Network Load Balancer limitations

NLB does not offer ALB-style content routing based on hosts, paths, headers, methods, or query parameters. It does not provide ALB listener capabilities such as user authentication, redirects, fixed responses, or direct AWS WAF association. When application-layer decisions are required, teams may need an ALB or equivalent application component behind the NLB.

Gateway Load Balancer limitations

GWLB requires appliances that support GENEVE on port 6081. It is not designed to replace ALB or NLB for standard application delivery. Architecture teams must account for routing symmetry, appliance connection tracking, encapsulation overhead, MTU requirements, and failure behavior.

GWLB does not support IP fragmentation. AWS documentation specifies an 8,500-byte maximum transmission unit for GWLB traffic, and packets larger than that size are dropped. Teams must ensure that packet sizes and appliance interfaces are compatible with the encapsulated traffic path.

There are also operational trade-offs. ALB rule sets can become difficult to govern when many teams share one ingress. NLB's simpler routing may move more responsibility into applications. GWLB can improve security-service consistency but introduces additional routing domains, appliance licensing, capacity planning, and stateful-failover considerations.

A sound decision therefore considers total architecture cost rather than load-balancer pricing alone. Engineering effort, troubleshooting complexity, security operations, cross-zone traffic, observability, certificate management, and appliance costs may materially affect the outcome.

The selection should begin with the traffic and operating requirements rather than a preferred AWS service.

The design should also account for Availability Zones, cross-zone behavior, health checks, target registration, autoscaling, TLS ownership, logging, monitoring, deployment strategy, failure domains, and expected traffic growth.

A proof of concept should validate protocols, connection behavior, failover, routing rules, source-IP requirements, certificate handling, observability, appliance compatibility, and cost before production adoption.

Load balancing improves availability, scalability, and resilience by distributing traffic across healthy capacity, but the AWS load balancer types solve different architectural problems.

Application Load Balancer provides request-aware routing and centralized controls for HTTP, HTTPS, and gRPC applications. Network Load Balancer provides transport-level handling for TCP, UDP, and TLS workloads that require performance, static addressing, or private connectivity. Gateway Load Balancer provides transparent traffic distribution across compatible network-security appliances.

Technology leaders should select the service according to protocol, routing intelligence, addressing, performance, security, connectivity, availability, and operating-model requirements.

FAMRO helps organizations assess application protocols, availability objectives, routing models, security controls, PrivateLink requirements, and multi-VPC architectures before designing an AWS load-balancing solution.

🌐 Learn more: Visit Our Homepage

💬 WhatsApp: +971-505-208-240

AWS Elastic Load Balancing Documentation

AWS Application Load Balancer Documentation

AWS Network Load Balancer Documentation

AWS Gateway Load Balancer Documentation

AWS Prescriptive Guidance: Building a Scalable and Secure Multi-VPC Network Infrastructure