Azure Load Balancer pricing: L4 traffic and data processing model

L4 load balancer estimates are easiest when you treat them like a network device: it runs for a number of hours and it processes a volume of traffic. The two keys are: (1) split internal vs internet-facing, and (2) model baseline + peak.

0) Confirm you are modeling the right product

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 a different L7 product; model that separately.

1) 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.

2) 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).

3) 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.

4) 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.

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).