Skip to content
AWS aws load-balancing 6 min read

Types of Elastic Load Balancers

Elastic Load Balancing (ELB) is the AWS service that spreads incoming traffic across many backend servers so no single server gets overwhelmed. But “ELB” is not one thing — it is a family of four different load balancers, each built for a different kind of traffic. Picking the right one matters because they speak different protocols, cost different amounts, and offer very different features. This page introduces all four so you know which name maps to which job.

The four types at a glance

The “layer” numbers below come from the OSI model (Open Systems Interconnection, a standard way of describing the layers of a network). Layer 7 is the application layer (HTTP, the language web browsers speak). Layer 4 is the transport layer (TCP and UDP, the raw connection protocols underneath HTTP). The higher the layer, the more the load balancer can “understand” about the traffic.

TypeShort nameOperates onTypical trafficStatus
Application Load BalancerALBLayer 7 (HTTP/HTTPS)Websites, REST APIs, microservicesCurrent — use for web traffic
Network Load BalancerNLBLayer 4 (TCP/UDP/TLS)High-throughput, low-latency, gaming, IoTCurrent — use for non-HTTP
Gateway Load BalancerGLBLayer 3 (IP packets)Third-party network appliancesCurrent — niche
Classic Load BalancerCLBLayer 4 and basic Layer 7Old EC2-Classic appsLegacy — avoid for new work

Application Load Balancer (ALB)

An ALB works at Layer 7, which means it can read the actual HTTP (HyperText Transfer Protocol, the protocol of the web) request — the URL path, the host name, the headers, and the HTTP method. Because it understands the request, it can make smart routing decisions: send /api/* to one group of servers and /images/* to another, or route shop.example.com and blog.example.com to different backends from a single load balancer.

When to use it: any HTTP or HTTPS application. This covers the vast majority of new projects — websites, REST and GraphQL APIs, and microservices behind a single entry point. It also terminates TLS (Transport Layer Security, the encryption behind HTTPS) for you, integrates with AWS WAF (Web Application Firewall) to block bad requests, and supports authentication via Amazon Cognito.

When NOT to use it: when your traffic is not HTTP — for example a database connection, a game server using UDP, or anything that needs the absolute lowest latency. Use an NLB for those.

Network Load Balancer (NLB)

An NLB works at Layer 4. It does not read the HTTP request; it just forwards raw TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) connections to your servers as fast as possible. Because it does less inspection, it is extremely fast and can handle millions of requests per second with very low latency. An NLB also gives you a static IP address per Availability Zone (a separate data center within a region), which is useful when a partner needs to allow-list a fixed IP.

When to use it: non-HTTP protocols (databases, message brokers, custom TCP/UDP services), workloads needing ultra-low latency or millions of connections per second, or when you specifically need a static IP for the load balancer itself.

When NOT to use it: when you want path-based or host-based routing, WAF protection, or other HTTP-aware features. The NLB cannot see the URL, so it cannot route on it — use an ALB instead.

Tip: A common modern pattern is an NLB in front of an ALB. The NLB gives you a static IP and raw speed at the edge, while the ALB behind it does the smart HTTP routing. You only need this when you genuinely need both a fixed IP and Layer 7 routing.

Gateway Load Balancer (GLB)

A GLB works at Layer 3 (IP packets) and exists for one specific job: transparently inserting third-party network appliances — firewalls, intrusion-detection systems, deep-packet-inspection tools — into the path of your traffic. It sends all traffic to a fleet of virtual appliances, lets them inspect or filter it, then returns it to the network. It uses a protocol called GENEVE on port 6081 to encapsulate the traffic.

When to use it: only when you are deploying virtual security or monitoring appliances (often from the AWS Marketplace) and need to scale them like a normal target group. Most application teams will never touch a GLB.

When NOT to use it: for plain web or application traffic. It is not a general-purpose load balancer.

Classic Load Balancer (CLB) — legacy

The CLB is the original load balancer from 2009. It does basic Layer 4 and a little Layer 7, but it lacks almost every modern feature: no path-based routing, no host-based routing, no native container/IP targets, and no integration with newer services. AWS keeps it running for old EC2-Classic accounts but actively steers everyone toward ALB and NLB.

Warning: Do not build anything new on a Classic Load Balancer. If you have an existing one, plan a migration to an ALB (for HTTP) or NLB (for TCP/UDP). New AWS accounts cannot even create CLBs in some regions.

Picking one — the short version

For almost every new project the decision is simple:

  • HTTP or HTTPS traffic? Use an ALB.
  • Raw TCP/UDP, ultra-low latency, or you need a static IP? Use an NLB.
  • Deploying third-party security appliances? Use a GLB.
  • Anything else / starting fresh? It is an ALB or an NLB — never a CLB.

For a deeper feature-by-feature breakdown, see the dedicated comparison page linked below.

Cost note

All ELBs charge a small hourly fee (roughly $0.0225 per hour, about $16 per month) plus a usage-based unit called an LCU (Load Balancer Capacity Unit) for ALB/NLB, billed on the highest of new connections, active connections, processed bytes, and rules evaluated. In practice a low-traffic ALB or NLB costs a few dollars a month; an idle one still costs the hourly fee, so delete load balancers you are not using.

Listing your load balancers with the CLI

You can see every ALB, NLB, and GLB in a region (the modern “v2” API covers all three) with one command.

aws elbv2 describe-load-balancers --query "LoadBalancers[].{Name:LoadBalancerName,Type:Type,DNS:DNSName}"

Output:

[
    {
        "Name": "web-alb",
        "Type": "application",
        "DNS": "web-alb-1234567890.us-east-1.elb.amazonaws.com"
    },
    {
        "Name": "stream-nlb",
        "Type": "network",
        "DNS": "stream-nlb-0a1b2c3d.elb.us-east-1.amazonaws.com"
    }
]

Classic Load Balancers use a separate, older API and are listed with aws elb describe-load-balancers (no v2). If that command returns nothing, you have none — which is the goal.

Best Practices

  • Default to an ALB for any HTTP/HTTPS workload; reach for an NLB only when you need raw TCP/UDP, extreme performance, or a static IP.
  • Never start a new project on a Classic Load Balancer; migrate any existing CLBs to ALB or NLB.
  • Use a GLB only for inline third-party security/inspection appliances, not for normal app traffic.
  • Always spread a load balancer across at least two Availability Zones for high availability.
  • Terminate TLS at the ALB (or NLB) so your backend servers do not each carry the encryption overhead.
  • Delete unused load balancers — they bill by the hour even with zero traffic.
Last updated June 15, 2026
Was this helpful?