Container image size and the real cost of every pull

Quick answer

Image size costs money three ways: registry egress per GB pulled, compute time spent waiting on pulls, and slower autoscaling that forces higher headroom. Cutting an image from 1.2 GB to 180 MB across 3,000 pulls a month saves about 3 TB of transfer and roughly 40 seconds per pod start. Where pulls cross regions or leave the cloud at 0.09 dollars per GB, that is around 270 dollars a month from image size alone, before counting faster scaling and shorter pipelines.

Image size is treated as a hygiene issue, something to fix when there is time. It is actually a cost input, and one that multiplies by a surprisingly large number, because every node, every deploy, every scale out event, and every CI job that pulls the image pays for it again.

Once you count the pulls, the case for a smaller image stops being about tidiness.

Counting the pulls

Pull source	Frequency	Monthly pulls
Deploys across 30 nodes	2 deploys a day	About 1,800
Autoscale events	40 a day	About 1,200
Node replacements and spot reclaims	10 a day	About 300
CI jobs pulling the image	60 a day	About 1,800
Total		About 5,100

Five thousand pulls of a 1.2 GB image is about 6 TB of transfer a month for one service. Node level caching reduces the real number, but a fleet with churn, spot reclaims, and fresh nodes re-pulls constantly, and CI runners are usually ephemeral so they always pull cold.

What transfer costs depend on placement

Pulls within the same region from a regional registry are typically free or close to it, which is why co-location is the first fix. Cross region pulls run about 0.02 dollars per GB, and pulls from a registry outside the cloud, including public registries reached over the internet, can hit 0.09 dollars per GB on the egress side.

Six terabytes at 0.09 dollars per GB is roughly 540 dollars a month for one service's images. Shrink to 180 MB and the same pull count is about 900 GB, roughly 80 dollars. That is a 460 dollar a month difference from a build change, and the egress mechanics matchdata transfer out cost.

Pull time is compute you pay for

A 1.2 GB image takes roughly 40 to 60 seconds to pull and unpack on a typical node, against 5 to 10 seconds for a 180 MB one. During that window a pod is not serving traffic and a CI job is burning runner minutes.

For CI, 45 seconds across 1,800 monthly jobs is 22 hours of runner time, about 10 dollars managed but far more in wall clock delay for engineers. For autoscaling, the pull delay is worse than the money: if scale out takes 90 seconds instead of 25, you compensate by running more headroom, which means permanently paying for idle capacity to cover a slow pull.

How images get large

The usual causes are consistent. A full operating system base instead of a slim or distroless one adds 200 to 800 MB. Build toolchains left in the final image, compilers, package managers, and headers, add hundreds of megabytes. Package manager caches and temporary files not cleaned in the same layer persist even after a later delete. Copying the whole repository, including tests and fixtures, adds whatever your repository weighs.

Multi stage builds address most of this: compile in a fat builder stage, copy only the binary and runtime assets into a slim final stage. Go and Rust services commonly land under 30 MB this way, and Node or Python services typically reach 100 to 250 MB with a slim base and no dev dependencies.

Cache and replicate instead of re-pulling

Where pulls must cross a boundary, put a pull through cache in the cluster's region so the external fetch happens once rather than per node. Replicate your own registry into every region you deploy in, since replication storage is far cheaper than repeated cross region egress.

Also make sure nodes actually reuse cached layers: pinning digests, keeping the base image stable, and avoiding an always pull policy where it is not needed preserve the cache that is already on the node.

Track size as a build metric

Publish image size on every build and alert when it grows more than 20 percent. Size regressions creep in through dependency additions and base image bumps, and catching them in the pull request is far easier than explaining a transfer bill later.

The infrastructure around images, the registry, its replication, the cache, and the node pools that pull from it, is Terraform, so c3x can price changes to that layer from the plan with no cloud credentials. Adding registry replication to three regions, for instance, shows as a concrete monthly number you can weigh against the egress it avoids. Image size is one of the few optimizations that reduces cost, speeds deploys, improves autoscaling, and shortens pipelines at the same time.

FAQ

How much does container image size cost?

It depends on pull volume and placement. One service can see about 5,100 monthly pulls across deploys, autoscale events, node replacements, and CI jobs. At 1.2 GB that is roughly 6 TB of transfer, about 540 dollars a month if pulls cross regions or leave the cloud at 0.09 dollars per GB. At 180 MB the same pull count is about 900 GB, roughly 80 dollars.

Do same region image pulls cost anything?

Usually little or nothing, which is why co-locating the registry with the clusters and runners that pull from it is the first fix. Cross region pulls run about 0.02 dollars per GB and pulls from registries outside the cloud, including public ones reached over the internet, can reach 0.09 dollars per GB on the egress side.

How does image size affect autoscaling?

A 1.2 GB image takes roughly 40 to 60 seconds to pull and unpack versus 5 to 10 seconds for a 180 MB one. If scale out takes 90 seconds instead of 25, teams compensate by running more headroom, which means permanently paying for idle capacity to cover a slow pull. The indirect cost often exceeds the transfer charge.

What makes container images large?

A full operating system base instead of a slim or distroless one adds 200 to 800 MB, build toolchains left in the final image add hundreds of megabytes, package manager caches not cleaned in the same layer persist after a later delete, and copying the whole repository adds tests and fixtures. Multi stage builds fix most of it by copying only the binary and runtime assets into a slim final stage.

How do I keep image size from creeping back up?

Publish image size on every build and alert on growth above about 20 percent, since regressions arrive through dependency additions and base image bumps. For the surrounding infrastructure, registry replication, pull through caches, and node pools, C3X prices changes from the Terraform plan with no cloud credentials, so adding replication in three regions shows as a number to weigh against the egress it avoids.

What to do next

Shrink the image, then price the registry around it. C3X estimates Terraform cost with no cloud credentials. Start with the quickstart.