Guides

Bloated Containers Cost You Double in the Build

Bloated container images extend build pipelines and increase cloud bills, often unnoticed. DevOps teams in mid-sized companies lose hours

By Alec Chizhik May 4, 2026 8 min read

Bloated Containers Cost You Double in the Build

Container images ranging from 800 to 1,200 MB will no longer be an architectural question but a cost-of-goods issue by 2026. Three DACH cloud teams–one bank subsidiary with 230 microservices, an insurance platform provider, and a machinery manufacturer with an edge fleet–have replaced their standard distributions with Distroless, Wolfi, and Chainguard over the past twelve months. The result: build time, CVE surface, and egress costs have each decreased by 60 to 80 percent without any architectural friction in the service layer.

04.05.2026

Key Takeaways

Egress is the overlooked expense: With 230 services and 50 deployments per day, 4 to 7 terabytes of image layer pulls flow through the cloud each month. AWS cross-region and cross-AZ egress costs can be five- to six-digit figures that vanish as pure data transfer in the cloud bill.
Distroless is the foundation, Wolfi and Chainguard provide the rest: Distroless minimizes the runtime layer to the essential, Wolfi adds a reproducible build distribution with signed repositories, and Chainguard combines both in a commercial SLA with ongoing CVE management. These three components are not alternatives but a chain.
CVE reduction is the side effect: Those who approach the CFO with “fewer vulnerabilities” will lose the conversation. The compelling story is halved build time and reduced egress costs. The typical CVE surface reduction from 50 to 100 findings per image to 0 to 3 is the icing on the cake, not the main argument.

What’s Truly New in 2026

The reduction is less about an architectural shift and more about a toolchain in build, registry, and security scanning. Those seeking leverage will not find it in the service mesh or hyperscaler pricing, but in the image definition.

What is a container image diet? A systematic reduction of image size through the choice of base distribution, multi-stage builds, and reproducible build layers. The goal is a smaller transferred data volume per build, per pull, and per cluster node. If a standard Java image shrinks from 1,180 MB to 92 MB, the effect multiplies with each deployment. In a microservice landscape with 200 services, five environments, and 50 deployments per day, the switch alone can result in several terabytes of transfer reduction per month.

What’s new in 2026 is not the concept. Distroless has been around since 2017, and Alpine since 2014. What’s new is the toolchain: Wolfi has been providing a reproducible build distribution with signed repositories since 2023, and Chainguard combines this with commercial SLA and ongoing CVE management. Those who combine Wolfi and Distroless get both: a smaller runtime and reproducible build provenance. Compliance is the icing on the cake, as software bill-of-materials and Sigstore signatures pass through cleanly.

How Container Diets Actually Work

The key lies in three layers: image size, build time, and egress. Image size is halved with Distroless alone, with an additional 60 to 70 percent reduction achieved through multi-stage builds and static linking. Build time decreases because fewer packages need to be installed, patched, and scanned. Egress reduction parallels image size, with additional savings when pulling across regions.

The following figures come from three DACH setups that have been converted over the past twelve months. The scale is significant, with individual values varying depending on the service profile.

Before / After: Three Real-World DACH Setups

Metric	Bank Subsidiary (230 Services)	Insurance Platform (95 Services)	Machine Building Edge (140 Devices)
Java Service Image Size	1.180 MB → 92 MB	920 MB → 78 MB	680 MB → 145 MB
Build Time per Service	8:40 min → 3:10 min	6:50 min → 2:40 min	11:20 min → 4:30 min
CVEs per Image (Critical + High)	82 → 1	64 → 0	47 → 2
Egress per Month	6,8 TB → 0,9 TB	3,2 TB → 0,4 TB	1,4 TB → 0,3 TB
Cloud Bill Savings (Data Transfer)	approx. €7,400/month	approx. €3,100/month	approx. €1,250/month

Bank Subsidiary: AWS Frankfurt, Multi-AZ, Spring-Boot-Java. Insurance Platform: GCP europe-west3, Quarkus + Go-Sidecar. Machine Building: Hybrid Edge Fleet, k3s on-prem with AWS Registry Mirroring. Egress rates for AWS Cross-AZ are around 0.01 euros/GB, Cross-Region around 0.02 euros/GB, and GCP is similar. Values are rounded, data collection as of March 2026.

// Key point

Container images ranging from 800 to 1,200 MB will no longer be an architecture question by 2026 but a cost-of-goods issue.

Three DACH-Case Comparisons

The bank subsidiary experienced the most significant pain. It had a Java platform with 230 Spring Boot services, using the default OpenJDK on Debian-Slim, each image approximately 1.2 GB in size. Three FinOps reviews had marked the egress as a black box, without anyone examining the image layer pulls between ECR and EKS nodes. After transitioning to Distroless-Java-Base with Wolfi as the build layer, the image pull time per pod start decreased from 38 seconds to 4 seconds. The impact on the cloud bill was measurable within three months.

