Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Bills Now Meter Your Container Image Pulls
Transcript
- Lucas: So Luna, I was looking at a client's cloud bill last week — mid-sized fintech, nothing exotic — and there it was: a line item for container image pulls. Charged per pull, tiered by image size. Luna: Wait, that's a thing now? I thought pulls were just... free. Part of the registry service. Lucas: That used to be the case. But over the past year, I've seen this charge creep into enterprise contracts. It started with a niche vendor, then the big three followed. By early 2026, it's pretty much standard. Luna: So what's the actual metering? Is it just per pull, or is there more to it? Lucas: It's per pull, but with a twist. The price varies by image size — small images under a gig are pennies, but anything over five gigs, you're paying a noticeable amount per pull. And if the pull crosses a network boundary, say from a registry in one region to a cluster in another, there's an egress component too. Luna: That sounds like a recipe for surprise bills. I mean, we've had episodes about data egress fees, but this feels like a new layer. Lucas: Exactly. And it's not just the pull itself — it's the frequency. Teams that rebuild and deploy multiple times a day can rack up hundreds of pulls a week. That adds up fast. Luna: So what does this mean for the average DevOps team? Are they just stuck with it? Lucas: Not necessarily. Let me tell you about that fintech client. They were running a standard Kubernetes setup, pushing images to a managed registry, and pulling them on every deploy. Their bill jumped about eighteen percent quarter-over-quarter after they switched to a new CI/CD pipeline that did more frequent builds. Luna: Eighteen percent — that's not trivial. What did they do? Lucas: They did a few things. First, they audited their image sizes. Some of their images were bloated — one was over eight gigs because it included test dependencies. They slimmed it down to under two gigs. That alone cut the per-pull cost significantly. Luna: So it's a classic case of 'size matters'. Lucas: Right. Then they looked at pull frequency. They had a nightly job that was pulling the same image across three environments, even though nothing had changed. They added a simple digest check — if the image tag hadn't changed, skip the pull. That cut pulls by about forty percent. Luna: Nice. And what about the egress side? Did they have to move registries? Lucas: They had their registry and cluster in the same region, so no egress there. But they found that some of their development teams were pulling from a different region because of an old configuration. Once they fixed that, they saved on the network transfer too. Luna: So the key is to treat pulls like any other cloud resource — monitor, optimize, and budget. Lucas: Exactly. And that's the broader point. Cloud vendors are getting more granular with metering. We've talked about charges for load balancer paths, firewall rule evaluations, DNS queries — now image pulls. The pattern is clear. Luna: And if this episode is useful to you, the way we keep it ad-free is through listener support. You can buy us a coffee at buy me a coffee dot com slash fexingo. It genuinely helps, and we appreciate it. Lucas: Yeah, that's really the only way we keep this going. Thanks for that, Luna. Luna: So, back to the topic. How are these charges structured in the big three? Is it uniform? Lucas: Not exactly. AWS, Azure, and GCP have similar tiers, but the thresholds differ. For example, AWS charges a small fee per pull for images over a certain size, while Azure bundles it into the registry service but adds a separate data transfer fee. GCP is experimenting with a flat rate per pull, regardless of size, but they're testing it. Luna: So there's no standard yet. That's interesting — it could be a differentiator. Lucas: Right. And that's why teams need to be proactive. If you're not tracking your pulls, you're flying blind. Luna: What about smaller players? Do they have any leeway? Lucas: Smaller teams might be under the radar, but as they scale, these charges will become significant. There's also the question of open-source registries — like Docker Hub — which have their own rate limits. That's a different can of worms. Luna: So what's the takeaway for a listener who runs containers? Lucas: Start tracking your pull counts and sizes now. Most cloud consoles have usage reports. Look for patterns — repeated pulls of the same image, images that are unnecessarily large, cross-region pulls you can avoid. Then set up alerts for unexpected increases. Luna: And maybe consider a pull budget, like you do for CPU and memory. Lucas: Absolutely. In fact, some FinOps teams are already adding 'pull budget' to their dashboards. It's becoming a standard metric. Luna: One more thing — is there any talk of a standard or regulation that could change this? Lucas: There's been some murmurs about the Cloud Native Computing Foundation proposing best practices for registry billing, but nothing concrete. For now, it's each vendor their own. Luna: So it's a bit of the Wild West out there. Lucas: A bit, yeah. But that's also an opportunity. Teams that get ahead of this can negotiate better contracts or optimize early. Luna: What about the future? Do you see this spreading to other types of pulls, like from private registries? Lucas: Private registries are likely next. Some are already charging for pull requests, even if it's bundled into a subscription. The trend is clear: every action has a price. Luna: That's a bit daunting, but also a reminder to be more intentional about resource usage. Lucas: Exactly. And that's really the theme of this show — being intentional with your cloud infrastructure. The days of 'just pull and go' are numbered.