I'm unhappy with EKS costs for running microservices

Totally understandable—EKS can get expensive fast, especially for microservices where you end up paying for a lot of always-on infrastructure and operational overhead.

Here are the main cost levers to look at, in order of impact:

1) Check whether EKS is the real cost driver

EKS itself has a fixed control plane fee, but the bigger costs are usually:

• Worker nodes (EC2, or Fargate)
• Load balancers per service / ingress
• NAT Gateway traffic and hourly charges
• EBS volumes
• Observability (logs, metrics, traces)
• Overprovisioning from “one service = one deployment = one replica set” patterns

If you want, I can help you build a cost breakdown from your AWS bill.

2) Reduce node waste

Common fixes:

• Use Cluster Autoscaler or Karpenter
• Right-size CPU/memory requests and limits
• Pack workloads better with bin packing
• Use mixed instance types
• Use Spot for fault-tolerant services
• Avoid lots of tiny nodes with poor utilization

A lot of EKS teams pay for 2–5x more capacity than they actually use.

3) Cut networking and ingress costs

This is often a surprise bill driver:

• Too many ALBs/NLBs for individual services
• Traffic going through NAT Gateway instead of VPC endpoints
• Cross-AZ traffic between services
• Heavy service-to-service chatter inside the cluster

Possible improvements:

• Put more services behind a shared ingress
• Use Gateway API / Ingress consolidation
• Add VPC endpoints for AWS services
• Reduce cross-AZ dependencies if possible

4) Consider whether EKS is overkill

For microservices, EKS is often chosen for flexibility, but it may be too much if you:

• Have a small team
• Don’t need advanced Kubernetes features
• Want lower ops overhead
• Run mostly HTTP APIs and scheduled jobs

Alternatives:

• ECS Fargate: simpler ops, often lower total cost for smaller setups
• App Runner: good for simple web services
• Lambda: best for event-driven or spiky workloads
• Plain EC2 + systemd/Docker: sometimes cheapest, but more manual
• Cloud Run-like patterns on AWS are limited, but ECS Fargate is closest

5) Consolidate services or rethink architecture

Microservices can become expensive because each service has its own:

• deployment
• scaling rules
• health checks
• logging
• networking
• IAM

You might save money by:

• merging low-traffic services
• using a modular monolith
• reducing service count
• separating only the truly independent workloads

6) Improve observability spend

Costs can balloon from:

• verbose application logs
• high-cardinality metrics
• full trace sampling on all traffic

Try:

• lower log retention
• sample traces
• reduce debug logging in prod
• use log filtering/aggregation

7) Use AWS savings options

• Savings Plans for baseline compute
• Reserved Instances if your usage is predictable
• Spot for batch and stateless services
• Scale down dev/stage clusters aggressively

---

Practical next step

If you want to make this concrete, I’d suggest answering these 5 questions:

1. Are you using EC2 nodes or Fargate?
2. How many services and clusters do you have?
3. What’s the biggest line item: compute, load balancers, NAT, logs, or storage?
4. Are workloads mostly steady or bursty?
5. Do you need Kubernetes specifically, or just container orchestration?

If you share a rough setup, I can help you figure out whether to:

• optimize EKS,
• move part of it to ECS/Fargate,
• or simplify the architecture altogether.