Container image size is a cost lever most teams never look at. A large image inflates registry storage, multiplies data transfer every time a node pulls it across a zone or region, and consumes node disk because each layer is cached locally on every node that runs the workload. It also slows pod startup, so autoscaling lags and you run extra capacity to cover the gap. The fix is cheap and durable: build lean images with multi stage builds and minimal bases, and set registry lifecycle policies to delete stale versions automatically. This is one of the standing wins in container cost work.
This article sits in the Kubernetes and container costs cluster. The full container view is in the Kubernetes cost guide; this page is the storage and image specific detail.
Where does image size actually cost money?
Three lines on the bill move with image size, and a fourth moves indirectly.
- Registry storage. Every tag and every untagged build sits in your registry, Amazon ECR, Azure Container Registry, GCP Artifact Registry, or OCI Container Registry, and you pay per gigabyte stored. Thousands of stale builds at hundreds of megabytes each add up quietly.
- Data transfer. Pulling an image across an availability zone or region incurs transfer charges. On AWS this is the same class of quiet budget eater as data transfer and NAT gateway traffic. A cluster that scales out frequently pulls images constantly, so a smaller image multiplies into real savings.
- Node disk. Kubernetes caches image layers on each node. Large images and many distinct images per node mean larger node disks, which is provisioned storage you pay for whether or not it is full.
- Compute during scaling. A heavy image takes longer to pull and start, so autoscaling reacts slowly. Teams compensate with headroom, which is idle compute. Lean images shorten startup and let you run tighter.
How do you build a lean image?
The mechanics are well understood and pay back immediately.
Multi stage builds. Compile and assemble in a build stage, then copy only the runtime artefact into a clean final stage. Build tooling, compilers, and package caches never ship to production. This alone often removes the majority of an image's size.
Minimal or distroless bases. Starting from a full operating system base pulls in shells, package managers, and libraries you never run. Minimal bases and distroless images carry only what the application needs, which shrinks the image and reduces the attack surface as a bonus.
Layer discipline. Combine related commands, clean package caches in the same layer that creates them, and order layers so the rarely changing ones cache. Pin only the dependencies you actually run rather than installing broad meta packages.
One artefact per image. Resist bundling debugging tools, test fixtures, and multiple language runtimes into a single production image. Each addition is stored, transferred, and cached forever.
What does registry lifecycle policy do?
Image hygiene is not only about the size of each image; it is about how many you keep. Registries accumulate every build, and most of those builds are never deployed again. A lifecycle policy deletes old and untagged versions automatically so you stop paying to store history nobody uses.
All four registries support retention rules. The highest return policy is usually two rules together: delete untagged images after a short window, and keep only the last N tagged versions per repository or anything newer than a set age. Set it once and the registry stays lean without anyone remembering to clean up. Confirm the policy excludes images still referenced by running workloads before enabling deletion.
A European SaaS company ran microservices on managed Kubernetes with images averaging well over a gigabyte, built from a full operating system base, and a registry that had never been pruned. Moving to multi stage builds on a minimal base cut the typical image to a fraction of its former size, and a lifecycle policy that removed untagged builds and capped tagged history cleared years of accumulated storage. The registry and transfer lines fell, node disks were reduced because the layer cache shrank, and pod startup dropped, which let the platform team trim autoscaling headroom. Figures are verified against billing data and anonymised.
How does this fit the wider container cost picture?
Image hygiene is a contained win, but it pairs with the bigger container levers: right sizing pod requests and limits, node right sizing, and bin packing so fewer nodes run more pods. Smaller images make scaling faster, which makes those levers work better, because tight autoscaling depends on fast pod startup. Treat image hygiene as the maintenance layer underneath the structural work in the Kubernetes cost guide and the cross cloud context in the cloud cost optimization guide. The native advisors will flag oversized nodes but rarely the image bloat underneath, so this is analysis you have to do deliberately.
Frequently asked questions
Cut your container storage cost with us
We audit image size, registry sprawl, and node disk together, then put the hygiene and lifecycle policies in place so the savings hold without manual cleanup. Our guarantee: we reduce your cloud spend or we reimburse our service fee.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.