Azure Load Balancer Pricing: Rules, Data Processed, and Bandwidth Boundaries
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
If you searched for Azure Load Balancer pricing, the first thing to confirm is what Azure actually bills on the load balancer line versus what still lands on bandwidth or adjacent network services. This page is the pricing and bill-boundary guide for Azure Load Balancer: use it to separate rules, data processed, and separate bandwidth charges before you blend in outbound internet access, NAT, or L7 gateway assumptions.
L4 load balancer estimates are easiest when you treat them like a network device with explicit billing boundaries. The two keys are: (1) split internal vs internet-facing, and (2) model baseline + peak without assuming that every transferred byte belongs inside the load balancer bill.
Quick pricing read
Azure Load Balancer pricing is not just a generic traffic number. The official pricing surface is built around rules, data processed, and separate bandwidth charges. That is why a clean estimate has to distinguish what is billed on the load balancer line from what belongs on outbound internet, cross-region transfer, or adjacent services.
- Rules: configuration count matters because rules are part of the priced surface.
- Data processed: processed bytes belong on the load balancer estimate, but they are not a shortcut for all egress cost.
- Separate bandwidth charges: Azure still applies bandwidth pricing where the traffic path qualifies for it.
- Outbound design: if the real question is outbound internet access or SNAT behavior, validate whether you are pricing Azure Load Balancer outbound rules or a NAT Gateway design.
This page was updated on 2026-06-18 against the current Azure pricing page and Microsoft Learn guidance for Azure Load Balancer outbound behavior.
0) Confirm you are modeling the right product
Azure Load Balancer is the right page only when the bill question is still about an L4 balancer. If the bill is really driven by application-layer routing, WAF, or outbound internet architecture, you need to separate that before you trust the estimate.
- Azure Load Balancer is L4 (TCP/UDP). It does not do HTTP routing like an L7 gateway.
- If you do HTTP routing, TLS termination, WAF, or path-based rules, you may be using Application Gateway instead; model that separately.
- If your real question is outbound internet access or SNAT design, validate whether you are really modeling Azure Load Balancer outbound rules or whether NAT Gateway is the more accurate pricing surface.
- Basic Load Balancer has already been retired, so production budgeting should be framed around the current Azure Load Balancer pricing model rather than legacy Basic-versus-Standard choices.
1) Know what belongs inside the Azure Load Balancer bill
The cleanest budgeting move is to decide which line items belong inside the load balancer bill before you estimate traffic. Azure Load Balancer pricing is about the balancer surface itself. Adjacent costs still matter, but they should be tracked beside the balancer instead of being blended into a single vague "network" number.
- Inside the balancer bill: rules, data processed, and load balancer runtime assumptions.
- Beside the balancer bill: bandwidth charges, NAT Gateway charges, Application Gateway charges, and downstream service transfer.
- Needs explicit validation: outbound SNAT path, cross-region paths, and whether internet responses are billed on a separate bandwidth line.
2) Hours (count your load balancers)
Count load balancers per environment (prod/stage/dev) and multiply by hours per month. If you have multiple front doors (regions, active-active), include them explicitly.
3) Traffic processed (GB)
Estimate monthly GB processed by converting request volume and average payload sizes into transfer. If you have multiple endpoints, model the highest-volume ones separately so heavy-tail endpoints do not disappear into a blended average.
Tools: RPS to requests, Response transfer, Unit converter.
- Baseline: normal RPS and normal payload sizes.
- Peak: incident traffic, autoscaling surges, and retry storms (can be 2-10x on both requests and bytes).
4) Data processed is not the same thing as bandwidth charges
This is the mistake that makes Azure Load Balancer pricing pages feel misleading. Data processed is part of the load balancer estimate. Bandwidth charges are a separate billing boundary for qualifying traffic paths. If you collapse those into one line, you can understate or double-count the network bill.
- Do not assume that every processed GB is the same thing as billed internet egress.
- Do not assume that internal traffic is priced the same way as internet-facing delivery.
- Do separate the load balancer processed-bytes model from your bandwidth validation workflow.
5) Outbound rules, SNAT, and NAT Gateway boundaries
Standard Azure Load Balancer outbound behavior deserves its own review because it can shift where teams expect the bill to land. If your architecture depends on outbound rules or SNAT through the balancer, keep that design decision explicit instead of assuming outbound internet pricing is automatically "part of the load balancer."
- Use outbound rules review when VM or cluster egress depends on the load balancer path.
- Use NAT Gateway review when your real decision is dedicated outbound internet architecture rather than balancing inbound traffic.
- Separate Application Gateway when the workload needs L7 routing, TLS termination, or WAF instead of a pure L4 balancer.
6) Egress (the boundary that matters)
If traffic exits to the internet, egress is often the material line item. Treat egress as independent from "GB processed" and validate what is billed (internal traffic may be priced differently than internet-facing traffic).
Tool: Data egress cost calculator.
- Split by destination if needed: same-region, cross-region, and internet.
- If your service returns large files, model that endpoint separately; it can dominate egress even at low RPS.
7) Hidden multipliers to check
- Retries/timeouts: multiply requests and bytes (and downstream dependencies).
- Health probes: usually small, but on large fleets they add background traffic (and noisy metrics).
- Cross-zone/cross-region: if your architecture hairpins traffic, you may pay for extra transfer legs.
Worked estimate template (copy/paste)
- Requests/month = baseline + peak (include retries)
- GB processed/month = requests/month * avg payload GB (split top endpoints)
- Egress GB/month = subset of GB that leaves to billed destinations (internet/cross-region)
Common pitfalls
- Double-counting egress and GB processed as if they are the same thing.
- Using one blended response size when a few endpoints dominate bytes.
- Modeling only average traffic and ignoring peak periods that drive capacity and cost.
- Ignoring retries/timeouts that multiply request volume and transfer.
- Assuming all traffic is "internal" without validating egress boundaries.
- Modeling outbound internet design on the load balancer page when NAT Gateway is the real pricing surface.
How to validate
- Validate peak traffic windows (deploys/incidents) and include them as a separate scenario.
- Validate retries/timeouts in client and server logs.
- Validate response sizes for top endpoints (bytes, not just request counts).
- Validate which traffic is billed as egress (internet/cross-region vs internal).
- Validate whether outbound rules or NAT Gateway define the real internet path for the workload.
Related tools
Related Azure service guides
- Azure Container Registry pricing: helpful when load balancer traffic is tightly coupled to deploy churn, node scale-outs, or image pull behavior.
- Azure Event Hubs pricing: useful when the same system also drives event ingestion, replay, or downstream transfer costs that do not show up in request counts alone.