NLB pricing: why TLS listeners cost more (2026)

A Network Load Balancer (NLB) costs $0.0225 an hour to exist and $0.006 per NLCU-hour to use, in AWS's own US East examples. Those two numbers are the easy part of NLB pricing. The expensive part is one checkbox and one listener type: a TLS listener gets 33 times fewer active connections per NLCU than a TCP listener carrying the same traffic, and turning on cross-zone load balancing can add more per gigabyte than the NLCU charge itself.

How much does an AWS Network Load Balancer cost before any traffic arrives?

$16.20 a month, on the Elastic Load Balancing pricing page's 24-hours-times-30-days convention. The page states "You are charged for each hour or partial hour that a Network Load Balancer is running", and its first NLB example adds "the hourly charge of $0.0225" to a usage charge. That hourly charge does not wait for a connection.

An internet-facing NLB also consumes addresses. The NLB user guide says "The Network Load Balancer has one IP address per enabled Availability Zone", and the pricing page adds that "You will incur standard public IPv4 address charges for all the addresses you consume with load balancers." At the VPC pricing page's $0.005 per address-hour, three zones add $10.80, so an idle internet-facing NLB in three zones is $27.00 a month. The address side of that is covered in what public IPv4 addresses cost.

The hourly charge matches an Application Load Balancer's, and an NLCU is 25% cheaper than an ALB LCU. What an NLCU contains is where the two diverge.

What is an NLB LCU, and why does a TLS listener get so little of one?

An NLCU is three allowances, and the pricing page says "You are charged only on one of the three dimensions that has the highest usage for the hour." The TCP and UDP contents are compared against ALB in our ALB LCU pricing breakdown. The third protocol is the one that changes a bill:

The page defines the split by listener, not by what is on the wire: "TCP and UDP traffic refers to the traffic destined for any TCP/UDP listener on your Network Load Balancer while TLS traffic refers to the traffic destined for any TLS listener on your Network Load Balancer." Encrypted bytes arriving on a TCP listener are TCP traffic for billing.

The gap matters most for long-lived connections, where the active dimension binds. Hold 100,000 idle-ish connections open, as a fleet of devices or WebSocket clients does, and that is 1 NLCU on a TCP listener, $4.32 a month. On a TLS listener it is 33.33 NLCUs, $144.00 a month, for the same sockets.

Does a Network Load Balancer TLS listener cost more than TCP pass-through?

Yes, and AWS's own Example 2 shows it without saying so. It sends identical traffic to both listener types: "100 new TCP connections per second and 100 new TLS connections per second, each lasting three minutes and consuming 1,000 processed bytes." The TCP side bills on bytes at 0.36 NLCUs. The TLS side bills on active connections: "this translates to 18,000 active connections, or 6 NLCUs (18,000 active connections / 3,000 active connections)."

"$1.55 per month for TCP Traffic ($0.00216 * 24 hours * 30 days)"

"$25.92 per month for TLS traffic ($0.036*24*30)"

Same connections, same bytes, 16.67 times the NLCU charge. Moving that TLS traffic to a TCP listener would save about $24.36 a month on this example, and the NLB listener documentation describes exactly that configuration: "create a TCP listener on port 443 instead of creating a TLS listener. With a TCP listener, the load balancer passes encrypted traffic through to the targets without decrypting it."

The trade is real, not free. Pass-through moves the handshake cost onto your targets, and you lose certificate management on the load balancer. Two documented facts push the same way regardless of price. First, "Network Load Balancers do not support mutual TLS authentication (mTLS). For mTLS support, create a TCP listener instead of a TLS listener." Second, the NLB certificate page warns that a certificate imported into IAM is not validated when attached, and with an unsupported key size such as RSA 4096-bit "the listener will enter a non-functional state". It states that "For RSA certificates, the maximum supported key size for NLB TLS listeners is 3072-bit." Termination on the NLB is worth paying for when your targets cannot do TLS cheaply; it is not the default it looks like.

One arithmetic note on Example 2: AWS rounds the hourly total to "$0.060 per hour" and multiplies that, giving $43.20. The unrounded total is $0.06066 an hour, or $43.68 a month. Small, but it means the example's grand total does not equal the sum of its own parts.

Are Network Load Balancer NLCUs billed separately for TCP, UDP and TLS?

Yes. An ALB takes one maximum across its dimensions. An NLB takes one maximum per protocol and adds them. The ELB FAQ is explicit: "for each protocol you are charged only on one of the three dimensions (the highest for the hour)." Example 3 bills a TCP listener and a UDP listener on the same NLB at 0.36 NLCUs each, and charges both.

CloudWatch reports them the same way. The NLB metrics reference lists ConsumedLCUs_TCP, ConsumedLCUs_TLS and ConsumedLCUs_UDP alongside the total, and the per-protocol ActiveFlowCount_TLS and NewFlowCount_TLS tell you which TLS dimension is binding. If ConsumedLCUs_TLS dominates and ActiveFlowCount_TLS divided by 3,000 matches it, the TLS listener is the bill.

The same page lists NewFlowCount_QUIC, and the listener page lists QUIC and TCP_QUIC as supported protocols. The pricing page defines NLCU contents for TCP, UDP and TLS only, so we cannot state from AWS's pages how a QUIC listener is metered.

