ALB vs NLB: Every Difference, Why an ALB Has No Static IP (and the Two Fixes), Pricing, Timeouts, Client IPs, PrivateLink, and Which AWS Load Balancer to Pick

An Application Load Balancer (ALB) understands web traffic: it works at Layer 7, reads HTTP and HTTPS requests, and routes them by path, host name or header to EC2 instances, containers, IP addresses or Lambda functions. A Network Load Balancer (NLB) works at Layer 4: it forwards TCP, UDP and TLS connections without reading them, handles very high connection rates, and gives you one fixed IP address per Availability Zone, which you can make your own Elastic IPs. That last point is the one people search for: an ALB has no static IP, so if a partner or firewall needs to allowlist your IPs, put an NLB in front of the ALB (an NLB can target an ALB directly) or use AWS Global Accelerator. In US East (N. Virginia) both cost $0.0225 an hour, plus $0.008 per LCU-hour for an ALB and $0.006 per NLCU-hour for an NLB, and for ordinary web traffic an NLB's capacity unit covers far more connections. Below: every difference in one table, when to pick which, the static-IP fixes, pricing math, timeouts, client IPs, PrivateLink, and the mistakes that cause 502s and dropped connections.

Jake's computer shop runs its booking website on two EC2 instances behind an ALB. It had worked for a year without anyone thinking about it. Then a card-payment partner sent a new requirement: "Send us the IP addresses your server uses, and we will allowlist them." Jake opened the load balancer, looked for an IP address, and found only a long DNS name. Ethan, his developer friend, explained why there was no IP to give, and what to change so there would be.

New to load balancers? A load balancer is the front door that spreads incoming traffic across several servers, so no single server is overloaded and one failing server does not take your site down. The Auto Scaling explainer covers the fleet of servers behind it.

ALB vs NLB in plain English

