When I led the backend at FeteFlex, we moved everything from a pile of hand-managed instances onto Docker and Kubernetes. The bill dropped by about 80%, and deploys got roughly 40% faster. Both numbers ended up on my resume, and both are true.

But when people ask "so Kubernetes saved you 80%?" the honest answer is no. The migration was the occasion for the savings. The savings themselves came from five much less glamorous things, and I think most small teams could get the majority of them without ever typing kubectl.

Where the money actually went

1. Things nobody remembered were running. The single biggest chunk. A staging environment for a feature that shipped a year earlier. Instances someone spun up "for a quick test." EBS volumes from machines that no longer existed, still being billed. Snapshots on snapshots. We found them because the migration forced us to make a list of everything, and the list was longer than anyone's mental model of the system.

2. Everything was sized for a traffic spike that happened once. Every service had its own instance, and every instance was picked for the worst day anyone could remember. Average utilization was embarrassing. Packing those services onto a small number of nodes with realistic resource requests was the second-biggest saving. This is the one thing Kubernetes genuinely made easier, because it forces you to write down how much CPU and memory each service needs, and then it holds you to it.

3. One load balancer per service. We had a load balancer in front of almost everything, each with its own hourly fee. Replacing them with a single ingress was an afternoon of work and a permanent line item gone.

4. Traffic crossing availability zones. Services chatting to each other across zones, and everything egressing through a NAT gateway. Individually tiny. Collectively a surprising share of the bill. Co-locating chatty services and being deliberate about egress fixed it.

5. Spot instances for anything stateless. Our workers didn't care if they were interrupted; they picked the job back up. That's a steep discount for tolerating something we already tolerated.

Notice that only number two is really a Kubernetes story. Numbers one, three, four and five are "someone finally looked."

What Kubernetes actually bought us

To be fair to it: it made the hidden costs visible. You cannot deploy to a cluster without declaring resources, so over-provisioning stopped being invisible. Every service got the same deploy path, so the "40% faster" number is real. Health checks and restarts meant fewer 2am messages. And the migration itself was the audit we'd never have done otherwise.

It also cost us. The learning curve was steep for a small team. Networking debugging is its own skill. Managed control planes aren't free. For a good while, one of us was effectively a part-time cluster admin instead of a product engineer.

Would I do it again?

For that system, with a dozen-plus services, gRPC between them, and a team that had already outgrown SSH-and-pray, yes. For three services and two engineers, honestly no. I'd take a container platform that hides the cluster, do the "someone finally looked" audit by hand, and bank most of the same savings for a fraction of the complexity.

The uncomfortable truth I took from that project is that cloud cost isn't really an infrastructure problem. It's an attention problem. Nobody was wasting money on purpose. We were wasting it because nobody's job was to look, and the tooling didn't make us.

If you take one thing from this: before you plan a migration to save money, spend a day listing everything you're paying for. You might find you've already saved half of it, and you haven't changed a line of YAML.