Kubernetes Cost Optimisation for Startups: Cut Cloud Spend Without Touching Reliability

The cloud bill arrives. It is larger than last month. Engineering is busy shipping features, so nobody has time to investigate. The number rolls over. Next month it is larger still.

This is the most common Kubernetes cost story. Not fraud, not waste in the obvious sense — just a cluster quietly over-provisioned from the start, with nobody whose job it is to notice. If your team is running Kubernetes and has not done a deliberate cost review in the last six months, there is a high probability you are spending 30–50% more than you need to. The fixes are not exotic. They are three levers, applied in the right order.

Why Kubernetes cost optimisation starts with utilisation data

Before you touch a single configuration, you need to know what the cluster is actually doing. Most teams skip this and jump straight to "let us reduce node sizes" or "let us enable the autoscaler" — and then spend weeks chasing incidents they introduced.

The right starting point is cost attribution by namespace and workload. Tools like Kubecost or OpenCost surface the real picture: which teams, which services, which jobs are consuming what share of the bill. Without that, every optimisation is a guess.

What you typically find:

Requested resources are 3–5x actual usage. Engineers set CPU and memory requests conservatively at first deploy and never revisit them. The scheduler allocates nodes based on requests, not actual consumption — so a node that looks 80% allocated is often running at 20% utilisation.
Development and staging environments run 24/7. Nobody pays much attention to non-production, so dev clusters run full-time on the same node sizes as production. A scheduled scale-to-zero for off-hours cuts 60–70% of non-prod cost with no operational change.
Old workloads never leave. Orphaned deployments, stale cron jobs, and jobs from cancelled projects accumulate quietly and consume cluster capacity.

Measure first. The data tells you where the highest-ROI changes are.

Lever one: right-size requests and limits

The single highest-ROI action in most clusters is correcting over-requested CPU and memory. The Vertical Pod Autoscaler (VPA) in recommendation mode (not auto mode, to start) will give you per-container suggestions based on observed usage. The Goldilocks UI wraps VPA recommendations into a dashboard that makes it easy to see which workloads to tackle first.

A practical approach:

Enable VPA in recommendation-only mode across all namespaces.
Wait one to two weeks to collect usage data across different load conditions — including your peak traffic window.
Review recommendations namespace by namespace, starting with the highest-spend workloads.
Apply changes with a small buffer above the p95 recommendation. Do not chase the median — you need headroom for traffic spikes.

This alone typically reduces the node count needed to run the same workloads by 30–40%. Every node you can remove has a direct, permanent impact on the monthly invoice.

Lever two: autoscaling that actually works

Most teams enable the Cluster Autoscaler and consider the job done. In practice, the Cluster Autoscaler is conservative by design — it is good at adding nodes under load and slow to remove them. Pair it with the Horizontal Pod Autoscaler (HPA) and, where appropriate, Karpenter, and the economics change significantly.

HPA for variable workloads. If a service handles 10x the requests at noon compared to midnight, it should not run the same replica count at both times. An HPA scaled on CPU or custom metrics (request rate, queue depth) means you are paying for capacity proportional to actual demand, not peak demand 24/7.

Karpenter for node provisioning. Where the Cluster Autoscaler works with pre-defined node groups, Karpenter provisions exactly the node type and size the pending pods need. This eliminates the common pattern of small pods stranded on oversized nodes because no smaller node group exists.

Spot and preemptible nodes for stateless workloads. For workloads that can tolerate interruption — background jobs, worker queues, non-critical API replicas — spot instances can cut compute cost by 60–80% compared to on-demand. The key is identifying which workloads are actually safe to run on preemptible nodes. Stateless services with proper PodDisruptionBudgets and multiple replicas are good candidates. Databases, session stores, and anything that holds in-memory state are not.

Lever three: environment-level cost boundaries

The first two levers focus on the production cluster. The third is often where startups find their largest absolute savings: non-production environments.

Set explicit cost budgets per namespace and enforce them:

Dev namespaces scale to zero outside business hours. A simple CronJob or KEDA ScaledObject targeting a schedule brings deployments to zero replicas overnight and on weekends. A morning scale-up job brings them back.
Preview environments are ephemeral. Per-PR preview environments are a good practice, but they need an expiry policy. An environment that outlives its pull request by a week is just waste.
Separate node pools for non-prod. Run dev and staging on cheaper node types or on a separate preemptible node pool. The cost difference between running all environments on the same production-grade nodes versus purpose-sized ones can be substantial.

What you should not cut

Kubernetes cost optimisation articles often make it sound like every line item is negotiable. Some are not.

Do not cut monitoring and observability. Grafana, Prometheus, your tracing collector — these are cheap relative to the cluster and expensive to be without during an incident. An hour of on-call debugging time costs more than a month of observability tooling.

Do not remove reliability headroom from production. PodDisruptionBudgets exist to prevent over-aggressive autoscaling from taking down your availability during a node drain or rolling update. Per-zone redundancy for stateful workloads is not waste — it is the cost of the uptime guarantee. If you are running a payments service, a messaging platform, or anything with an SLA, this headroom is the SLA.

Do not automate what you do not understand yet. VPA in auto mode will mutate running pods' resource requests. Karpenter will terminate and replace nodes. These are the right long-term configurations, but apply them after you have spent time in recommendation mode and understand your workload's behaviour under changes. Rushing to automation without a baseline understanding is how you trade a cost problem for an incident.

A framework for the first 30 days

If you are starting from scratch on Kubernetes cost optimisation, a reasonable sequence is:

Days 1–3: Install cost attribution tooling. Identify the top five cost centres by workload and namespace.
Days 4–10: Enable VPA in recommendation mode. Audit non-production environments for 24/7 over-provisioning. Schedule a scale-to-zero for dev.
Days 11–20: Apply right-sized resource requests to the highest-spend workloads. Measure the impact on node count and monthly projection.
Days 21–30: Evaluate Karpenter and spot node pools for appropriate workloads. Define a cost budget per environment and set up alerts when it is exceeded.

The target is not zero cloud spend — it is cost proportional to value delivered. When your infrastructure bill grows at the same rate as your revenue, that is a healthy signal. When it grows faster, that is a signal to investigate.

How Cursopic approaches cloud cost engagements

Our Cloud Platform Engineering practice treats cost-awareness as a first-class concern from day one of any engagement, not an afterthought. We instrument clusters before we optimise them, attribute cost by team and workload, and design autoscaling policies that maintain the uptime guarantees your users expect.

The case studies in our work section include a payments platform re-architecture that maintained 99.99% uptime while cutting infrastructure cost by 40% — a result that came from right-sizing and autoscaling, not from sacrificing reliability.

If your cloud bill is growing faster than your team can explain, it is worth a conversation. The common patterns are well-understood, the tooling is mature, and the savings tend to compound once the right framework is in place.

For more on how we approach platform architecture decisions that compound over time, read Cloud-native platforms without the rewrite.

Start a conversation about your cluster — a 30-minute call is enough to identify whether there are meaningful savings available and what the right sequencing would be for your team.