Why Kubernetes Egress Costs on AWS Will Surprise You the First Time You Scale

Running Kubernetes on AWS feels like the obvious choice until your first real traffic spike hits and you open the billing console. That number in the egress line? It's not a mistake. It's exactly what AWS intended, and if you didn't architect around it from day one, you're paying for the education now.

I've talked to enough DevOps teams in the Treasure Valley and across the Pacific Northwest to know this story by heart. They stood up EKS, got their pods running, deployed a few services, and everything looked fine — right up until the month they actually had users. Then the bill arrived and suddenly someone's having a very uncomfortable conversation with their CFO.

Let's walk through what's actually happening, why it compounds so fast in Kubernetes specifically, and what your options look like if you're tired of funding AWS's network infrastructure.

How Kubernetes Makes Egress Costs Worse Than You'd Expect

Egress fees aren't unique to Kubernetes. AWS charges $0.09/GB for data leaving their network (after the first GB free tier), and that applies to any service. But Kubernetes introduces several traffic patterns that multiply your exposure in ways a simple EC2 deployment doesn't.

The first one is inter-AZ traffic. AWS charges $0.01/GB for data moving between Availability Zones — in both directions. That sounds small. It isn't, once you understand how Kubernetes routes traffic by default. When a service receives a request, kube-proxy uses iptables rules to load balance across all healthy pod endpoints regardless of where they're running. If your request lands on a node in us-west-2a and gets forwarded to a pod in us-west-2b, you just paid for that hop. Both ways.

A cluster with 20 services, moderate traffic, and pods spread across three AZs can generate tens of thousands of dollars per year in inter-AZ charges alone — for traffic that never left your own application.

The second multiplier is container image pulls. Every node that schedules a new pod pulls the image from ECR or Docker Hub. If you're running ECR and your nodes are in a private subnet without a VPC endpoint, those pulls go through a NAT Gateway. NAT Gateway costs $0.045/GB processed, on top of the data transfer charges. A 2GB image pulled across 50 nodes during a rollout is $4.50 in NAT Gateway fees for one deployment. Run deployments daily and do the math.

The third is external load balancer traffic. Every AWS Load Balancer in front of your services processes data at $0.008/LCU-hour plus data processing fees. If you're running a microservices architecture with 10-15 services each fronted by their own ALB because that's what the tutorials showed you, you're paying for all of it.

The Bill That Actually Hurt

Here's a real scenario. A SaaS company running a healthcare data platform in EKS — about 40 microservices, three environments (dev, staging, prod), and a modest but growing user base in the Boise metro area. Their compute costs were reasonable. They'd right-sized their instances and were using Spot for non-critical workloads. They felt good about their AWS spend.

Then they hit $34,000 in a single month. Compute was $18,000. The other $16,000 was a combination of NAT Gateway ($4,200), inter-AZ data transfer ($3,800), load balancer fees ($2,100), and outbound egress to their users ($5,900).

That last number is the one that stings the most. Their users were primarily in Idaho and the Pacific Northwest. Their data was leaving an AWS Oregon region, traveling to end users 300 miles away, and they were paying $0.09/GB for every byte of it. The latency to those same users was 20-40ms because the traffic was routing through AWS's backbone infrastructure rather than taking a direct path.

They were paying a premium to be farther from their own customers.

What You Can Actually Do About It on AWS

If you're committed to staying on AWS, there are real mitigations — none of them are free, and most require retrofitting your cluster.

Topology-aware routing is the most impactful change for inter-AZ costs. Kubernetes 1.21+ supports topology hints that bias traffic toward endpoints in the same zone. Enable it with an annotation on your Service:

apiVersion: v1
kind: Service
metadata:
  name: your-service
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  type: ClusterIP
  ...

This works well when you have enough replicas spread across zones. With only one or two replicas, the hints get ignored and you're back to random routing.

VPC endpoints for ECR and S3 eliminate NAT Gateway charges for image pulls and object storage access. You create interface endpoints for ECR API and ECR DKR, and a gateway endpoint for S3. Each interface endpoint costs $0.01/hour per AZ — roughly $21/month per service — but if you're pulling images at any real volume, it pays for itself fast.

Consolidating load balancers with an ingress controller (NGINX or AWS Load Balancer Controller with path-based routing) reduces your per-ALB costs. One ALB can handle routing for dozens of services. This should have been the default advice from the start, but here we are.

Even after doing all of this correctly, you're still paying $0.09/GB for traffic to your end users. That fee doesn't go away. It's structural.

The Geographic Argument Nobody's Making Loudly Enough

Here's something that gets overlooked in Kubernetes cost optimization discussions: where your cluster runs matters as much as how it's configured.

If your users are in Boise, Nampa, Meridian, or anywhere in the Treasure Valley, you're routing traffic through Oregon at minimum. Probably farther. The latency hit is real — 20-40ms versus sub-5ms from infrastructure actually located in Idaho. For most web applications that's not catastrophic, but for anything interactive, real-time, or latency-sensitive (video, audio, financial transactions, healthcare telemetry), it's a genuine UX problem.

The cost argument is more straightforward. When you run Kubernetes on infrastructure without punishing egress fees, the entire calculus changes. Flat pricing on outbound data means you can actually predict your bill. No NAT Gateway charges. No inter-AZ transfer fees because your cluster isn't spread across artificial availability zones designed to generate that revenue.

We run Kubernetes workloads here at IDACORE on infrastructure we own in Weiser, Idaho — 85 miles from Boise, with direct connectivity to the region. Our pricing doesn't have an egress line item that scales with your success. A team that was paying $34K/month on AWS moved comparable workloads to us for under $22K, and that included managed Kubernetes support. The difference wasn't magic — it was the absence of fees that exist specifically because AWS can charge them.

What to Actually Evaluate Before You Migrate

I'm not going to tell you to rip everything out of EKS tomorrow. That's not realistic, and there are legitimate reasons some workloads belong on hyperscalers — global distribution, specific managed services with no equivalent elsewhere, compliance requirements that mandate certain certifications.

But if you're an Idaho company running workloads that primarily serve Idaho and Pacific Northwest users, the geographic argument for staying on AWS is weak. You're not getting lower latency. You're not getting better support. You're getting a brand name and a bill that grows in ways that are hard to predict.

Before any migration conversation, run this analysis on your current AWS bill:

1. Pull your last 6 months of Cost Explorer data, broken down by service
2. Isolate: NAT Gateway, Data Transfer, Elastic Load Balancing, and EC2 Data Transfer
3. Add those four lines together
4. That number is what you're paying for AWS's network. Not your compute. Not your storage. Their network.

For most Kubernetes deployments I've seen in this region, that number is 30-45% of the total bill. Sometimes higher.

Then ask what you'd pay for that traffic on infrastructure without per-GB fees. The answer usually ends the debate.

There's also the support question, which is separate from cost but matters just as much operationally. When something breaks in your cluster at 11pm, you want to talk to someone who has actually run BGP routing tables and understands what a cascading pod failure looks like from the infrastructure side — not a ticket queue in a different timezone reading from a runbook. That's the difference between operator-built infrastructure and a hyperscaler's support tiers.

Kubernetes is genuinely good technology. The operational model AWS has built around it — with fees at every network boundary — doesn't have to be the price of admission.

---

If what you just read sounds like your last AWS billing review, it might be worth looking at what Kubernetes hosting actually costs on infrastructure built and operated in Idaho. We can pull your current bill apart line by line and show you exactly where the differences land — no estimate theater, just real numbers. Get a straight answer on what you'd actually pay.