EKS pricing: what to include in a realistic cost estimate
The easiest way to underestimate EKS cost is to model only nodes. Nodes are usually the biggest line item, but a realistic budget includes a fixed per-cluster fee, storage and snapshots, load balancers, networking transfer, and observability volume. Use this page as a checklist and a template for a first-pass estimate.
1) Control plane (fixed fee per cluster)
- Estimate monthly control plane cost as clusters × $/hour × 730.
- It matters most for many small clusters (dev/test/stage sprawl), not for one large production cluster.
Guide: EKS control plane cost
2) Nodes (compute + attached storage)
Most clusters are node-hour driven. Start from requests-based sizing and a utilization target, then convert to node count and node-hours.
- Node-hours: node count × hours/month (and separate always-on vs scheduled groups if applicable).
- Packing efficiency: topology constraints, DaemonSets, and pod caps reduce real utilization.
- Attached storage: EBS root volumes and any node-local storage are separate line items.
3) Load balancers and ingress
Load balancers are often a hidden baseline cost because they’re always-on. The drivers are “how many” and “how much traffic/capacity”.
- Count the always-on LBs (one-per-service patterns can multiply quickly).
- Model capacity units for typical and peak traffic windows.
Tool: load balancer cost calculator
4) Observability (logs and metrics)
For many teams, observability becomes the “surprise bill” after the cluster is stable. If you don’t model it, your estimate is fragile.
- Logs: ingestion GB/day × retention (plus any scan/search costs).
- Metrics: time series count grows with cardinality (labels) and scrape frequency.
5) Networking: NAT, cross-AZ, and internet egress
Kubernetes often increases east-west traffic (service-to-service calls). If traffic crosses AZs or routes through NAT, costs can show up fast.
- NAT: processed GB for private workloads calling public endpoints or AWS services without endpoints.
- Cross-AZ: service chatter and load balancer routing can create steady transfer.
- Internet egress: APIs, downloads, and CDN origin traffic.
Tool: VPC data transfer calculator
6) Storage and snapshots (PVs and backups)
- PVs: GB-month for block storage and the growth rate over time.
- Snapshots: snapshot GB-month and retention policy.
Related: EBS snapshot cost
First-pass estimate template (inputs to collect)
- Cluster count (by environment and region)
- Average node count + instance $/hour (or blended on-demand/spot mix)
- Always-on load balancer count and rough traffic/capacity assumptions
- Log ingestion GB/day and retention (days)
- NAT processed GB/month and cross-AZ transfer assumptions
- PV storage GB-month and snapshot retention
If you’re missing a number, write down an assumption and validate it after deployment instead of pretending it’s zero.
Common pitfalls
- Budgeting from peak nodes (overestimates) or from perfect packing (underestimates) without headroom.
- Cluster sprawl in non-prod making fixed per-cluster fees and add-ons balloon.
- One load balancer per service creating a large always-on baseline.
- Ignoring log/metric growth (cardinality) until the bill arrives.
- Accidental NAT and cross-AZ traffic from “it just works” routing.
How to validate after the first month
- Group EKS costs by service and usage type: confirm your top 3 drivers match your model.
- Check node-hours vs the planned node count; investigate fragmentation if it’s higher than expected.
- Review load balancer count and utilization; consolidate where appropriate.
- Measure log ingestion GB/day and retention; tune verbosity and sampling intentionally.
- Check NAT processed GB and cross-AZ transfer; adjust routing and endpoints if needed.