For most teams, network load balancer pricing looks deceptively simple on the AWS pricing page and then shows up as a line item nobody fully understands on the monthly bill. A Network Load Balancer, or NLB, is one of the cheapest components in an AWS architecture to launch and one of the easiest to misjudge over time, because its cost is driven less by a flat fee and more by how your traffic behaves.
This guide breaks down exactly what you pay for when you run an NLB, how the capacity unit model works, where the hidden charges hide, and how NLB compares with the other load balancers in the Elastic Load Balancing family. It is written for the people who sign off on architecture and budgets: CTOs, DevOps engineers, cloud architects, founders, and engineering managers who want a precise mental model rather than a vague estimate.
What a Network Load Balancer Is, and Why Its Pricing Trips People Up
A Network Load Balancer operates at Layer 4 of the network stack, distributing TCP, UDP, and TLS traffic rather than inspecting HTTP requests. It is built for raw performance, capable of handling millions of requests per second at very low latency, and it can preserve source IP addresses and expose static or elastic IPs. It is also the technology that backs AWS PrivateLink endpoint services.
Because NLB works below the application layer, it does not do content based routing, header inspection, or rule evaluation the way an Application Load Balancer does. That simplicity is exactly why it is fast, and it is also why its pricing feels different. There is no per rule cost, but there is a subtle and often expensive twist around encrypted traffic and cross zone data movement that catches teams off guard.
The confusion usually comes from three places: people assume the flat hourly fee is most of the bill, they forget that TLS termination consumes capacity units far faster than plain TCP, and they overlook the data transfer charges that ride alongside the load balancer itself. We will address all three.
Features That Influence What You Pay
A few NLB capabilities map directly to cost, so it helps to know them before you design an architecture around one:
- Static and elastic IP addresses give you fixed entry points, which is a major reason to pick NLB, but public IPv4 addresses now carry an hourly charge per address.
- Source IP preservation and Layer 4 passthrough keep the load balancer simple and cheap, since there is no request parsing or rule evaluation happening.
- Optional TLS termination is convenient, but as the examples below show, it is the single biggest driver of capacity unit consumption.
- PrivateLink integration lets you expose a service to other accounts through the NLB, which shifts some charges to the consumers of that service.
The Two Components of Network Load Balancer Pricing
Every NLB bill is the sum of a fixed hourly charge and a variable usage charge measured in capacity units. Keeping these two mentally separate is the single most useful habit for reasoning about cost.
The Fixed Hourly Charge
You pay for every hour or partial hour that the NLB exists, whether or not it serves a single byte. In most US regions this is around $0.0225 per hour, which works out to roughly $16 to $17 per month per load balancer. Some regions run slightly higher, closer to $0.0252 per hour. Partial hours are billed as full hours.
The practical lesson: an idle NLB is not free. A load balancer with no targets, only unhealthy targets, or zero traffic still charges the full hourly rate. In sprawling accounts this is one of the most common sources of quiet waste.
The Variable NLCU Charge
The usage charge is measured in Network Load Balancer Capacity Units, or NLCUs, billed at roughly $0.006 per NLCU hour. An NLCU is not a single metric. It is a bundle of allotments across three traffic dimensions, and AWS charges you for whichever dimension you consume the most of in a given hour, averaged over that hour.
This “highest dimension wins” rule is the heart of the model. You are never charged for all three dimensions at once. You are charged for the one that peaks. That means a workload can be limited by connections in one hour and by bytes in another.
What the AWS Free Tier Covers
New AWS accounts get a shared Elastic Load Balancing free tier, historically around 750 hours of load balancer usage per month plus a data or capacity allowance, spread across the load balancer family rather than granted separately per type. AWS has also introduced a broader credit based free tier for new accounts that can offset early load balancer costs. This is useful for prototypes and low traffic sites in the first year, but it disappears quickly once you run multiple load balancers or move real production traffic. Treat it as a starting cushion, not a long term discount.
How NLCUs Are Measured: The Three Dimensions
Each NLCU includes a fixed allotment of capacity in each dimension. Crucially, those allotments differ sharply between plain TCP or UDP traffic and encrypted TLS traffic. The table below shows the standard allotments per NLCU.
| Dimension | What it measures | TCP allotment per NLCU | TLS allotment per NLCU |
| New flows | Newly established connections per second | 800 per second | 50 per second |
| Active flows | Peak concurrent connections, sampled per minute | 100,000 per minute | 3,000 per minute |
| Processed bytes | Data moved through the load balancer | 1 GB per hour | Lower than TCP per NLCU |
Read this table carefully, because it explains most surprise bills. A single NLCU covers 800 new TCP connections per second but only 50 new TLS connections per second. That is a sixteen fold difference. The moment you terminate TLS on the NLB, your capacity unit consumption on the connection dimensions can jump by more than an order of magnitude for the same number of clients.
UDP traffic is metered in the same style as TCP, with its own allotments that sit close to the TCP levels. The takeaway is not the exact UDP number but the pattern: unencrypted Layer 4 traffic is cheap per connection, and TLS termination is where NLCUs accumulate quickly.
Worked Examples: Turning Traffic Into a Bill
Abstract rates are hard to reason about, so here are two realistic scenarios. Figures use approximate US pricing and are meant to show the shape of the calculation, not an exact invoice.
Example 1: A Low Traffic TCP Service
Imagine an internal service behind an NLB that averages a few new TCP connections per second, holds a few hundred concurrent connections, and moves about 1 GB of data per hour at peak.
- New flows: a handful per second against an 800 per second allotment is a tiny fraction of one NLCU.
- Active flows: a few hundred against 100,000 per minute is again a fraction of one NLCU.
- Processed bytes: about 1 GB per hour against the 1 GB allotment is roughly one NLCU.
The bytes dimension is the highest, so you are billed for roughly one NLCU per hour. That is about $0.006 per hour on top of the $0.0225 hourly charge, or close to $22 per month all in. For this kind of workload, the fixed hourly fee dominates and usage is almost a rounding error.
Example 2: A TLS Heavy Mobile Backend
Now imagine a mobile API behind an NLB terminating TLS, receiving 100 new TLS connections per second, each lasting a few minutes, with modest data per connection.
- New TLS flows: 100 per second against a 50 per second allotment is about 2 NLCUs.
- Active TLS flows: roughly 18,000 concurrent against a 3,000 per minute allotment is about 6 NLCUs.
- Processed bytes: modest, well under one NLCU.
Here the active TLS connection dimension dominates at around 6 NLCUs, so you pay for 6 NLCUs per hour rather than a fraction of one. That is roughly $0.036 per hour in usage, and the same traffic served as plain TCP would have cost a fraction of that. This is the single most important pricing insight for NLB: terminating TLS at the load balancer is convenient, but it changes your cost profile dramatically.
The Hidden Costs Behind Network Load Balancer Pricing
The hourly and NLCU charges are only the load balancer line item. Several related charges appear elsewhere on the bill and are easy to attribute to the wrong service.
Cross Zone Load Balancing and Cross AZ Data Transfer
This is the NLB specific cost that surprises the most people. By default, cross zone load balancing is turned off on an NLB, which means each load balancer node only sends traffic to targets in its own Availability Zone. When you enable cross zone load balancing so traffic can reach targets in any zone, the data that crosses zone boundaries is billed as inter Availability Zone data transfer, typically around $0.01 per GB in each direction.
This matters because Application Load Balancers include cross zone load balancing for free, while NLB charges for the cross zone data movement. For high throughput workloads, enabling cross zone balancing on an NLB can add a real, ongoing cost that is invisible until you read the data transfer section of your bill.
Public IPv4 Address Charges
AWS now charges for public IPv4 addresses at roughly $0.005 per hour per address, which is about $3.60 per month each. An internet facing NLB uses public IPs across its zones, so every public IPv4 it holds adds to the bill. This is small per address but multiplies across many load balancers and many zones.
TLS Termination Overhead
As the second worked example showed, TLS termination consumes NLCUs far faster than plain TCP because the per NLCU allotments for TLS connections are much smaller. If you can terminate TLS at the application tier or push encrypted passthrough where appropriate, you may lower NLCU consumption. This is an architectural tradeoff, not a pure cost decision, but it belongs in the conversation.
Data Transfer and PrivateLink
Standard AWS data transfer rules still apply to traffic flowing through the load balancer. Internet egress runs at standard rates, commonly in the range of $0.05 to $0.09 per GB depending on volume and region. If you use the NLB to back a PrivateLink endpoint service, the consumers of that service pay endpoint and data processing charges separately, which is worth understanding when you expose a service to other accounts.
Idle and Orphaned Load Balancers
Because the hourly charge applies regardless of traffic, forgotten load balancers are pure waste. Test environments, decommissioned services, and load balancers left behind by deleted stacks keep billing until someone removes them. In large organizations this sprawl is often the biggest single opportunity to reduce load balancer spend.
NLB vs ALB vs Gateway vs Classic: Pricing Compared
Network load balancer pricing only makes sense in the context of the other Elastic Load Balancing options, because choosing the right type is the first and largest cost decision. All of them share the same broad model of an hourly fee plus a capacity unit, but the rates and drivers differ.
| Load balancer | Layer and traffic | Hourly (approx) | Capacity unit | Unit rate | Main cost drivers |
| Network (NLB) | Layer 4, TCP UDP TLS | $0.0225 | NLCU | $0.006 | Flows and bytes, TLS is costly |
| Application (ALB) | Layer 7, HTTP HTTPS | $0.0225 | LCU | $0.008 | Connections, bytes, rule evaluations |
| Gateway (GWLB) | Layer 3, appliances | $0.0125 | GLCU | $0.004 | Flows and bytes, plus endpoint fees |
| Classic (CLB) | Layer 4 and 7, legacy | $0.025 | None | Per GB | Hourly plus about $0.008 per GB |
The Classic Load Balancer is legacy and being phased out, so new designs should ignore it except during migrations. The Gateway Load Balancer is a specialized tool for inserting third party appliances such as firewalls and intrusion detection systems, and it carries a separate endpoint charge on top of the hourly and GLCU fees. The real everyday choice for most teams is between NLB and ALB.
The NLCU Versus LCU Difference That Decides Cost
The most important number in this comparison is not the hourly rate, which is nearly identical for NLB and ALB, but how much each capacity unit buys you on the connection dimensions.
| Dimension | ALB LCU allotment | NLB NLCU allotment (TCP) |
| New connections | 25 per second | 800 per second |
| Active connections | 3,000 per minute | 100,000 per minute |
| Processed bytes | 1 GB per hour | 1 GB per hour |
| Rule evaluations | 1,000 per second | Not applicable |
A single NLB capacity unit absorbs 32 times more new connections than an ALB capacity unit for plain TCP traffic. For connection heavy Layer 4 workloads, NLB is not just faster, it is meaningfully cheaper per unit of work. The ALB, on the other hand, earns its slightly higher rate by giving you HTTP routing, host and path based rules, native TLS handling, sticky sessions, and web application firewall integration that NLB simply does not provide.
Think in total cost of ownership, not sticker rate. An ALB that consolidates ten services behind one set of routing rules can be cheaper overall than ten NLBs each carrying their own hourly floor, even though the ALB unit rate is higher. The reverse is also true: forcing HTTP heavy traffic onto an NLB to chase a lower unit rate can cost you in engineering effort and lost features. The right lens is the whole system, not the price of a single capacity unit.
When a Network Load Balancer Is the Cheaper Choice
Cost should follow the workload, not the other way around. The pricing model rewards specific patterns.
NLB Wins For
- Connection heavy TCP or UDP workloads, such as game servers, IoT ingestion, database proxies, and messaging systems, where the 800 connections per NLCU allotment keeps usage low.
- Ultra high throughput services that need to handle very large request rates with minimal latency overhead.
- Static IP or PrivateLink requirements, where you need fixed addresses or want to expose a service across accounts.
ALB Is Worth the Higher Unit Cost When
- You need Layer 7 routing by path, host, or header, which NLB cannot do.
- You want built in features like WAF, authentication, redirects, or Lambda targets that only ALB supports.
- Your traffic is HTTP based and moderate, where the small per unit difference is not worth losing routing flexibility.
The honest summary: do not choose NLB purely to save a few dollars. Choose it when its performance and Layer 4 model fit, and enjoy the lower per connection cost as a bonus. Choosing the wrong type to shave capacity unit cost usually creates more expensive workarounds elsewhere.
Network Load Balancer Pricing in Kubernetes and Container Environments
If you run Amazon EKS or self managed Kubernetes on AWS, NLB pricing deserves special attention, because the platform can create load balancers automatically. When you define a Kubernetes Service of type LoadBalancer, or use the AWS Load Balancer Controller in NLB mode, each such service can provision its own Network Load Balancer.
That convenience becomes a cost pattern. A cluster with many exposed services can quietly spin up a dozen or more NLBs, each carrying its own hourly floor of around $16 per month before a single byte flows. Multiply that across staging, testing, and production clusters and the fixed cost alone can climb into the hundreds of dollars per month, entirely separate from the compute the cluster runs.
- Prefer shared ingress where you can. Routing many services through a single ingress avoids the one load balancer per service pattern that inflates the fixed floor.
- Use internal NLBs for east to west traffic that never needs a public address, which also removes public IPv4 charges.
- Watch cross zone data transfer, since Kubernetes spreads pods across zones and cross zone balancing on NLB bills the inter Availability Zone traffic that results.
- Clean up on teardown. Deleting a namespace or service should remove its load balancer, but orphaned NLBs from failed deletions are a frequent source of waste in container platforms.
The core message for platform teams is that the number of load balancers your cluster creates is a cost decision, even when a controller makes it automatically. Make it deliberately, and review it as the cluster grows.
Capacity Unit Reservation: Committing for a Lower Rate
AWS offers a capacity unit reservation model for Elastic Load Balancing that lets you commit to a baseline number of capacity units per hour in exchange for a lower rate on the reserved portion. Reserved NLCUs are billed at a discounted rate, while usage above your reservation is charged at the standard on demand NLCU rate.
This is useful for workloads with a predictable, steady baseline of traffic. You reserve the floor and pay on demand only for the peaks above it. For bursty or unpredictable workloads, staying fully on demand is usually simpler. As with any commitment, the savings only materialize if your actual usage reliably sits at or above the reserved level, so base the reservation on measured metrics rather than optimistic forecasts.
Common Pricing Mistakes That Inflate NLB Bills
Most overspending on network load balancer pricing comes from a small set of recurring mistakes rather than from the base rates themselves. Recognizing them is usually enough to avoid them.
- Treating the hourly fee as the whole cost. Teams budget for the flat fee and are surprised when TLS connection volume or processed bytes push NLCU charges well above it.
- Terminating TLS on the load balancer without measuring the impact. Because TLS allotments per NLCU are a fraction of the TCP allotments, this decision can multiply usage charges without anyone noticing.
- Enabling cross zone balancing everywhere by default. It improves distribution but adds cross AZ data transfer on NLB, and at high throughput that transfer can exceed the load balancer fee.
- Leaving load balancers running after the workload is gone. Idle and orphaned NLBs keep billing the hourly floor indefinitely.
- Attributing data transfer to the wrong service. Cross AZ, egress, and NAT charges sit near the load balancer on the bill and are easy to blame on it or to overlook entirely.
- Over provisioning load balancers per service or per environment. One thoughtful routing design often replaces several separate load balancers.
None of these are exotic. They are the everyday consequences of a pricing model that rewards attention to how traffic is encrypted, distributed, and cleaned up. Catching them is mostly a matter of reviewing metrics and the data transfer section of the bill on a regular cadence.
How to Estimate Your Network Load Balancer Pricing
A reliable estimate comes from your own metrics, not from a generic assumption. The process is straightforward once you know which numbers to pull.
Start With CloudWatch Metrics
- Count your load balancers first. Multiply the number of active NLBs by the hourly rate and by 730 hours to get the fixed monthly floor before any traffic.
- Pull per hour capacity metrics. Use new flow counts, active flow counts, and processed bytes from CloudWatch, and identify which dimension peaks in a representative hour.
- Convert to NLCUs. Divide each dimension by its per NLCU allotment, take the highest result, and that is your NLCU count for that hour.
- Model baseline and peak separately. An average blended number hides the launches, incidents, and bot spikes that actually drive cost. Run both scenarios.
Then Validate With the AWS Pricing Calculator
The AWS Pricing Calculator lets you plug in connections, bytes, and load balancer hours for your region and returns a modeled cost. Use it as a second opinion on the numbers you derived from metrics, and always confirm the current rates for your specific region, since pricing varies geographically and changes over time.
Best Practices to Reduce Network Load Balancer Costs
Load balancer spend is rarely the largest line on an AWS bill, but it compounds quietly across environments. These practices consistently reduce it without hurting reliability.
- Delete idle load balancers. Audit for NLBs with no targets, only unhealthy targets, or negligible traffic, and remove them. Each one deleted saves the full hourly floor.
- Consolidate where the type allows. With ALB you can serve many services behind one load balancer using host and path rules. NLB does not route at Layer 7, but you can still avoid spinning up separate load balancers for workloads that could share one listener setup.
- Be deliberate about cross zone balancing. Enable it only where you need the even distribution, and understand the cross AZ data transfer it triggers on NLB.
- Reconsider TLS termination points. If TLS connection volume is driving NLCUs, evaluate whether termination belongs at the load balancer or elsewhere in your stack.
- Release unused public IPv4 addresses and prefer internal load balancers for service to service traffic that never needs to touch the internet.
- Use reservations for steady baselines and stay on demand for spiky, unpredictable traffic.
- Watch the data transfer bill, not just the load balancer line. Cross AZ traffic, egress, and NAT charges often dwarf the load balancer fee itself, so treat them as part of the same network cost review.
Regional Differences in Network Load Balancer Pricing
The rates quoted throughout this article reflect common US regions. Prices vary by region, and some regions run noticeably higher on both the hourly charge and the capacity unit rate. Availability Zones within a region also affect cost indirectly through cross zone data transfer.
Before you finalize a design or a budget, confirm the exact hourly and NLCU rates for the region you plan to deploy in. A workload that is cost efficient in one region can be measurably more expensive in another, and multi region designs multiply both the fixed and variable components across every region you run in.
Conclusion: Making the Network Load Balancer Pricing Decision
Network load balancer pricing is simple in structure and subtle in practice. You pay a modest hourly fee for each NLB and a usage fee measured in NLCUs, billed on whichever traffic dimension peaks each hour. The fixed fee dominates for small workloads, and the usage fee takes over as connections and throughput grow, with TLS termination and cross zone data transfer acting as the two biggest accelerators of cost.
For engineering and financial decision makers, the practical playbook is clear. Choose the load balancer type that fits the workload first, using NLB for connection heavy Layer 4 traffic and ALB when you need Layer 7 features. Then control cost by deleting idle load balancers, being deliberate about cross zone balancing and TLS, watching the data transfer bill, and reserving capacity only where your baseline is predictable.
Do that, and network load balancer pricing becomes a predictable, well understood part of your architecture rather than a mysterious line item. The load balancer itself is cheap. The discipline around how you route, encrypt, and move traffic through it is what actually determines the bill.