Think of the two as two kinds of receptionist. The ALB opens every letter. It reads the HTTP request (the web address, the host name, the headers, the cookies) and decides where it goes based on what it says: /api/* to the API servers, /images/* to the image service, shop.example.com to one group and admin.example.com to another. Because it reads requests, it can also do web jobs on the way: end HTTPS, check a login, block attacks with AWS WAF, send back a fixed response or a redirect.

The NLB does not open the letters. It looks at the envelope (the IP address and port) and passes the connection to a healthy target as fast as possible. Because it does less, it handles more: very high connection rates, long-lived connections, and protocols that are not HTTP at all, such as game traffic, IoT devices, mail, databases, or anything over UDP. It is also the load balancer with fixed IP addresses, and the one that AWS PrivateLink requires.

There is a third type, the Gateway Load Balancer (GWLB), which sends traffic through security appliances such as third-party firewalls. You only need it for that job, and it is not what most people mean by "which load balancer," so this page focuses on ALB and NLB. The Classic Load Balancer is the older generation; new designs use ALB or NLB.

Jake: "So the ALB is smart and the NLB is fast?"

Ethan: "The ALB understands websites. The NLB moves connections without caring what is in them. Our booking site is a website, which is why it has an ALB."

Every difference in one table

Two rows surprise people. First, NLBs now support security groups, so "NLB has no security group" is outdated advice; you can control what reaches the NLB itself. Second, both support WebSockets: an NLB simply passes the long-lived TCP connection through, while an ALB understands the upgrade from HTTP.

When to use an ALB, and when to use an NLB

Most choices come down to one question: does your traffic speak HTTP, and do you need anything that requires reading it?

Use an ALB when:

• You run a website, a web app or a REST or gRPC API.
• You want one load balancer to route to several services by path or host name, which is the usual setup for microservices and containers on ECS or EKS.
• You want AWS WAF in front of the app, user login at the load balancer, redirects from HTTP to HTTPS, or fixed responses for maintenance pages.
• You want to call Lambda functions from a URL without API Gateway.

Use an NLB when:

• The traffic is not HTTP: game servers, IoT, VoIP and other UDP traffic, MQTT, SMTP, databases, custom TCP protocols.
• You need fixed IP addresses, for allowlists in partners' firewalls or for DNS records that must point at IPs.
• You need extreme connection rates or very long-lived connections.
• You want to offer a service to other VPCs or accounts through AWS PrivateLink; endpoint services sit behind an NLB.
• Your targets must see the client's original IP address at the network level, without reading a header.

Use both when you need the ALB's web features and the NLB's fixed IPs, which is exactly Jake's case. The next section shows how.

Jake: "Can I just switch the booking site to an NLB to get the fixed IPs?"

Ethan: "You'd lose the HTTPS redirect, the path routing and the WAF rules. Better to keep the ALB and put an NLB in front of it."

Static IPs: why an ALB has none, and the two fixes

An ALB scales by adding and replacing the machines behind its DNS name, and its IP addresses change as it does. That is why AWS gives you a DNS name for it and no IP: anything that points at the IPs directly would break the next time they change. An NLB is built differently: it has one IP address per enabled Availability Zone, and those addresses stay the same for the life of the load balancer. For an internet-facing NLB, you can bring your own Elastic IP addresses, one per subnet, when you create it, so the addresses are yours to keep and publish.

If you need fixed IPs for a web app, you have two good options.

Option 1: an NLB in front of the ALB. An NLB can use an Application Load Balancer as its target, so traffic arrives at the NLB's fixed IPs and is passed straight to the ALB, which does everything it did before. You give the partner the NLB's Elastic IPs. Steps:

1. Allocate one Elastic IP per Availability Zone your ALB uses (EC2 → Elastic IPs → Allocate).
2. Create a target group of type Application Load Balancer, protocol TCP, port 443, and register your ALB in it.
3. Create an internet-facing NLB in the same subnets, and in each subnet mapping choose Use an Elastic IP address with the IPs from step 1.
4. Add a TCP listener on port 443 that forwards to the ALB target group (add port 80 the same way if you redirect HTTP).
5. Point your DNS at the NLB, and send the partner the Elastic IPs.

The NLB passes the TLS connection through to the ALB, so your HTTPS certificate stays on the ALB and nothing else in the app changes. You pay for both load balancers, but the NLB's part for a small site is mostly its hourly charge.

Option 2: AWS Global Accelerator. Global Accelerator gives you two static anycast IP addresses that route users over AWS's network to your ALB (or NLB) in one or more Regions. It is the better fit when you serve users worldwide, want faster failover between Regions, or need IPs that stay the same even if you rebuild the load balancer. It costs more than an NLB, with a fixed hourly fee plus data charges.

A note on the other direction. If the partner wants to know the IP your servers call out from (to your payment API, for example), that is not the load balancer at all. Outbound traffic from private subnets leaves through a NAT gateway, and its Elastic IP is the address to give. Ask the partner which direction they mean; mixing these up is the most common reason "we sent the IPs and it still fails."

Build the NLB-in-front-of-ALB setup with the AWS CLI

If you prefer commands to clicking, here is the same setup in five steps. Replace the IDs with your own; the ALB, its subnets and its VPC must already exist.

# 1. One Elastic IP per Availability Zone
aws ec2 allocate-address --domain vpc
aws ec2 allocate-address --domain vpc

# 2. The NLB, with an Elastic IP in each public subnet
aws elbv2 create-load-balancer --name booking-nlb --type network --scheme internet-facing \
  --subnet-mappings SubnetId=subnet-aaa111,AllocationId=eipalloc-111 SubnetId=subnet-bbb222,AllocationId=eipalloc-222

# 3. A target group whose target is the ALB
aws elbv2 create-target-group --name booking-to-alb --target-type alb \
  --protocol TCP --port 443 --vpc-id vpc-0123456789abcdef0

# 4. Register the ALB in it
aws elbv2 register-targets --target-group-arn TARGET_GROUP_ARN --targets Id=ALB_ARN

# 5. A TCP listener on 443 that forwards to the ALB
aws elbv2 create-listener --load-balancer-arn NLB_ARN --protocol TCP --port 443 \
  --default-actions Type=forward,TargetGroupArn=TARGET_GROUP_ARN

Repeat steps 3 to 5 for port 80 if your ALB redirects HTTP to HTTPS. When the target group shows the ALB as healthy, test the site through one of the Elastic IPs, then move your DNS record to the NLB. The ALB keeps its own listeners, certificates, rules and WAF exactly as they were.

How to find your NLB's IP addresses

For an NLB, the IPs are easy to see. Each Availability Zone has one, and the load balancer's DNS name resolves to all of them:

# Linux or Mac
dig +short my-nlb-1234567890abcdef.elb.us-east-1.amazonaws.com

# Windows
nslookup my-nlb-1234567890abcdef.elb.us-east-1.amazonaws.com

Each zone also has its own DNS name, which starts with the zone, for example us-east-1a.my-nlb-1234567890abcdef.elb.us-east-1.amazonaws.com. In the console, the Elastic IPs show in the NLB's network mapping, and you can also find them in EC2 → Network Interfaces, filtered by the load balancer's name.

Running the same lookup on an ALB also returns IP addresses, but they are only a snapshot of today's addresses. Do not hand those to anyone as permanent.

Set up an ALB for a website, with HTTPS and the redirect

For anyone building the web side from scratch, this is the standard ALB setup for a site on EC2, in the console. It takes about fifteen minutes.

1. Get a certificate. In AWS Certificate Manager, request a free public certificate for your domain and validate it with DNS. Our ACM guide walks through it.
2. Create a target group. EC2 → Target Groups → Create. Type Instances, protocol HTTP, port 80 (or your app's port), health check path such as /health. Register your instances.
3. Create the ALB. EC2 → Load Balancers → Create → Application Load Balancer. Internet-facing, at least two Availability Zones with public subnets, and a security group that allows ports 80 and 443 from the internet.
4. Add an HTTPS listener on port 443 with your ACM certificate, forwarding to the target group.
5. Add an HTTP listener on port 80 whose action is Redirect to HTTPS, port 443, status 301. Visitors who type http:// now land on the secure site.
6. Lock down the instances. Change the instances' security group so ports 80 and 443 accept traffic only from the ALB's security group, not from the whole internet. Our security group guide shows how to reference one group from another.
7. Point DNS at the ALB. In Route 53, use an alias record for your domain pointing to the load balancer.

Step 6 is the one people skip, and it matters: with it, nobody can bypass the load balancer (and its WAF rules) by hitting an instance's public address directly.

ALB routing rules, by example

The ALB's listener rules are where it earns its keep. Each rule has conditions and an action, and the ALB checks them in priority order, lowest number first, falling back to the default action if nothing matches. A few patterns cover most needs:

Forward actions can also split traffic by weight between two target groups, for example 90% to the current version and 10% to a new one, which is a simple way to test a release on real visitors. Keep the number of rules sensible: each request's first 10 rule evaluations are free, and very long rule lists add to LCU usage and make behavior harder to reason about.

Sudden traffic spikes and capacity reservations

Both load balancers scale automatically, so for most sites you never think about capacity. The exception is a sudden, very large spike: a flash sale, a ticket launch, a TV mention. A load balancer that has been quiet all week grows to meet the load quickly, but not instantly.

For a known event, both ALBs and NLBs let you reserve capacity units ahead of time. You set a minimum number of LCUs (or NLCUs), the load balancer is ready for that level before the traffic arrives, and you pay for the reserved units at the normal rate while the reservation is in place, plus any usage above it. Book the reservation before the event and remove it after.

The "NLB is faster" reputation comes from what each one does per connection. An NLB does not read requests, so it adds very little delay and handles enormous connection counts. An ALB reads and routes every request, which costs a little time but is what gives you path routing, WAF and the rest. For a normal website, the ALB's extra delay is small next to the time your app takes to answer; choose by features, not by speed, unless you run something latency-critical such as a game server.

Pricing: what each one costs

Both load balancers have the same hourly charge in US East (N. Virginia), $0.0225 an hour, about $16.43 for a 730-hour month. The difference is in the capacity units, and in what one unit covers.

You pay for whichever dimension uses the most units in each hour. For an NLB, UDP and TLS have their own lower limits per unit (UDP: 400 new flows a second and 50,000 active a minute; TLS: 50 new connections a second and 3,000 active a minute), so TLS-heavy NLB traffic costs more per connection than plain TCP.

A worked example. Jake's booking site processes about 5 GB a day, around 0.2 GB an hour, with modest connection numbers. Bytes are its biggest dimension, so it uses well under one LCU on average:

• ALB: $16.43 a month for the hours, plus roughly 0.2 LCU × 730 hours × $0.008 = about $1.17, so about $17.60 a month.
• Adding an NLB in front for static IPs: another $16.43 a month for its hours, plus a similar small NLCU charge, so roughly $34 a month for both.

Two more costs are easy to miss. Public IPv4 addresses are billed separately, and an internet-facing load balancer uses at least one per Availability Zone. And data between Availability Zones can cost money when an NLB's cross-zone balancing is on. New AWS accounts on the free tier get 750 hours a month of ALB or Classic Load Balancer time and 15 LCUs, which covers a small test setup.

The biggest load balancer bill is usually the one nobody uses: a forgotten ALB still costs about $16 a month for its hours alone. Our idle load balancer guide shows how to find them.

ALB or API Gateway for an API?

If you are building an API, there is a third option to weigh: Amazon API Gateway. It is not a load balancer, but it often does the same job for APIs, and people compare it with the ALB all the time.

• API Gateway charges per request (about $1.00 per million for HTTP APIs and $3.50 per million for REST APIs in US East, at the first pricing tier), with no hourly fee. It adds API features: API keys and usage plans, throttling per client, request validation, and caching on REST APIs. It suits APIs with uneven or low traffic, and APIs built on Lambda.
• The ALB charges by the hour plus capacity units, with no per-request fee. It suits steady, high traffic, where per-request pricing adds up, and apps running on EC2 or containers that are already behind a load balancer.

A rough rule: below a few million requests a month, API Gateway is usually cheaper and gives you more API features; at sustained high volume, the ALB's flat pricing tends to win. Both can call Lambda functions, and both work with AWS WAF.

Load balancers for containers: ECS and EKS

Containers are where most new ALBs and NLBs live, and both orchestrators wire them up for you.

• Amazon ECS: when you create a service, you attach it to a target group, and ECS registers and removes tasks as they start and stop. With Fargate or awsvpc networking, each task gets its own IP, so the target group type is IP. One ALB can front many services with path or host rules, which keeps costs down compared with one load balancer per service.
• Amazon EKS: the AWS Load Balancer Controller creates load balancers from Kubernetes objects. An Ingress becomes an ALB with routing rules, and a Service of type LoadBalancer becomes an NLB. Annotations on those objects choose the scheme, the subnets, the certificate and the target type.

The same choice applies inside a cluster as outside: HTTP services behind an ALB, everything else (and anything needing fixed IPs) behind an NLB.

Seeing the real client IP behind each one

Your app often needs the visitor's real IP address, for logs, rate limits or fraud checks. The two load balancers deliver it differently.

• ALB: the target sees the ALB's address as the source, and the visitor's IP arrives in the X-Forwarded-For header. Configure your web server or framework to trust that header from the ALB and log it. In Nginx, that is the real_ip module; in Apache, mod_remoteip; most frameworks have a "trust proxy" setting.
• NLB: with instance targets, the target sees the client's IP directly, as if there were no load balancer. With IP targets, check the target group's client IP preservation setting, or turn on Proxy Protocol v2, which adds a small header with the original address that your server must be configured to read.

One consequence surprises people with NLBs: when the client IP is preserved, your targets' security groups must allow traffic from the clients' IP ranges (for a public site, from anywhere on the listener port), not just from the load balancer. If targets refuse connections after you move from an ALB to an NLB, check this first.

Jake: "Our logs show the same IP for every customer."

Ethan: "That's the ALB's address. The customer's real IP is in X-Forwarded-For. We need to tell the web server to log that instead."

Timeouts and long-lived connections

Idle timeouts close connections that have been silent for too long, and they explain many "random" disconnects.

• ALB: default idle timeout 60 seconds, which you can change. If a request takes longer than that with no data flowing, the client gets an error. Long reports, slow exports and WebSockets with no traffic hit this first; raise the timeout or send keepalive data. Our ALB 502 vs 504 guide covers what each timeout error means.
• NLB, TCP: 350 seconds by default, changeable from 60 to 6,000. After it passes, the next packet gets a TCP reset. Clients and targets can send TCP keepalives to restart the clock. If you set it above 350, also raise the connection-tracking timeout on your targets' network interfaces to at least the same value, or the target side can drop the connection first.
• NLB, TLS listener: 350 seconds, fixed. When it sees keepalives, the NLB sends its own every 20 seconds on both sides.
• NLB, UDP: 120 seconds, fixed. After that, a new packet is treated as a new flow and may go to a different target, which matters for stateful UDP protocols.

Also, an NLB needs your targets to answer a new connection within 30 seconds to set up the return path.

Cross-zone load balancing and uneven traffic

A load balancer has a node in each Availability Zone. With cross-zone load balancing on, each node spreads traffic across targets in every zone; with it off, each node only uses targets in its own zone.

On an ALB, cross-zone balancing is on, so traffic spreads evenly across all healthy targets whatever zone they are in. On an NLB, it is off by default. That causes a classic problem: one instance in zone A and three in zone B means the zone A instance takes half of all traffic, because DNS sends clients evenly to the two zones' IPs. Either keep the same number of targets in each zone, or turn on cross-zone load balancing for the NLB or its target group, knowing that traffic crossing zones can add data transfer charges.

NLBs can also steer DNS toward the client's own zone (full or 85% zonal affinity), and support zonal shift to move traffic away from a zone that is having trouble. Those are advanced settings; for most sites, even targets per zone or cross-zone on is enough.

PrivateLink: why it needs an NLB

If you want to offer a service to other VPCs or other AWS accounts privately, without peering or the internet, you publish it as a VPC endpoint service with AWS PrivateLink. The service must sit behind a Network Load Balancer (or a Gateway Load Balancer for appliance traffic). An ALB alone cannot be an endpoint service.

If your service is a web app behind an ALB, the same trick as for static IPs works: an NLB with the ALB as its target, published as the endpoint service. Consumers then reach it through an interface endpoint in their own VPC. Our VPC endpoint and PrivateLink guide covers the costs on the consumer side.

Health checks: the setting that decides who gets traffic

Both load balancers send traffic only to targets that pass health checks, and most "the load balancer is broken" problems are really failing health checks.

• An ALB checks a path you choose over HTTP or HTTPS, such as /health, and expects a success code (200 by default). Make the health path cheap and independent of slow dependencies, or a slow database marks every server unhealthy at once.
• An NLB can check over TCP (can it connect?), HTTP or HTTPS. A TCP check only proves the port is open, not that the app works, so use an HTTP check when you can.
• Targets' security groups must allow the health checks from the load balancer, on the health check port. A missing rule is the most common reason every target shows unhealthy.

If containers on ECS keep failing their checks, our ECS health check guide goes through the causes in order.

Common mistakes, and what they look like

Giving a partner the ALB's current IPs

They work today and break when the ALB scales. Use an NLB with Elastic IPs in front, or Global Accelerator, and give out those addresses.

Moving an HTTP app to an NLB and losing features

An NLB cannot route by path, redirect HTTP to HTTPS, attach WAF or check logins. Keep the ALB for those and add an NLB only for what it does better.

Targets refuse connections behind a new NLB

With client IP preservation, traffic arrives from the clients' addresses, not the load balancer's. Allow the client ranges on the targets' security groups for the listener port, plus the health check traffic.

One instance overloaded behind an NLB

Cross-zone load balancing is off by default, so each zone's IP gets an equal share. Balance targets across zones or turn on cross-zone.

Long requests fail at exactly 60 seconds

That is the ALB's default idle timeout. Raise it, or make the work asynchronous so the request returns quickly.

Connections reset after a few quiet minutes on an NLB

The TCP idle timeout (350 seconds by default) expired. Use TCP keepalives or raise the timeout, and match the targets' connection-tracking timeout.

502 errors from an ALB

The target closed the connection or sent an invalid response. Our ALB 502 vs 504 guide walks through the causes; a backend keepalive timeout shorter than the ALB's idle timeout is a common one.

Frequently asked questions

On Monday, Ethan put an NLB with two Elastic IPs in front of the booking site's ALB, sent the two addresses to the payment partner, and moved the DNS record. The site looked exactly the same to customers. The partner allowlisted the IPs on Tuesday, and card payments went live on Wednesday. "Two IP addresses," Jake said, "and all it cost was another load balancer." "And sixteen dollars a month," said Ethan.

Revision note. Written October 19, 2026. "The right tool for the right job," as the saying goes; with load balancers, sometimes the right job needs two tools, one in front of the other.