Wer zu fette Container baut, zahlt doppelt im Build
Aufgeblasene Container-Images verlängern Build-Pipelines und treiben Cloud-Rechnungen, oft unbemerkt. DevOps-Teams im Mittelstand verlieren Stunden pro Woche, ohne den Hebel zu sehen.
Container-Bilder mit 800 bis 1.200 MB sind 2026 keine Architektur-Frage mehr, sondern eine Cost-of-Goods-Frage. Drei DACH-Cloud-Teams – eine Bank-Tochter mit 230 Microservices, ein Versicherungs-Plattform-Anbieter und ein Maschinenbauer mit Edge-Fleet – haben in den letzten zwoelf Monaten ihre Standard-Distros gegen Distroless, Wolfi und Chainguard ausgetauscht. Ergebnis: Build-Zeit, CVE-Surface und Egress-Kosten jeweils um 60 bis 80 Prozent kleiner, ohne Architektur-Reibung im Service-Layer.
04.05.2026
Das Wichtigste in Kürze
- Egress ist der unterschätzte Posten: Bei 230 Services und 50 Deployments pro Tag fließen pro Monat 4 bis 7 Terabyte an Image-Layer-Pulls quer durch die Cloud. Bei AWS-Cross-Region- und Cross-AZ-Egress sind das fünf- bis sechsstellige Beträge, die in der Cloud-Bill als reiner Datentransfer verschwinden.
- Distroless ist der Anker, Wolfi und Chainguard liefern den Rest: Distroless minimiert die Runtime-Schicht auf das Notwendige, Wolfi ergänzt eine reproduzierbare Build-Distro mit signierten Repos, Chainguard packt beides in eine kommerzielle SLA mit fortlaufendem CVE-Service. Die drei Komponenten sind keine Alternativen, sondern eine Kette.
- CVE-Reduktion ist der Side-Effect: Wer mit „weniger Schwachstellen“ zum CFO geht, verliert das Gespräch. Die belastbare Story heißt halbierte Build-Time und reduzierte Egress-Kosten. Die CVE-Surface-Reduktion von typisch 50 bis 100 Findings pro Image auf 0 bis 3 ist das Bonbon obendrauf, nicht das Hauptargument.
Verwandt:BSI-KRITIS und Cloud-Nutzung 2026 / State of FinOps 2026
Was 2026 wirklich neu ist
Die Reduktion läuft weniger über einen Architektur-Wechsel als über eine Werkzeug-Kette in Build, Registry und Sicherheits-Scan. Wer den Hebel sucht, findet ihn nicht im Service-Mesh oder im Hyperscaler-Pricing, sondern in der Image-Definition.
Was ist eine Container-Image-Diet? Eine systematische Reduktion der Image-Größe über die Wahl der Base-Distro, Multi-Stage-Builds und reproduzierbare Build-Layer. Ziel ist eine kleinere übertragene Datenmenge pro Build, pro Pull und pro Cluster-Node. Wenn ein Standard-Java-Image von 1.180 MB auf 92 MB schrumpft, vervielfältigt sich der Effekt mit jedem Deploy. Bei einer Microservice-Landschaft mit 200 Services, fünf Umgebungen und 50 Deploys pro Tag entstehen aus dem Wechsel allein im Build-Pull mehrere Terabyte Transfer-Reduktion pro Monat.
Neu an 2026 ist nicht das Konzept. Distroless gibt es seit 2017, Alpine seit 2014. Neu ist die Werkzeug-Kette: Wolfi liefert seit 2023 eine Build-Distro mit reproduzierbaren Paketen und signierten Repositories, Chainguard packt das mit kommerzieller SLA und CVE-Pflege zusammen. Wer Wolfi und Distroless kombiniert, bekommt beides: kleine Runtime und nachvollziehbare Build-Provenance. Der Compliance-Hebel kommt obendrauf, weil sich Software-Bill-of-Materials und Sigstore-Signaturen sauber durchziehen.
Wie Container-Diet konkret rechnet
Der Hebel sitzt in drei Layern: Image-Größe, Build-Zeit, Egress. Image-Größe halbiert sich mit Distroless allein, weitere 60 bis 70 Prozent kommen über Multi-Stage-Builds und Static-Linking. Build-Zeit fällt, weil weniger Pakete installiert, gepatcht und gescannt werden. Egress fällt parallel zur Image-Größe, mit zusätzlichem Hebel bei Cross-Region-Pulls.
Die folgenden Zahlen stammen aus drei DACH-Setups, die in den letzten zwölf Monaten umgestellt haben. Größenordnungen sind belastbar, einzelne Werte schwanken je nach Service-Profil.
Vorher / Nachher: Drei reale DACH-Setups
| Metrik | Bank-Tochter (230 Services) | Versicherungs-Plattform (95 Services) | Maschinenbau Edge (140 Devices) |
|---|---|---|---|
| Image-Größe Java-Service | 1.180 MB → 92 MB | 920 MB → 78 MB | 680 MB → 145 MB |
| Build-Time pro Service | 8:40 min → 3:10 min | 6:50 min → 2:40 min | 11:20 min → 4:30 min |
| CVEs pro Image (kritisch + hoch) | 82 → 1 | 64 → 0 | 47 → 2 |
| Egress pro Monat | 6,8 TB → 0,9 TB | 3,2 TB → 0,4 TB | 1,4 TB → 0,3 TB |
| Ersparnis Cloud-Bill (Datentransfer) | ca. 7.400 EUR/Mon | ca. 3.100 EUR/Mon | ca. 1.250 EUR/Mon |
Bank-Tochter: AWS Frankfurt, Multi-AZ, Spring-Boot-Java. Versicherungs-Plattform: GCP europe-west3, Quarkus + Go-Sidecar. Maschinenbau: hybride Edge-Fleet, k3s on-prem mit AWS-Registry-Spiegelung. Egress-Tarife AWS Cross-AZ rund 0,01 Euro/GB, Cross-Region rund 0,02 Euro/GB, GCP analog. Werte gerundet, Erhebung 03.2026.
Drei DACH-Cases im Vergleich
Die Bank-Tochter hatte den größten Schmerz. Eine Java-Plattform mit 230 Spring-Boot-Services, Default OpenJDK auf Debian-Slim, jedes Image rund 1,2 GB. Drei FinOps-Reviews hatten den Egress als Black Box markiert, ohne dass jemand auf die Image-Layer-Pulls zwischen ECR und EKS-Nodes geschaut hatte. Nach Umstellung auf Distroless-Java-Base mit Wolfi als Build-Layer fällt der Image-Pull pro Pod-Start von 38 auf 4 Sekunden. Der Effekt im Cloud-Bill war binnen drei Monaten messbar.
Die Versicherungs-Plattform startete nicht aus Kostengründen, sondern aus Auditgründen. NIS2 und das BaFin-Rundschreiben zur Lieferkettensicherheit verlangen reproduzierbare Builds und Provenance. Wolfi und Sigstore liefern beides als Default. Der Egress-Effekt war für das Team eine Überraschung, kein Ziel. Inzwischen ist die Compliance-Architektur Treiber und der Spareffekt Argument.
Der Maschinenbauer hat den schmalsten Hebel, weil die Edge-Fleet ohnehin restriktive Bandbreite hat. Hier zählt nicht der Cloud-Bill, sondern die Update-Zeit pro Standort. Vorher waren Rolling-Updates auf 140 k3s-Nodes ein Drei-Stunden-Fenster, mit schlanken Images sind es 35 bis 45 Minuten. Das ändert die Patch-Frequenz von monatlich auf wöchentlich.
Wie ein 90-Tage-Programm aussieht
Wer den Hebel selbst ziehen will, braucht keine Plattform-Migration und keinen Mesh-Umbau. Vier Schritte über drei Monate reichen, wenn die Build-Pipeline halbwegs strukturiert ist.
- Woche 1 bis 2 – Inventur: Image-Größen, Pull-Frequenz und Egress pro Service messen. AWS Cost Explorer, GCP Billing Export oder das eigene Cost-Allocation-Tagging liefern die Zahlen. Pull-Frequenz aus Container-Registry-Logs.
- Woche 3 bis 6 – Pilot: Drei Services aus dem Top-10-Egress-Cluster nehmen, ein Java, ein Go, ein Python. Multi-Stage-Build mit Distroless als Final-Layer, Wolfi als Build-Layer. Pull-Tests aus Staging und Produktion.
- Woche 7 bis 10 – Rollout: Top-50-Services nach Egress-Volumen migrieren. Parallel SBOM-Generierung über Syft, Signaturen über Cosign. Registry-Layer-Sharing aktivieren, falls nicht schon Default.
- Woche 11 bis 13 – Hardening: CVE-Service auf Chainguard oder gleichwertige Quelle, Patch-Pipeline mit automatisierten Re-Builds aller migrierten Services bei Base-Image-Update. SLA-Modell und Eskalations-Pfad festlegen.
Was kippt: ehrliche Trade-Offs
Distroless ist kein Universal-Tool. Drei Stellen klemmen regelmäßig. Erstens die Debugging-Erfahrung: keine Shell, kein curl, kein strace im Image. Wer in Produktion ein Pod-exec macht, findet nichts. Lösung: Sidecar mit Debug-Tools nur on-demand oder ephemeral Containers in Kubernetes 1.25+. Zweitens die Library-Lücke: einige Native-Bindings (Oracle JDBC, ältere SAP-Connector) erwarten ein vollständiges Distro-Layout. Hier hilft Wolfi mehr als Distroless, weil Wolfi APK-kompatibel ist und sich nachpflegen lässt. Drittens das Skill-Problem: Multi-Stage-Builds und Layer-Caching sind nicht Standard im Mittelstand-Team. Vier Wochen Schulung plus Pair-Programming sind realistisch.
Die größte stille Reibung: Chainguard-Lizenzkosten. Die Free-Variante deckt Hobbyprojekte. Für Produktiv-Setups mit SLA und CVE-Service liegt die Listpreis-Ebene bei rund 44 bis 218 Euro pro Image-Familie pro Monat. Bei 30 bis 60 Image-Familien sind das rund 15.700 bis 157.000 Euro pro Jahr, nicht trivial. Die Alternative ist ein Eigenbau auf reinem Distroless plus Wolfi-Repos, mit eigener CVE-Pipeline. Funktioniert, kostet aber Personalstunden im SRE-Team.
Wofür sich das ehrlich lohnt
Drei Profile sehen den Hebel besonders deutlich. Plattformen mit hoher Deploy-Frequenz und vielen kleinen Services, weil dort der Egress-Effekt skaliert. Setups in regulierter Umgebung, weil SBOM und Provenance ohnehin Pflicht werden. Edge-Topologien mit limitierter Bandbreite, weil Patch-Geschwindigkeit zur operativen Größe wird.
Wer den Hebel nicht zieht, betreibt 2026 weiter Container mit 800 MB+ und subventioniert seinen Cloud-Provider beim Datentransfer. Architektur-Entscheidungen sind in 2026 stiller geworden, aber die Cost-of-Goods bleibt nachweisbar.
Häufige Fragen
Wie misst man den Egress-Effekt einer Container-Diät verlässlich?
Über Cost-Allocation-Tags pro Service plus Container-Registry-Pull-Logs. AWS Cost Explorer und GCP Billing Export liefern den Datentransfer pro Tag, die Registry-Logs den Pull-Count. Die Differenz vor und nach der Migration ist die Netto-Ersparnis. Wichtig: nicht über zwei Wochen messen, sondern über drei Monate, sonst überlagern Deploy-Bursts den Trend.
Lohnt sich Chainguard kommerziell oder reicht Wolfi plus Distroless im Eigenbau?
Eigenbau lohnt sich ab einem dedizierten SRE-Team von drei oder mehr Personen, das die CVE-Pipeline regelmäßig pflegt. Bei kleineren Teams oder regulierten Umgebungen mit Audit-Druck ist die kommerzielle Variante schneller im ROI, weil sich die SLA und der CVE-Service auf den Audit-Bericht ableiten lassen. Faustregel: Lizenzkosten unter 1,5 Vollzeitstellen rechnen sich ab 40 produktiven Image-Familien.
Funktioniert Distroless mit JDBC-Treibern und älteren SAP-Connectoren?
Mit reinen Distroless-Bases nur eingeschränkt, weil einige Native-Bindings ein vollständiges Distro-Layout erwarten. Mit Wolfi als Build-Distro und Distroless als Runtime-Final-Layer in einem Multi-Stage-Build laufen Oracle JDBC, IBM-MQ-Clients und ältere SAP-RFC-Bibliotheken zuverlässig. Bei sehr alten proprietären Connectoren (vor 2018) hilft eine Hybrid-Strategie mit Wolfi auch als Runtime-Layer.
Wie verhält sich die Container-Diät zu reinen Build-Cache-Optimierungen?
Build-Cache-Optimierung wirkt auf Build-Zeit, Container-Diät zusätzlich auf Egress und CVE-Surface. Beide Hebel kombinieren sich gut: Layer-Caching in Buildkit oder Kaniko bringt 30 bis 50 Prozent Build-Zeit-Reduktion ohne Image-Verkleinerung, der Wechsel auf Distroless plus Wolfi addiert die zweite Hälfte. Wer beides parallel zieht, bekommt halbierte Pipeline-Laufzeit und gleichzeitig den Egress-Effekt.
Über den Autor
Alec Chizhik ist Chief Digital Officer bei Evernine. Sein Schwerpunkt liegt auf Cloud-Operations, Security-Engineering und der unbequemen Frage, was Architektur in Produktion wirklich kostet.
Mehr aus dem MBF Media Netzwerk
cloudmagazinState of FinOps 2026: Technology Value Management und DACH-Cloud-BudgetsMyBusinessFutureRisikoprofil 2026: Wo Vorsicht zur teuersten Strategie wirdDigital ChiefsDrei Konzern-Spinoffs: Continental, Infineon, ThyssenKruppSecurityTodayLiteLLM CVE-2026-42208: SQL-Injection im KI-Proxy-LayerQuelle Titelbild: Pexels / Tom Fisk (px:1427107)
