Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / How Cloud Contracts Now Charge for Container Image Vulnerability Scans
Transcript
- Lucas: So you run a containerized app in production, you push an image to the registry, and the cloud provider automatically scans it for vulnerabilities — no extra charge, right? That's been the default for years. Luna: Right, a built-in security feature. But I've been hearing that's changing. Some teams are seeing new line items on their bill. Lucas: Exactly. Starting late last year and accelerating through 2026, AWS, Azure, and GCP have all begun metering container image vulnerability scans. It used to be bundled into the registry cost. Now it's a per-scan charge. Luna: How much are we talking? Lucas: Roughly one to five cents per scan per image, depending on the provider and the depth of the scan. AWS ECR charges $0.012 per scan for basic, $0.04 for enhanced. Azure Container Registry is $0.02. GCP Artifact Analysis is $0.015. Sounds tiny until you multiply by thousands of scans a day. Luna: And a lot of teams scan on every push, plus scheduled scans. That adds up fast. Lucas: Right. I talked to a fintech company that runs about 12,000 image pushes a week. Their monthly scanning bill went from effectively zero to $4,700. Their FinOps lead told me that was the single biggest unexpected cost increase in Q2. Luna: That's real money. And I bet it's not just the scan fee — there's probably downstream costs too, like storing scan results or triggering alerts. Lucas: Yes, some providers charge for result storage. AWS Enhanced Scanning includes a per-finding fee. So if you have a lot of false positives — and most registries do — you're paying for noise. Luna: Now, before we go deeper, I want to take a quick beat. Lucas, we've been doing this show for over a hundred episodes, and we've never run ads. Lucas: That's intentional. The show is listener-supported. A small group of regulars already chips in through buy me a coffee dot com slash fexingo, and that's what keeps the lights on — no sponsors, no tracking, just the content. Luna: Yeah, it's a model we believe in. If these conversations are useful for what you're building or running, that's the whole goal. And for anyone who wants to help keep it going, the link is buy me a coffee dot com slash fexingo. Lucas: Appreciate that. So back to the scanning costs — the key question is: why did providers flip this to metered? It's not pure greed. There's real infrastructure behind each scan. Luna: Right, they're running a vulnerability database, compute for analysis, network for pulling layers. It's not free to provide. Lucas: Exactly. AWS says the average enhanced scan uses about 30 seconds of compute. At scale, that's significant. But the pricing also creates a subtle lock-in — once you're paying per scan, you're less likely to switch to a third-party scanner that would require re-architecting your pipeline. Luna: So what should teams do? Just accept the cost or fight it? Lucas: There are levers. First, reduce scan frequency. You don't need to scan every push in production. Many teams scan only on merge to main and then a weekly deep scan. That alone cut that fintech's bill by 60 percent. Luna: But security teams might push back. They want continuous scanning. Lucas: And they're right to. But you can use cheaper basic scans for every push and only the expensive enhanced scans on release candidates. That's a common pattern. Luna: Another option is using a third-party scanner like Trivy or Snyk, which run in your own CI pipeline and don't hit the cloud registry bill. But then you're managing your own vulnerability database. Lucas: Which has its own costs — engineer time, compute, storage. But for large shops, it can be cheaper. I've seen enterprises cut their scanning cost by 80 percent by moving to an open-source scanner and only using the cloud provider's for compliance audits. Luna: And there's also the contract side. Are these charges negotiable in enterprise agreements? Lucas: They can be. I've seen some large customers get scanning included as part of a committed-use discount or a Enterprise Support contract. But you have to ask. It's not automatically waived. Luna: So the lesson is: read the fine print on your registry pricing. And if you're doing a new cloud deal, make scanning fees a line item in the negotiation. Lucas: Exactly. One more thing — some providers charge per image layer, not per image. If you have a multi-layer image, each layer gets scanned separately. That can double or triple the effective cost. Luna: So optimizing your Dockerfile to have fewer layers isn't just a best practice for build speed — it's a cost optimization. Lucas: Exactly. We're seeing FinOps teams now include 'layer count' as a metric in their cost dashboards. That's a shift from a year ago. Luna: It's wild how granular cloud billing has become. Every API call, every scan, every DNS query — all metered. Lucas: That's the direction. And it means the job of the cloud architect now includes understanding pricing models at a much deeper level. It's not just about compute and storage anymore. Luna: So what's the one takeaway for our listeners? If you're managing container infrastructure, what should you do this week? Lucas: Check your registry bill. Look for a line item called 'Scanning' or 'Image Analysis'. Compare it to your total registry cost. If it's more than 10 percent, start optimizing scan frequency and layer count. And if you're in procurement, bring it up in your next renewal. Luna: Solid advice. And as always, if you've got a story about scanning costs or any other cloud billing surprise, we'd love to hear it. Lucas: You can reach us through the show page. But for now, that's the view from here. Thanks for listening.