Does turning on NLB cross-zone load balancing add data transfer charges?

Yes. It is off by default, and turning it on adds EC2 data transfer charges. The NLB target group attributes page says "With Network Load Balancers, cross-zone load balancing is disabled by default at the load balancer level" and "When enabling cross-zone load balancing for a Network Load Balancer, EC2 data transfer charges apply." The FAQ gives the ALB contrast in one line: "Since cross-zone load balancing is always on with Application Load Balancer, you are not charged for this type of regional data transfer."

How much crosses depends on your layout. The target group attributes page explains that "When cross-zone load balancing is on, each load balancer node distributes traffic across the registered targets in all registered Availability Zones." Assume three zones with equal target counts: each node keeps a third of its traffic local and sends two thirds to other zones.

The regional rate appears in AWS's own CUR sample as "$0.010 per GB – regional data transfer in/out/between EC2 AZs or using elastic IPs or ELB in US East (N. Virginia)", in the AWS Networking blog on VPC peering charges. The CUR data transfer guide adds: "For a given resource, you're charged for both inbound and outbound traffic in a data transfer within an AWS Region."

On byte-bound traffic, the checkbox costs 1.11 to 2.22 times the NLCU charge it sits beside. For 1,000 GB a month that is $6.00 of NLCUs and $6.67 to $13.33 of cross-zone transfer, billed under EC2 rather than ELB, where nobody looking at the load balancer line will see it. The general mechanics are in cross-AZ data transfer cost.

It also has a quota side effect. The NLB quotas page says "If cross-zone load balancing is enabled, the maximum is 500 targets per load balancer, regardless of the number of Availability Zones." The cheaper fix for uneven zones is usually an equal target count per zone, which keeps the default off.

What does NLB LCU reservation cost at its 2,750 LCU minimum?

At least $16.50 an hour per zone. The NLB capacity reservation page sets the floor: "The total reservation request must be at least 2,750 LCU per Availability Zone." Pricing Example 4 prices reserved units at the on-demand rate, "Reserved LCU-hrs: $18.00 per hour ($0.006 * 3000 Reserved NLCU-hrs)", and bills usage above the reservation on top.

So a reservation is not a discount. In AWS's examples it buys a capacity floor at the same unit price, and the pricing page bills "the number of LCU reserved per minute" whether traffic reaches it or not. At the minimum, three zones cost $49.50 an hour, $1,188 a day. The capacity reservation page converts the unit: "each LCU being equal to 2.2Mbps", so 2,750 LCUs is about 6.05 Gbps per zone. Most of the use cases it lists are short, such as "an upcoming event that will have a sudden, unusual high traffic". Reserve for the event, not for the year.

What does a Network Load Balancer add when it fronts AWS PrivateLink?

A second bill, on the consumer's side. Per the PrivateLink endpoint service guide, "Endpoint services require either a Network Load Balancer or a Gateway Load Balancer." The provider pays the NLB meters above. Each consumer pays for an interface endpoint, which the PrivateLink pricing page bills "for each hour that your VPC endpoint remains provisioned in each Availability Zone", at "$0.01 per hour for each endpoint ENI" plus $0.01 per GB for the first petabyte. Three zones is $21.60 a month before data. How those endpoint charges accumulate is covered in what VPC endpoints actually cost.

The same guide notes that "Regional data transfer charges apply when you enable cross-zone load balancing", which is the provider's usual shortcut for zones without targets. And if the service is really an HTTP app, the FAQ's pattern of an ALB behind the NLB, "which provides support for PrivateLink and a static IP address per Availability Zone", means paying two hourly charges and two kinds of capacity unit for one service.

Is a Network Load Balancer free in AWS on the free tier?

AWS's own pages disagree. The FAQ still says "For new AWS accounts, a free tier for a Network Load Balancer offers 750 hours and 15 LCUs." The pricing page describes the same allowance without NLB in it: "750 hours per month shared between Classic and Application load balancers; 15 GB of data processing for Classic load balancers; and 15 LCUs for Application Load Balancers." It then adds that "Starting July 15, 2025, new AWS customers will receive up to $200 in AWS Free Tier credits". Neither page promises NLB hours to an account opened today in terms the other agrees with, so budget an NLB as billable from its first hour.

The FAQ is stale elsewhere too, which is worth knowing before trusting it on price. It says "Network Load Balancer only supports RSA certificates with 2K key size", while the certificate page lists ECDSA 256-bit, 384-bit and 521-bit keys. It says NLB "currently supports 200 targets per Availability Zone", while the quotas page lists 500.

Two neighbouring posts pick up where this one stops. An NLB in a VPC that reaches the internet through a NAT Gateway pays a second hourly network meter, covered in what a NAT Gateway costs. And because cross-zone transfer lands under EC2 rather than Elastic Load Balancing, finding it on the bill means breaking open EC2 - Other in Cost Explorer.

Putting an accelerator in front of the same load balancer adds a fixed hourly fee that bills whether or not anybody connects, plus a per-GB premium charged on top of normal data transfer rather than instead of it: AWS Global Accelerator pricing.