If your organisation runs workloads on virtual machine (VM) based infrastructure, you are almost certainly paying for idle compute capacity. Kubernetes offers a fundamentally different approach to scheduling workloads that can dramatically improve resource utilisation — and therefore reduce your infrastructure bill. This article explains why, using a suitcase analogy popularised by cloud economist Owen Rogers of 451 Research on the Google Kubernetes Podcast, and backs it up with a rough but illustrative AWS cost comparison.
The Core Problem: Fixed-Size Boxes (Virtual Machines)
Imagine you are packing a suitcase after a shopping trip. Every item you bought is still inside its original store box — rigid, fixed in size, with plenty of empty space inside each one. You cannot rearrange the contents because everything is sealed in its own box. As a result, you need two suitcases to carry everything home, at a total cost of $200, when all the actual clothing would have fitted in one suitcase ($100) if you had unpacked the boxes and filled every nook and cranny.
Those fixed-size boxes are virtual machines. Every VM carries significant overhead in the form of a full guest operating system — kernel, system libraries, daemons — that consumes CPU and memory before your application even starts. Because VMs are sized to handle peak load (spikes), their average utilisation is often very low. You are paying for space inside boxes that is mostly empty.
Containers: Unpacking the Boxes
A container is the equivalent of removing the clothes from the store boxes and packing them directly into the suitcase. Containers share the host operating system kernel; they do not each carry their own OS. This removes most of the overhead and allows you to pack far more workloads onto the same underlying server or VM.
The key insight is that an application built and run as containers should cost less than the equivalent VM-based deployment — provided those containers are scheduled efficiently onto the available infrastructure. That scheduling problem is exactly what Kubernetes solves.
How Kubernetes Bin-Packing Works
Kubernetes treats each containerised application as a Pod — the smallest deployable unit. When you submit a Pod to the cluster, the Kubernetes scheduler inspects each worker node’s available CPU and memory and places the Pod on the node that best fits its resource requests. This process is called bin packing: filling available capacity as tightly as possible, just like squeezing clothes into every corner of a suitcase.
Because containers have far less overhead than VMs, and because Kubernetes actively optimises placement, you can run many more workloads on the same physical or virtual hardware. Idle capacity that would have been stranded inside individual VMs is now shared across all Pods on the node.
A Rough AWS Cost Comparison
The following numbers are illustrative and simplified. Actual costs depend on instance types, reserved pricing, data transfer, storage, and many other factors. Do not treat these figures as a precise benchmark — use them to understand the order-of-magnitude difference in approach.
Typical VM-Based Setup
Consider a team running 20 application EC2 instances and 4 RDS database instances, all sized for peak load with consistently low average utilisation:
- 20 EC2 instances × ~$100/month = $2,000/month
- 4 RDS instances × ~$250/month = $1,000/month
- Total: ~$3,000/month
Kubernetes on AWS EKS
Migrating those 20 applications to containers and running them as Pods on a single EKS worker node (for example, an m5.xlarge, which AWS allows to run up to 58 Pods based on its network interface IP limits) could look like this:
- 1 × m5.xlarge EC2 worker node × ~$300/month = $300/month
- EKS control plane fee = ~$73/month (check current AWS pricing)
- RDS instances (unchanged) = $1,000/month
- Total: ~$1,373/month
In this illustrative scenario, the EC2 compute cost alone drops from $2,000 to roughly $300 — a reduction of approximately 85% on that line item, and around 54% of the overall bill. In practice, across multiple clients, savings in the range of 60–70% of existing EC2 cloud costs have been reported, particularly where EC2 instances are consistently underutilised. Your mileage will vary based on actual workload characteristics and the instance types you choose.
Note: The RDS line item is excluded from the EC2 saving because managed database services are not typically containerised in the same way. Database migration decisions deserve their own analysis.
Prerequisites: Containerising Your Workloads
Realising these savings is not automatic. Your team must be able to:
- Containerise each application — write a
Dockerfile, build an image, and push it to a container registry (Docker Hub, Amazon ECR, Google Artifact Registry, etc.). - Write Kubernetes manifests — define Deployments, Services, ConfigMaps, and resource requests/limits for each workload.
- Integrate with CI/CD pipelines — automate image builds and cluster deployments so that every commit produces a tagged, versioned image that can be promoted through environments.
This investment in containerisation pays dividends beyond cost reduction. A tagged container image is a portable, reproducible artifact that runs identically on a developer laptop, an on-premises cluster, or any cloud provider’s managed Kubernetes service. It also enables advanced deployment strategies out of the box:
- Blue/Green deployments — run two identical environments, switch traffic instantly, roll back immediately if something goes wrong.
- Canary releases — route a small percentage of traffic to a new version before rolling it out fully.
- Rolling updates — Kubernetes replaces Pods incrementally with zero downtime by default.
Beyond Cost: Other Reasons to Adopt Kubernetes
Cost optimisation is a compelling starting point, but Kubernetes offers a broader set of operational benefits:
- Portability — workloads are no longer coupled to a specific cloud provider or hypervisor.
- Self-healing — Kubernetes automatically restarts failed containers and reschedules Pods away from unhealthy nodes.
- Horizontal scaling — the Horizontal Pod Autoscaler can scale your application Pods based on CPU, memory, or custom metrics, and the Cluster Autoscaler can add or remove worker nodes to match demand.
- Declarative configuration — your entire infrastructure state is described in version-controlled YAML files, making it auditable and reproducible.
- Ecosystem — a large ecosystem of Helm charts, operators, and CNCF projects covers observability, networking, security policy, and more.
Is Kubernetes Right for Every Workload?
Kubernetes introduces operational complexity. Small teams running a handful of simple services may find that the learning curve and cluster management overhead outweigh the savings. Managed services like AWS EKS, Google GKE, and Azure AKS reduce — but do not eliminate — that burden. Before committing, assess:
- Whether your applications can be containerised without significant refactoring.
- Your team’s current Kubernetes expertise or appetite for training.
- Whether your workloads are genuinely underutilising their current VMs (check actual CPU and memory metrics, not just assumed peak sizing).
- Stateful workloads — databases and other stateful services require additional planning (persistent volumes, operators) and may be better left on managed cloud database services.
Summary
The suitcase analogy makes the economic argument for Kubernetes intuitive: VMs are like fixed-size boxes that waste space; containers are like loose items you can pack tightly. Kubernetes is the expert packer that fills every available gap. For organisations running underutilised VM fleets — especially on public cloud infrastructure where every idle CPU cycle costs money — migrating workloads to a Kubernetes cluster can yield substantial and measurable cost reductions, while simultaneously improving deployment velocity and operational resilience.
Original concept and suitcase analogy attributed to Owen Rogers (451 Research), as discussed on the Google Kubernetes Podcast.