Latest / The Cloud Business Podcast with Fexingo: AWS, Azure, GCP, and Enterprise Infrastructure / Why Cloud Contracts Now Charge for Container Registry Storage Scans
Transcript
- Lucas: So you push a container image to a registry, the registry scans it for vulnerabilities, and you get a report. That part has been free, or close to it, for years. Luna: Right — the scan itself. But you're telling me that's changing? Lucas: Not the scan event, no. What's changing is that the registry now keeps a copy of every scan result — the full vulnerability manifest, the layer digests, the CVE mappings — and they charge you to store that metadata. Luna: Wait — they charge for storing the scan report? Not just the image layers? Lucas: Exactly. Amazon ECR started this last fall. Azure Container Registry followed in March. And GCP's Artifact Registry just announced a similar charge effective August 1st. They call it 'scan result storage' or 'vulnerability assessment storage' — but it's effectively a new line item on your bill. Luna: So if I have a CI/CD pipeline pushing images fifty times a day, each push triggers a scan, and each scan generates a manifest that gets stored and billed. Lucas: Correct. And the manifest isn't tiny. A typical Alpine-based image with maybe 30 packages — the scan manifest is around 12 kilobytes. But if you're running 150 image pushes per day across dev, staging, and prod, that's roughly 1.8 megabytes of new scan metadata daily. Luna: That doesn't sound like much. Lucas: It's not — until you factor in retention. Most teams keep every image for at least 90 days, often more. So you're accruing. After a quarter, you've got about 162 megabytes of scan manifests per pipeline. Scale that across ten microservices, each with its own repo, and you're looking at 1.6 gigabytes of scan storage — at roughly two cents per gigabyte per month, that's negligible. But then the providers add a per-object overhead. Luna: Per-object overhead — that's the killer. Lucas: That's where the math flips. ECR charges a small fee per stored object in addition to the storage byte rate. Their standard storage rate is $0.10 per gigabyte per month, but they also charge $0.01 per 1,000 objects. If you're storing 150,000 scan manifests — which is realistic for a medium-sized engineering org — the per-object fee becomes $1.50 a month. Combined with the byte storage, maybe $2 to $3 total. Still tiny. Luna: But you said $800 a month earlier. Lucas: Right — that's the enterprise multiplier. In large orgs, they replicate images across regions for disaster recovery. If you push to us-east-1 and replicate to eu-west-1 and ap-southeast-2, that's three copies of every scan manifest. Plus some teams have separate registries for each business unit, each with their own scan storage. I've seen a case at a financial services firm where they had 14 regional ECR repositories, each with 250,000 scan manifests retained for six months. That's 3.5 million objects per region — the per-object fee alone hit $35 per region per month, times 14 regions, nearly $500 just in object fees. Add storage bytes and cross-region data transfer for the manifests, and you're at $800. Luna: So it's death by a thousand cuts — but the cuts are all hidden in object counts. Lucas: Exactly. And the frustrating part is that most teams don't even use the old scan results. The registry keeps the latest scan by default, but it retains every historical scan manifest for the lifecycle of the image tag. So if you push image:latest fifty times in a day, you get fifty scan manifests, all billed, even though you only care about the most recent one. Luna: Can you clean them up? Set a lifecycle policy to delete old scan manifests? Lucas: You can, but it's not straightforward. ECR lifecycle policies let you expire untagged images, but scan manifests aren't untagged images — they're associated with a specific image digest. To delete old scan results, you'd need to delete the image tags themselves, which may break your deployment rollback process. Some teams create separate lifecycle rules that expire images older than 30 days, but only for tags that match a pattern like 'build-*'. Luna: So you have to design your tagging strategy around billing, not just release management. Lucas: That's the new reality. Azure Container Registry gives you a bit more control — they allow you to purge scan results via the az CLI, but it's a manual operation. GCP's Artifact Registry hasn't published a deletion API for scan manifests yet; they say it's coming. Luna: It feels like the cloud providers are turning every free tier capability into a metered line item. First DNS query volume, then Terraform state reads, now scan storage. Lucas: It is a pattern. And I think the rationale is that these services were initially priced assuming low usage, but as container adoption exploded, the metadata storage costs became material. AWS reported in their 2025 re:Invent that ECR scan manifest storage had grown 12x year over year, mostly from CI/CD pipelines that push hundreds of times daily. Luna: So they're basically saying: you broke the model, now you pay. Lucas: Pretty much. And to be fair, the per-object fee is reasonable if you're a small team — it's pennies. But enterprise architects need to be aware because it adds up across many repos and regions. The mitigation isn't hard, but it requires planning: consolidate registries, use lifecycle policies aggressively, replicate only to necessary regions, and monitor scan manifest counts in your cost allocation reports. Luna: And if you're on a podcast talking about cloud billing, you're probably the person who'll have to explain this to your VP of Engineering. Lucas: Which is why we do this. If you find these breakdowns useful for what you're building or running — whether you're an architect, a platform engineer, or a finance person trying to understand a surprise line item — listener support is what keeps the show ad-free and independent. You can help at buy me a coffee dot com slash fexingo. Luna: Yeah, it genuinely makes a difference. Every contribution goes straight into research time and better guests. Lucas: Alright — back to the math. One more thing I want to highlight: the scan storage charge also applies to base image layers that never change. If you use a standard Ubuntu 22.04 base, its vuln scan manifest is the same for every image built on top of it. But you pay for each copy. Luna: So you're paying multiple times for scanning the same base image. Lucas: Exactly. Some teams are moving to a 'golden image' pattern where they pull a pre-scanned base from a shared registry and only scan the application layer. That eliminates redundant base image manifests. Luna: Does that actually reduce the stored object count? Lucas: It does, because the scan only covers new layers. If your base image is already in the registry with a known digest, the scan result for the combined image might still reference the base layers, but the registry doesn't store a full duplicate manifest — it stores a differential. At least that's how ECR handles it. But you still pay for the differential storage. Luna: Okay, so the golden image approach reduces the size of each new manifest, but there's still a manifest per image. Lucas: Right. The object count remains the same. The savings come from the per-object fee being fixed regardless of manifest size. So smaller manifests don't save you on object fees, but they reduce byte storage. For most teams, the per-object fee dominates anyway. Luna: So the real lever is reducing the number of images you keep, not the size of the manifests. Lucas: Exactly. That's why lifecycle policies are your best tool. Set them to expire untagged images after 7 days, and tag only releases. For CI/CD, use short-lived tags like 'build-12345' and expire them after 30 days. You'll still have all the scan history you need for compliance, but your object count drops by an order of magnitude. Luna: And if you need to keep images for longer — say for audit — can you offload the scan manifests to cheaper storage? Lucas: You can extract the scan results via the registry API and store them in S3 Glacier or Azure Archive. But that's a custom script, and you lose the ability to view them in the console. Some third-party tools like Anchore or Trivy can export scan results to your own storage and even deduplicate across images. That might be worth it for large fleets. Luna: So the takeaway: scan storage is now a line item, it's driven by object count more than byte size, and you need to actively manage retention. Lucas: That's it. Check your April bill for 'ECRScanStorage' or 'ContainerRegistryScanResultStorage'. If you see a charge you don't recognize, it's probably this. And if you're planning a migration to a new registry, factor this into your TCO. Luna: Good advice. Next episode — reserved compute pricing for container instances. That one's got some surprises too. Lucas: It does. See you then.