You probably don’t need Kubernetes or AWS (Part 1 of 2)

In IT, these two terms have become more than just standard requirements in any DevOps/SRE job listing. They are more like the clichéd ‘stress resistance’ in a résumé. At the same time, the vast majority of companies whose infrastructure runs in AWS and uses Kubernetes have no real idea why they need them. The funniest part is that if you tell their CTO the platform and tooling might have been a bad choice, they will fiercely defend it.

Why you usually don’t need AWS

AWS, like any cloud provider, has huge advantages:

1. High availability and separation into availability zones

2. Ability to choose regions closer to end users

3. No headaches with configuring unique hardware and/or network equipment

However, for many companies the downsides outweigh all of this:

1. Vendor lock-in

Often it’s so strong that migrating to bare metal or another cloud is roughly equivalent to building the infrastructure from scratch.

2. Much higher cost compared to bare metal

RAM costs about 1.5x more

1 vCPU costs 2–2.5x more (with relatively unpredictable performance)

Disk costs 1.5–2x more

Traffic costs x∞ (on bare metal it is usually free or costs peanuts)

There is a major trap in this cost structure: AWS easily hands out grants worth thousands of dollars to startups. They deploy everything, lock themselves into AWS and suddenly realize the grant is ending. Now they have to pay tens of thousands every month, where they could have saved more than 70%.

3. Hidden operational complexity

This is the most interesting part. Many choose AWS because ‘it just works’. In reality it is not quite like that. Anyone who has tried to investigate an incident and during the research ended up digging into the infrastructure knows this feeling: you are poking around in a black box, almost blind.

By contrast, debugging bare-metal setups is straightforward and logical.

AWS sells a sense of safety and speed very well, but for most startups this is a temporary illusion. As the product grows, you hit limits not because you lack managed services, but because of cost, complexity, and the loss of understanding of what is actually happening in the system.

The cloud did not remove infrastructure work; it hid it behind abstractions and created the need for dedicated AWS engineers who maintain the platform instead of the product. In places where a small team that understands the system end to end can easily handle bare metal, the cloud often demands more people, more process, and more compromises.

In the end, bare metal is not a step backward. It is a more rational and controllable choice.

Why Kubernetes is unnecessary (and often harmful)

Kubernetes is not about simplifying infrastructure. It is a way to make simple things complicated. Its main purpose is to handle scale that most projects simply do not have.

1. Kubernetes is overhead, not magic

It adds dozens of entities, abstractions, and YAML files where you previously had systemd and a single deploy. Debugging turns into fortune-telling with pods and control plane logs. Any clear cause-and-effect disappears.

2. It requires its own priesthood

If you have Kubernetes, you need a Kubernetes engineer. Not for the product, but just to keep the platform running. Infrastructure starts living its own life and eats up the team’s time.

3. It solves Google’s problems, not yours

Kubernetes was built for hundreds of services and dozens of teams. Dragging it into a startup with 5–50 services is like treating a cold with chemotherapy.

4. Self-healing treats symptoms, not root causes

Kubernetes does not fix bugs, it just restarts them. Problems get masked instead of being solved.

5. The myth of ‘portability’

Managed Kubernetes is tightly coupled to cloud load balancers, storage, and IAM. On paper it is a standard. In reality it is vendor lock-in, and escaping it is as expensive and painful as possible.

Kubernetes does not make a system simpler, cheaper, or more reliable. It just makes it harder to understand.

Bare metal plus simple tools give you control and transparency. Kubernetes is only needed when life is already painful without it. In all other cases it is an expensive illusion of maturity.

AWS and Kubernetes are not signs of maturity. More often they are signs of blindly following hype.

They sell you a feeling of reliability and a ‘proper architecture’, but in practice they bring vendor lock-in, higher costs, loss of control, and an explosion of operational complexity.

Most projects do not need cloud abstractions or Google-level orchestration. They need predictable servers, simple deploys, and a team that understands the whole system.

If you use AWS and Kubernetes and cannot clearly explain what specific pain they solve for you right now, you are just paying for an illusion of maturity and postponing the moment when you will have to deal with reality.