ECS vs EKS cost: a practical checklist (compute, overhead, and add-ons)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

This page is the AWS orchestration-platform comparison page, not the ECS or EKS bill-boundary page: the goal is to compare two AWS operating models under the same workload, traffic, and overhead assumptions.

ECS vs EKS comparisons are often wrong because teams compare “service A” to “service B” without modeling the surrounding infrastructure. Use this checklist to compare consistently: normalize workload assumptions, pick the compute model, add platform overhead, then add the line items that dominate in production.

If you still need to decide what belongs inside the ECS bill or the EKS bill before you compare platforms, go back to the relevant pricing guide first. ECS pricing. EKS pricing.

Step 0: normalize workload assumptions (the part most comparisons skip)

• Average capacity: typical vCPU and memory used over a month (not peak only).
• Burstiness: how often you hit peak (daily, weekly, incident-only).
• Traffic shape: requests/sec and average response size (drives transfer and LB usage).
• Logging volume: GB/day and retention (often a separate bill).

Helpful helpers: units converter and RPS → monthly requests.

Keep this page on the platform-choice layer. Generic Kubernetes routing belongs on the hub, and provider bill scope belongs on the ECS or EKS pricing pages.

Step 1: pick the compute model for ECS

• ECS on EC2: pay for instance-hours (and EBS). You win when you can pack tasks efficiently.
• ECS on Fargate: pay for vCPU-hours + memory GB-hours per running task. You win when you reduce idle running tasks.

Step 2: model EKS baseline and packing efficiency

EKS cost is usually dominated by node-hours, but the driver is “how well you pack pods into nodes” and “how many clusters you operate”.

• Control plane: fixed hourly fee per cluster (matters for many small clusters).
• Nodes: rightsize from requests and accept imperfect packing (pod limits, topology constraints).
• Add-ons: CNI/ingress/observability add baseline overhead on every node.

Step 3: add the line items that dominate both (don’t skip this)

• Load balancers: hourly baseline plus capacity units for each LB.
• Logs & metrics: ingestion + retention; high-cardinality metrics and chatty logs can become major.
• Networking: NAT processed GB, cross-AZ transfer, and internet egress.

A practical decision guide (when cost tends to favor each)

• ECS tends to win when you want a smaller platform surface area, run a few predictable services, and can keep average running tasks low.
• EKS tends to win when you can consolidate many workloads into fewer clusters and achieve high packing efficiency with disciplined requests and autoscaling.
• Either can lose if you sprawl clusters/LBs, ignore observability volume, or route internal traffic through expensive paths (NAT, cross-AZ).

Common pitfalls

• Comparing peak capacity instead of average (budgets are mostly driven by average).
• Ignoring cluster count: many small EKS clusters create fixed-fee and operational overhead.
• “One load balancer per service” patterns creating an always-on baseline bill.
• Missing NAT/cross-AZ transfer costs from service-to-service chatter.
• Assuming logs/metrics are “small” without measuring GB/day and series growth.

How to validate after you choose

• In billing/Cost Explorer, group costs by service and usage type: verify compute vs LB vs logs vs transfer.
• Compare “average running tasks/pods” to “peak”; optimization is often reducing idle, not shaving milliseconds.
• After a week, re-check: LB count, NAT processed GB, log ingestion GB/day, and cross-AZ transfer.

Related reading

Sources

• Amazon EKS pricing
• AWS Fargate pricing
• Amazon ECS overview

Related guides

Related calculators

FAQ