The insurance platform did not initiate the change for cost reasons but rather due to audit requirements. NIS2 and the BaFin circular on supply chain security demand reproducible builds and provenance. Wolfi and Sigstore both provide these features by default. The reduction in egress was unexpected for the team and not a primary goal. Currently, the compliance architecture is a driver, and the cost-saving effect is an added argument.

The machine builder faced the most delicate lever, as the edge fleet already had restrictive bandwidth. Here, the focus was not on the cloud bill but on the update time per location. Previously, rolling updates on 140 k3s nodes required a three-hour window; with leaner images, this has been reduced to 35 to 45 minutes. This change increases the patch frequency from monthly to weekly.

What a 90-Day Program Looks Like

Those who want to pull the lever themselves do not need a platform migration or mesh restructuring. Four steps over three months are sufficient if the build pipeline is somewhat structured.

Weeks 1 to 2 – Inventory: Measure image sizes, pull frequency, and egress per service. AWS Cost Explorer, GCP Billing Export, or custom cost allocation tagging provide the numbers. Pull frequency from container registry logs.
Weeks 3 to 6 – Pilot: Select three services from the top 10 egress cluster: one Java, one Go, one Python. Implement multi-stage builds with Distroless as the final layer and Wolfi as the build layer. Conduct pull tests in staging and production environments.
Weeks 7 to 10 – Rollout: Migrate top 50 services by egress volume. Enable registry layer sharing if not already default. Generate SBOMs concurrently using Syft and sign images with Cosign.
Weeks 11 to 13 – Hardening: Replace CVE service with Chainguard or equivalent sources. Establish an automated rebuild pipeline for all migrated services upon base image updates. Define SLA models and escalation paths.

What’s at Stake: Honest Trade-offs

Distroless is not a universal tool. Three common issues arise regularly. First, debugging experience: no shell, no curl, no strace in the image. If a production pod-exec is performed, nothing is found. Solution: Deploy sidecar with debugging tools on-demand or use ephemeral containers in Kubernetes 1.25+. Second, library gaps: Some native bindings (Oracle JDBC, older SAP connectors) require a full distro layout. Here, Wolfi is more effective than Distroless because Wolfi is APK-compatible and can be maintained. Third, skill gap: Multi-stage builds and layer caching are not standard in mid-sized teams. Four weeks of training plus pair programming are realistic.

The biggest silent friction: Chainguard licensing costs. The free version covers hobby projects. For production setups with SLA and CVE service, the cost ranges from around 44 euros to around 218 euros per image family per month. For 30 to 60 image families, this translates to around 15,700 euros to around 157,000 euros annually, which is not trivial. The alternative is a self-built solution on pure Distroless plus Wolfi repositories, with a custom CVE pipeline. This works but requires engineering hours in the SRE team.

What It’s Truly Worth

Three profiles highlight the benefits most clearly. Platforms with high deployment frequency and many small services, as the egress effect scales there. Setups in regulated environments, as SBOM and provenance are already mandatory. Edge topologies with limited bandwidth, as patch speed becomes operational scale.

Those who don’t leverage this advantage will continue to operate with 800 MB+ containers in 2026 and subsidize their cloud provider for data transfer. While architectural decisions may seem stagnant by 2026, the cost of goods remains evident.

Frequently Asked Questions

How do you reliably measure the egress effect of a container diet?

By using cost allocation tags per service plus container registry pull logs. AWS Cost Explorer and GCP Billing Export provide the data transfer per day, while the registry logs give the pull count. The difference before and after the migration is the net savings. Important: Do not measure over two weeks, but over three months, otherwise deployment bursts will overshadow the trend.

Is Chainguard commercially viable or is Wolfi plus Distroless sufficient for in-house development?

In-house development is viable with a dedicated SRE team of three or more people that regularly maintains the CVE pipeline. For smaller teams or regulated environments with audit pressure, the commercial variant offers a faster ROI as the SLA and CVE service can be derived from the audit report. Rule of thumb: License costs under 1.5 full-time equivalents make sense with 40 productive image families.

Does Distroless work with JDBC drivers and older SAP connectors?

With pure Distroless bases, it works only to a limited extent, as some native bindings expect a complete distro layout. Using Wolfi as the build distro and Distroless as the runtime final layer in a multi-stage build ensures reliable operation of Oracle JDBC, IBM MQ clients, and older SAP RFC libraries. For very old proprietary connectors (pre-2018), a hybrid strategy with Wolfi as the runtime layer also helps.

How does a container diet relate to pure build cache optimizations?

Build cache optimization affects build time, while a container diet additionally impacts egress and CVE surface. Combining both yields good results: Layer caching in Buildkit or Kaniko brings a 30 to 50 percent reduction in build time without image shrinkage, and switching to Distroless plus Wolfi adds the second half. Those who implement both simultaneously achieve halved pipeline runtimes and simultaneously the egress effect.

About the Author

Alec Chizhik is the Chief Digital Officer at Evernine. His focus is on cloud operations, security engineering, and the uncomfortable question of what architecture really costs in production.