GCP load balancing pricing: hours, requests, traffic processed, and egress

Load balancer estimates get accurate when you treat them as: hours + requests + traffic processed. For public services, internet egress is usually a separate (often larger) line item. Splitting these drivers also makes optimization obvious.

GCP load balancing inputs

  • LB hours: forwarding rules and VIPs.
  • Requests: some products bill per request.
  • Data processed: GB/month through the load balancer.

0) Decide what you are pricing

Different load balancer types have different billing units. For budgeting, most teams can start with these measurable drivers:

  • Hours: how many LBs (and environments) are always on.
  • Requests: baseline + peak requests/month (include retries).
  • Traffic processed: GB/month through the LB (response size is the key input).
  • Egress: outbound GB/month to the internet (or cross-region if applicable).

1) Hours (count always-on infrastructure)

Count load balancers and hours per month per environment (prod, staging, dev).

  • Always-on staging environments add up quickly.
  • Count internal and external LBs separately if you use both.

2) Requests (baseline and peak)

Convert RPS to monthly requests and split heavy endpoints if needed.

Tool: RPS to monthly requests.

3) Traffic processed: estimate GB from response size

If you know requests/month and average response bytes, you can estimate transfer. Keep a separate line item for heavy endpoints so they do not disappear into a blended average.

Tool: Response transfer.

4) Egress: separate it from LB processing

Internet egress is often larger than LB processing for public services. If you use a CDN, keep origin egress (cache fill) separate from edge bandwidth to avoid double-counting.

Tools: Egress cost, CDN bandwidth.

  • For APIs, response size (not request count) is usually the better predictor of egress.
  • For file downloads, model the download endpoints separately to avoid hiding them in an average.

Worked estimate template (copy/paste)

  • LB hours = LB count x hours/month (prod + non-prod)
  • Requests = baseline + peak requests/month (include retries)
  • Traffic processed = requests/month x avg response bytes (split heavy endpoints)
  • Egress = outbound GB/month (internet + cross-region if applicable)

Common pitfalls

  • Not splitting LB processing vs egress (leads to the wrong optimization).
  • Using one average response size and missing a heavy-tail endpoint.
  • Not modeling peak windows and retry storms (multipliers matter).
  • Double-counting CDN edge bandwidth and origin egress.

Related tools

Requests Transfer Egress Network transfer costs

Sources

Related guides

Cloud CDN pricing (GCP): bandwidth, requests, and origin egress (cache fill)
A practical Cloud CDN cost model: edge bandwidth, request volume, and origin egress (cache fill). Includes validation steps for hit rate by path, heavy-tail endpoints, and purge/deploy events that reduce hit rate.
GCP Cloud Run Pricing & Cost (requests, CPU/memory, egress)
Model Cloud Run cost from requests, duration, CPU/memory time, and egress. Includes validation tips for real workloads.
Load balancing costs explained: hours, requests, and traffic processed
A practical load balancer cost model: hourly baseline, request-based pricing, GB processed, WAF add-ons, and the patterns that create cross-zone traffic surprises.
Google Kubernetes Engine (GKE) pricing: nodes, networking, storage, and observability
GKE cost is not just nodes: include node pools, autoscaling, requests/limits (bin packing), load balancing/egress, storage, and logs/metrics. Includes a worked estimate template, pitfalls, and validation steps to keep clusters right-sized.
Inter-zone transfer costs on GCP: identify flows, estimate GB/month, and reduce churn
A practical checklist to estimate cross-zone data transfer: load balancers, multi-zone clusters, east-west chatter, and storage/database access patterns. Includes a worked template, validation steps, and control levers.
Private Service Connect costs: endpoint-hours and data processed (practical model)
A practical private connectivity estimate: endpoint-hours plus data processed (GB). Includes a worked template, pitfalls, and validation steps to compare PSC vs NAT/internet egress and avoid paying for both paths.

Related calculators

Data Egress Cost Calculator
Estimate monthly egress spend from GB transferred and $/GB pricing.
API Response Size Transfer Calculator
Estimate monthly transfer from request volume and average response size.
VPC Data Transfer Cost Calculator
Estimate data transfer spend from GB/month and $/GB assumptions.
Cross-region Transfer Cost Calculator
Estimate monthly cross-region transfer cost from GB transferred and $/GB pricing.
RPS to Monthly Requests Calculator
Estimate monthly request volume from RPS, hours/day, and utilization.
API Request Cost Calculator
Estimate request-based charges from monthly requests and $ per million.

FAQ

What usually drives load balancer cost?
Time and traffic processed are common drivers. For internet-facing apps, outbound egress is often the largest variable.
How do I estimate quickly?
Estimate monthly requests and average response size to get monthly GB, then split load balancer processing vs internet egress as separate lines.
What is the most common mistake?
Mixing load balancer charges and egress into one number. Treat 'LB processing' and 'egress' as separate drivers so you can optimize the right lever.
How do I validate?
Validate peak traffic and retry storms, validate whether traffic is served via CDN, and validate heavy endpoints (downloads/exports) separately.
Last updated: 2026-02-07