7 Min. Lesezeit

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.

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.

1. 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.
2. 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.
3. 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.
4. 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 50 bis 250 USD pro Image-Familie pro Monat. Bei 30 bis 60 Image-Familien sind das 18.000 bis 180.000 USD 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.

Quelle Titelbild: Pexels / Tom Fisk (px:1427107)