Cloud Egress Fees im Vergleich: AWS vs. Azure vs. GCP Preise

Wer einen neuen Cloud-Anbieter evaluiert, schaut zuerst auf den Instance-Preis. Das ist verständlich und trotzdem ein Fehler. Denn der eigentliche Kostentreiber steht klein gedruckt im Preisblatt: Egress Fees, also Gebühren für ausgehenden Datenverkehr. Bei datenintensiven Anwendungen können diese Kosten die reine Compute-Rechnung übertreffen. Wer das ignoriert, wundert sich am Ende des Monats.
Was sind Egress Fees und wie entstehen sie?
Cloud-Anbieter unterscheiden beim Datenverkehr grundsätzlich zwischen zwei Richtungen: Ingress (Daten fließen ins Rechenzentrum hinein) und Egress (Daten verlassen das Rechenzentrum). Ingress ist bei fast allen großen Anbietern kostenlos. Egress nicht.
Das gilt unabhängig davon, wohin die Daten fließen: zum Endnutzer ins Internet, in eine andere Cloud-Region desselben Anbieters oder zu einem anderen Cloud-Anbieter. Jede dieser Routen hat einen eigenen Tarif und alle davon kosten extra.
Das Modell ist nicht neu. Es geht auf die frühen Zeiten der Public Cloud zurück, als Bandbreite tatsächlich knapp und teuer war. Heute ist sie es auf Infrastrukturebene längst nicht mehr, die Preise für Egress bei den Hyperscalern haben sich aber kaum bewegt.
Das Preismodell der Hyperscaler im Detail
Die großen drei, AWS, Azure und GCP, folgen einem ähnlichen Schema. Konkrete Zahlen (Stand 2025, Region EU):
AWS: Egress ins Internet kostet ab dem ersten GB ca. 0,09 USD/GB (nach 100 GB Freikontingent pro Monat). Transfer zwischen AWS-Regionen liegt bei ca. 0,02–0,08 USD/GB je nach Region. Transfer zwischen Availability Zones innerhalb einer Region: 0,01 USD/GB – in beide Richtungen.
Azure: Egress ins Internet zwischen 0,05 und 0,087 EUR/GB (nach 5 GB Freikontingent). Zonen-übergreifender Transfer: 0,01 EUR/GB.
GCP: Egress ins Internet ab 0,085 USD/GB. Zwischen Zonen: 0,01 USD/GB.
Diese Zahlen klingen klein. Sie sind es nicht, wenn die Anwendung täglich mehrere Terabyte überträgt.
Besonderheit Kubernetes: Egress zwischen Availability Zones
In Kubernetes-Clustern, die über mehrere Availability Zones verteilt laufen, entsteht eine zusätzliche Kostendimension: Pods kommunizieren miteinander quer über Zonen und jedes Byte auf diesem Weg kostet. Gerade bei Microservice-Architekturen mit hohem internen Traffic summiert sich das schnell.
Eine oft genutzte Gegenmaßnahme ist Topology-Aware Routing: Kubernetes kann so konfiguriert werden, dass Pods bevorzugt mit Endpunkten in derselben Zone kommunizieren. Das reduziert zonen-übergreifenden Traffic deutlich, erfordert aber bewusstes Setup und ist kein Default.
Wie Egress Fees zum Lock-in-Mechanismus werden
Egress-Kosten wirken in zwei Richtungen. Einerseits fallen sie im laufenden Betrieb an. Andererseits schützen sie den Anbieter vor Kundenwechsel: Wer seine Daten zu einem anderen Anbieter migrieren will, zahlt dafür Egress-Gebühren auf Basis aller Daten, die das Rechenzentrum verlassen. Bei mehreren Hundert Terabyte kann das eine erhebliche Einmalzahlung bedeuten.
Dieses strukturelle Cloud Vendor Lock-in ist kein Zufall. Die EU-Kommission hat das erkannt: Der EU Data Act verpflichtet Cloud-Anbieter unter anderem dazu, Wechsel durch reduzierte oder abgeschaffte Switching Costs zu erleichtern – und sieht vor, dass Egress-Gebühren bis 2027 vollständig entfallen.
Für DevOps-Teams bedeutet das: Portabilität und Migrationsfähigkeit einer Architektur sollten von Anfang an mitgedacht werden – eine durchdachte Cloud Exit Strategie hilft, diese Risiken frühzeitig zu adressieren.
Egress Fees in der Praxis: Konkrete Kostenbeispiele
Ein realistisches Szenario: Eine SaaS-Anwendung überträgt 10 TB Daten pro Monat ins Internet. Ein normaler Wert für ein mittelgroßes Produkt mit aktivem Nutzerkreis.
Bei AWS (EU-Region):
10.000 GB × 0,09 USD = 900 USD/Monat. Nur für Egress. Hinzu kommen Compute, Storage und ggf. zonen-interner Traffic.
Bei einem europäischen Anbieter mit 20 TB inkludiertem Traffic:
0 USD für Egress. Bis zur Freimenge.
Der Unterschied über ein Jahr: knapp 10.800 USD, allein durch den Posten Datenübertragung. Compute-Kosten noch nicht mitgerechnet.
Das ist kein extremes Beispiel. Es ist ein typisches.
TCO statt Listenpreis: So berechnest du die echten Cloud-Kosten
Total Cost of Ownership (TCO) im Cloud-Kontext umfasst mehr als Compute und Storage. Eine vollständige Rechnung berücksichtigt:
- Egress ins Internet (nach Volumen)
- Egress zwischen Regionen und Availability Zones
- Egress zu anderen Cloud-Diensten (z. B. CDN, externe APIs)
- Support-Kosten (Basis-Support ist bei Hyperscalern oft kostenpflichtig)
- Lizenzkosten für proprietäre Dienste (Load Balancer, Managed Services)
- Migrationskosten beim Wechsel
Wer diese Posten in ein Spreadsheet einträgt und auf Basis der eigenen Traffic-Profile hochrechnet, bekommt schnell ein realistischeres Bild als der erste Blick auf die Instance-Preisliste liefert.
Checkliste: Was beim Anbietervergleich zu beachten ist
- Egress-Tarif ins Internet (pro GB, nach Freikontingent)
- Freimenge pro Monat – absolut oder prozentual?
- Kosten für Transfer zwischen Regionen und Zonen
- Kosten für ausgehenden Traffic zu CDN-Providern
- Enthaltener Traffic bei Managed Kubernetes Angeboten
- Switching-Kosten bei Kündigung (Egress für Datenmigration)
- Transparenz der Preisstruktur – ist alles auf einer Seite zusammengefasst?
Alternativen zu den Hyperscalern: Was europäische Anbieter anders machen
Während AWS, Azure und GCP ihr Egress-Modell als Standard etabliert haben, gehen europäische Cloud-Anbieter teils einen anderen Weg: inkludierter Traffic, Flatrate-Modelle oder deutlich niedrigere Tarife pro GB.
Das ist kein reines Kostenargument. Für Unternehmen mit Sitz in der EU kommen Datenschutz, DSGVO-Konformität und digitale Souveränität als weitere Faktoren hinzu. Wer Workloads nicht auf Infrastruktur außerhalb der EU betreiben darf oder will, hat bei den Hyperscalern zwar EU-Regionen, aber keine EU-Unternehmen als Vertragspartner.
Egress Fees sind kein technisches Detail. Sie sind ein Preismodell, das darauf ausgelegt ist, im Hintergrund zu wirken, bis die erste überraschende Rechnung kommt. Wer seine Cloud-Kosten wirklich verstehen will, rechnet mit TCO, nicht mit dem günstigsten Instance-Typ. Und wer Flexibilität und Kostenklarheit ernst nimmt, sollte beim nächsten Anbietervergleich Traffic-Kosten genauso gewichten wie CPU und RAM.
Full-Stack Developer: Was der Begriff wirklich bedeutet
Was Full-Stack-Entwicklung heute konkret bedeutet, wo die eigentlichen Probleme liegen und wie Entwickler damit umgehen, ohne sich dabei aufzureiben.
Bring Your Own Cloud: Was das Modell bedeutet und warum es Fahrt aufnimmt
BYOC ist kein weiterer Cloud-Flavour, sondern ein anderes Liefermodell: Der Anbieter deployt in deine Infrastruktur. Was das technisch bedeutet und für wen es relevant ist.