EKS pricing: what to include in a realistic cost estimate
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
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.
Use this page when you need to decide what belongs inside the full EKS bill before you tune node shape, cluster count, or adjacent infrastructure assumptions.
This guide is the EKS bill-boundary page: node-driven compute, fixed platform overhead, and adjacent infrastructure or observability lines should be modeled as separate cost surfaces instead of one blurred Kubernetes total.
How to split the EKS bill before you estimate it
- Node-driven compute: worker node-hours, attached node storage, and the packing assumptions that change node count.
- Fixed platform overhead: the per-cluster control plane fee that grows with cluster count even if workloads are small.
- Adjacent infrastructure and observability: load balancers, NAT, cross-AZ transfer, internet egress, persistent volumes, snapshots, logs, and metrics.
If the open question is how many nodes you really need, use the EKS node sizing guide. If the open question is whether too many clusters are inflating fixed overhead, use the EKS control plane cost guide.
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.