Google Kubernetes Engine (GKE) pricing: nodes, networking, storage, and observability
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
GKE planning gets accurate when you treat it as a stack: compute (nodes), networking (LB/egress/inter-zone), storage, and observability. The goal is not just to estimate, but to keep the cluster right-sized as traffic and workloads change.
0) What to model (drivers you can validate)
- Node pools: instance type, min/max nodes, and average node-hours per month.
- Bin packing: requests/limits, kube-system overhead, and DaemonSets.
- Networking: load balancers, internet egress, inter-zone traffic, and private connectivity.
- Storage: PV GB-month, snapshots, and retention windows.
- Logs/metrics: ingestion volume, retention, and scan/search behavior during incidents.
1) Node pools: instance-hours (baseline and peak)
Model each pool separately and keep baseline vs peak months distinct. Scale-out events often do not average out in practice (marketing, seasonality, incident retries).
Tool: Compute instance cost.
2) Requests/limits: the bin packing multiplier
Requests determine how many pods fit on a node. Over-requesting is one of the most common cost leaks. Validate overhead (kube-system, DaemonSets) and reserve capacity explicitly.
Tool: Requests/limits helper.
- For CPU-bound workloads, right-sized CPU requests can reduce nodes dramatically.
- For memory-bound workloads, use p95 memory to avoid OOM churn.
3) Networking: load balancers, egress, and inter-zone traffic
Internet-facing services often have meaningful egress. Multi-zone clusters also generate inter-zone east-west traffic that does not show up as "internet bandwidth" but still affects the bill.
Tools: Egress cost, Load balancing pricing, Inter-zone transfer.
4) Storage: PVs, snapshots, retention
Persistent volumes are a GB-month driver. Snapshots/backups and retention windows add a quiet multiplier, especially for stateful workloads.
Tool: Storage pricing (generic).
5) Observability: logs and metrics
Logging and metrics scale with pod count and verbosity. If each request emits multiple log lines, log ingestion can exceed compute. Model ingestion and retention explicitly.
Tool: Log cost tools.
Worked estimate template (copy/paste)
- Nodes = sum(node pool avg node-hours/month) (baseline + peak)
- Bin packing = effective pods/node based on requests/limits (headroom + overhead)
- Egress = outbound GB/month (internet + cross-region) + inter-zone GB/month
- Storage = PV GB-month + snapshot GB-month (retention)
- Logs = log GB/month + retention/scan assumptions
Common pitfalls
- Over-requesting CPU/memory so pods cannot pack (node count inflates).
- Not splitting system overhead (DaemonSets and kube-system are real capacity).
- Ignoring egress and load balancers (often the second-largest driver after nodes).
- Verbose logs per request and long retention windows.
- Underestimating inter-zone east-west traffic in multi-zone clusters.
How to validate
- Validate node utilization vs requested resources (find over-requesting and bin packing gaps).
- Validate outbound GB by destination and peak periods (deployments, incidents, scale-outs).
- Validate log bytes per request and retention policies.