If you are running fewer than a dozen services, Kubernetes is almost certainly costing you more in engineering time than it saves in infrastructure spend. I have seen this repeatedly across scale-ups that adopted K8s early because it felt like the right ambition — and are now paying three engineers to operate a cluster that serves a workload a single managed container service would handle for a fraction of the cost.
Kubernetes is a genuinely impressive piece of engineering. It is also one of the most expensively over-applied tools in the modern cloud stack. The question is not whether Kubernetes is powerful — it is whether your organisation is at the scale where that power is worth the operational tax.
The Kubernetes Tax Is Real
When you adopt Kubernetes, you are not just adopting a container orchestrator. You are adopting a full operational surface:
- Cluster provisioning and version management
- Node pool sizing and auto-scaling configuration
- Networking: CNI plugins, ingress controllers, service meshes (if you get there)
- RBAC, service accounts, and secrets management
- Certificate management (cert-manager, custom CA chains)
- Persistent volume configuration and storage classes
- Pod security policies or their successors
- Cluster monitoring: Prometheus, Grafana, alerting rules
- Log aggregation and shipping
- Backup and disaster recovery for cluster state and PVCs
- Upgrade cycles — which break things in subtle ways, every time
This is real work, and it requires real expertise to do well. The engineering hours that go into operating the cluster are hours not going into your product. For a team of six engineers running four services, this trade-off is almost never worth it.
What Kubernetes Actually Costs
Let me be concrete. Here is what I typically find when I audit a small team's Kubernetes setup:
| Cost Category | Typical Monthly Spend |
|---|---|
| Control plane (managed K8s) | 150–350 EUR |
| Node pools (3 nodes, minimum HA) | 400–900 EUR |
| Load balancers per service | 15–30 EUR each |
| Persistent volumes | 50–200 EUR |
| Egress and networking | 100–400 EUR |
| Engineering time (20% of 2 engineers) | 4,000–8,000 EUR |
| Total | 5,000–10,000 EUR/mo |
Compare that with the same workload on Azure Container Apps, Google Cloud Run, or AWS App Runner:
| Cost Category | Typical Monthly Spend |
|---|---|
| Managed container service (consumption-based) | 200–600 EUR |
| Managed database (no PVC complexity) | 100–300 EUR |
| Load balancer (included or shared) | 0–50 EUR |
| Engineering time (near-zero ops overhead) | 200–500 EUR |
| Total | 500–1,500 EUR/mo |
The difference is not the compute. It is the people. A managed container service handles the control plane, the ingress, the certificate rotation, the node upgrades, and the auto-scaling. Your team ships features instead of debugging why a pod is stuck in CrashLoopBackOff at 2am.
The "But We Might Need It" Fallacy
The most common justification I hear for early Kubernetes adoption is forward-looking: "We might have hundreds of services someday." This is infrastructure speculation, and it is expensive.
Optimising for a scale you have not reached yet, using tooling that is operationally expensive at your current scale, is a version of premature optimisation — except it affects your entire engineering organisation, not just a function.
The argument assumes that migrating to Kubernetes later is so difficult that you should absorb the operational cost now to avoid it. This is wrong for two reasons.
First, migrating three containerised services to Kubernetes when you need to is a two-week project, not a six-month programme. Containers are portable by design. If you have been running on Cloud Run and hit the scale where Kubernetes makes sense, the migration is not the catastrophe people imagine.
Second, you will know much more about your actual scaling requirements in two years than you do today. The Kubernetes configuration you design now, for a scale you are guessing at, will not resemble what you actually need when you get there.
The CV-driven architecture problem
I have sat in architecture reviews where Kubernetes was chosen because the senior engineers wanted to work with it, not because the organisation needed it. K8s skills are valuable and interesting. That is a legitimate personal motivation. It is a terrible reason to add thousands of euros per month in operational cost and complexity to a product that does not need it. If your architecture decision is driven by what your team wants to learn, you have a skills development problem — solve it with side projects and training budgets, not production infrastructure.
When Kubernetes Actually Earns Its Keep
I am not anti-Kubernetes. At the right scale, with the right team, it is genuinely the right tool. Here is where it starts to make sense:
You have more than 15–20 services
At this point, the operational overhead of managing dozens of separate deployment pipelines across a managed container service starts to rival the overhead of operating a cluster. Kubernetes gives you a unified control plane, consistent rollout strategies, and resource scheduling that actually becomes efficient.
You have dedicated platform engineering capacity
Kubernetes is not a set-and-forget system. It requires someone who owns it — who manages upgrades, responds to cluster incidents, tunes autoscaling, and keeps the security posture current. If you have a platform team of two or more engineers whose job includes cluster operations, the maths starts to shift.
You need workload scheduling capabilities
Custom resource requirements, GPU node pools, batch job scheduling with Job and CronJob primitives, bin-packing across heterogeneous hardware — these are Kubernetes strengths. If your workload profile includes ML training jobs, batch processing, and latency-sensitive APIs all running on the same infrastructure, Kubernetes gives you scheduling primitives that managed container services cannot match.
You have specific compliance requirements
Some regulated environments require fine-grained control over where workloads run, network policies between services, and audit trails for every API call. Kubernetes, properly configured, provides this control. Managed container services abstract it away — which is usually a benefit but occasionally a compliance constraint.
The Decision Framework
The honest question is not "is Kubernetes good?" It is "what does my organisation pay to operate Kubernetes, and what does it get in return?"
| Signal | Recommendation |
|---|---|
| Less than 10 services, less than 10 engineers | Use Cloud Run / Container Apps / App Runner |
| 10–20 services, no dedicated platform team | Managed container service; revisit at 20 services |
| 20+ services, growing team | Evaluate K8s seriously — TCO may now favour it |
| Platform team of 2+ engineers | K8s is operationally viable |
| GPU workloads or complex scheduling needs | K8s almost certainly wins regardless of service count |
| Hard compliance requirements on network isolation | Evaluate K8s with dedicated node pools |
| SaaS product with a single-tenant deployment model | K8s may be necessary for tenant isolation |
The decision path looks like this:
What to Do If You Are Already Over-invested in K8s
The right move is not always to migrate off. That can be as expensive as the initial adoption. Instead, the audit question is: what is the actual operational cost, and is it worth the return?
I have helped teams reduce their Kubernetes operational burden by 60% without migrating, by consolidating node pools, removing unused workloads, right-sizing resource requests, and automating upgrades. The cluster stays; the operational tax drops significantly.
Where the team is genuinely too small to operate Kubernetes safely — meaning production incidents are going unresolved, upgrades are deferred because nobody has time, and the cluster has not been patched in six months — migration to a managed service is the right call. A well-planned migration from Kubernetes to Cloud Run for a handful of services typically takes four to eight weeks, not six months.
The right question in your next architecture review
Before any infrastructure decision, ask: what is the total cost of ownership over 24 months, including the fully-loaded engineering time to operate this? Not just the compute bill. Most teams dramatically undercount the people cost and overcount the compute savings of complex infrastructure choices.
The Broader Pattern
Kubernetes is a symptom of a wider pattern: infrastructure choices made for capability reasons rather than economic reasons. The cloud ecosystem rewards complexity — every tool vendor, every conference talk, every blog post is pitching something sophisticated. The implicit message is that sophisticated equals serious, and simple equals immature.
The organisations I have worked with that have the lowest total infrastructure cost relative to engineering output tend to be the ones that aggressively resist complexity until they have no choice. They run managed services until managed services genuinely cannot meet their requirements. They adopt Kubernetes when they have the scale and team to justify it. They do not treat architectural ambition as a virtue.
Boring infrastructure is not a failure of ambition. It is a sign that the engineering team is focused on building the product, not operating the platform.
If your cloud architecture has grown expensive relative to the value it is delivering — whether that is a Kubernetes cluster that has become a burden, or a cloud bill that does not match your scale — let's talk. A 30-minute architecture review often surfaces enough savings to justify the conversation several times over.