Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Charge for Container Registry Pulls
Transcript
- Lucas: If you've looked at your cloud bill recently and noticed a line item for something like 'ECR image pull' or 'Container registry consumption,' you're not alone. More and more enterprises are seeing registry pull charges appear as a separate cost category. Luna: It used to be that pulling a Docker image was basically free — you paid for storage and maybe network egress, but the act of pulling itself wasn't metered. Lucas: Exactly. AWS introduced per-pull pricing for ECR back in late 2024. Azure Container Registry followed with similar consumption-based billing in early 2025. And GCP's Artifact Registry has always had a pull element but recently made it more granular. The industry trend is clear: cloud providers are monetizing the metadata and request volume behind your container operations. Luna: So what does that look like in practice? I've heard numbers like ten dollars per thousand pulls or something. Lucas: It varies. On AWS, after the first 500 gigabytes of data transferred out in a month, you pay roughly one cent per gigabyte for image layers. But there's also a per-request charge — about $0.0001 per pull for the first tier. That sounds tiny, but when you're running a CI/CD pipeline that builds and deploys dozens of microservices multiple times a day, those tenths of a cent add up fast. Luna: Right. So a company with, say, fifty services each deployed ten times a day, that's five hundred pulls daily, fifteen thousand monthly. At a tenth of a cent each, that's fifteen dollars. Not huge, but it's a new line item you didn't budget for. Lucas: And then you add in the fact that each pull can consist of multiple layers. If your base image is a fat Ubuntu with Python and Node and a dozen tools, you're pulling hundreds of megabytes per layer. The egress component can dwarf the request fee. One mid-sized SaaS startup I talked to saw their registry costs jump from essentially zero to about seven hundred dollars a month after crossing the two-hundred-thousand-pull threshold on ECR. Luna: Ouch. So how do teams avoid that? Is it all about using smaller base images? Lucas: That helps, but there's a bigger lever: pull-through caches. You can set up a local registry mirror — like a Docker Registry v2 compatible proxy — that caches frequently pulled images. Your CI nodes pull from the local cache, which only goes back to the cloud registry for cold misses. That cuts your external pull count by an order of magnitude. Luna: But then you're managing infrastructure for the cache. You need to host it somewhere, maintain it, keep it in sync. Is the trade-off worth it? Lucas: It depends on your scale. For a team with a few pulls a day, probably not. But if you're a hundred-engineer org doing continuous deployment, the cache pays for itself quickly. I've seen a two-hundred-dollar-a-month cache VM eliminate a five-thousand-dollar-a-month registry bill. Luna: That's a huge spread. And the cloud providers themselves offer managed cache solutions now, don't they? Like ECR pull-through cache rules. Lucas: Yes. AWS introduced pull-through cache rules for ECR last year — you define a rule that says 'for any image from Docker Hub or another registry, cache it in my ECR.' That way you avoid egress fees from Docker Hub and also control pull costs on the AWS side. Azure has a similar feature with Container Registry tasks and replication. GCP's Artifact Registry has regional replication and caching. Luna: So the providers are both creating the problem and selling the solution. Classic. Lucas: It is a bit ironic. But honestly, the caching features are genuinely useful even before the billing changes. They improve pull reliability and speed. The real frustration I hear from operators is that the pricing changes feel like a rug-pull for teams that built pipelines assuming pull costs were near zero. Luna: And that's the thing — these aren't huge numbers in absolute terms, but they change the calculus for architecture decisions. Do you use a fat base image that reduces build time but increases pull cost, or a slim distroless image that saves on pulls but requires more build complexity? Lucas: Exactly. It adds a new dimension to the old trade-off between build speed and runtime efficiency. And it's not just base images. You also have to think about multi-stage builds, image layer reuse, and whether you really need to pull every time or can reuse a cached layer from a previous build. Some teams are moving to using manifest lists and specifying digests to avoid unnecessary pulls. Luna: Let's talk about the CI/CD angle. If your pipeline pulls the same image ten times across different stages, you're paying ten times. So consolidating steps into a single container that runs all checks can reduce pulls. Lucas: That's a good point. Also, you can use a job-level cache for Docker layers. CircleCI and GitHub Actions both support caching Docker layers between workflow runs. That cuts down the number of times you pull from the registry during development loops. Luna: And what about the providers themselves? Are any of them offering free tiers or thresholds to soften the blow? Lucas: AWS gives you 500 gigabytes of free data transfer per month for ECR. After that, you pay. Azure Container Registry includes 100 gigabytes of storage and 10 gigabytes of data transfer free. But request costs are separate. GCP's Artifact Registry has a free tier that includes 1 GB of storage and 50 K image pull requests per month. Those thresholds are fine for small teams, but once you scale, you cross them. Luna: It really pushes you to be intentional about your containerization strategy. I think a lot of teams just pulled whatever image they wanted without thinking twice. Now that pattern has a cost. Lucas: We deliberately don't run ads on this podcast. If you want to support that choice, the link is buy me a coffee dot com slash fexingo. It helps us keep these conversations ad-free and focused on what matters for operators and builders. Luna: Yeah, listener support is what keeps the show independent. We appreciate anyone who chips in. Lucas: So back to the registry costs — one more tactic I've seen teams use is image deduplication. If you have multiple teams maintaining separate base images, there's often a huge overlap in layers. By consolidating base images into a single common layer family, you can dramatically reduce the number of unique layers stored and pulled. Docker's layer sharing is smart, but it only works if the layers are identical. If two images share the same base but have slightly different dependencies, they don't share layers. Luna: So it's about standardization. A platform team can enforce a set of approved base images — like a hardened Java 17 image, a Python 3.12 image, etc. — and then application teams layer their code on top. That way pulls are mostly hitting cached layers. Lucas: Exactly. And you can even use image manifest lists to serve the same image for different architectures without duplicating pull requests. It's a level of optimization most teams didn't need to think about a year ago, but now it's table stakes for cost control. Luna: What about using Kubernetes node-level image pre-pulling? Like if you know a new node is going to spin up, you can pre-pull images onto it to avoid pulling during pod startup. Lucas: That works, but it's tricky because you have to predict which images the node will need. Some teams use descheduler or cluster autoscaler strategies to keep images on nodes, but that adds complexity. Another approach is to use containerd's snapshotter with a shared NFS volume for container images, so all nodes share a common image store. Then pulls happen once. Luna: But then you're trading registry costs for storage costs on NFS. Still, it might be cheaper. Lucas: Right. The key is that the cost signals are getting finer-grained. Every API call, every byte transferred, every pull request — eventually it gets metered. The cloud providers are moving toward a pure usage-based model where nothing is truly free. That's good for flexibility, but it demands a new level of financial awareness from developers. Luna: It feels like the era of 'just use it and we'll figure out the bill later' is ending. Now you need to care about the cost of every pull request from day one. Lucas: Absolutely. And the teams that adapt early — by caching, choosing slim images, and consolidating layers — will have a competitive advantage. The others will see their cloud margins erode quarter by quarter.