Ausgangsgeb\u00fchren sind die Geb\u00fchren, die Cloud-Anbieter erheben, wenn Daten ihr Netzwerk verlassen \u2013 sei es ins Internet, in eine andere Region oder zu einem anderen Cloud-Anbieter. Sie kommen f\u00fcr viele Teams \u00fcberraschend, da auf den Preisseiten der Cloud-Anbieter vor allem die Rechen- und Speicherkosten hervorgehoben werden, w\u00e4hrend die Daten\u00fcbertragungsgeb\u00fchren in komplexen, gestaffelten Preislisten versteckt sind, die erst bei Erhalt der Rechnung sichtbar werden. Dieser Artikel erl\u00e4utert, wie Egress-Geb\u00fchren funktionieren, wodurch sie ausgel\u00f6st werden und wie Sie sie mithilfe von FinOps-Verfahren in den Griff bekommen k\u00f6nnen.<\/p>\n\n\n\n
Cloud-Anbieter berechnen Ausgangsgeb\u00fchren auf Basis des Datenvolumens, das aus ihrem Netzwerk \u00fcbertragen wird, gemessen in Gigabyte. Das Abrechnungsmodell ist in der Regel gestaffelt, was bedeutet, dass der Preis pro GB mit steigendem monatlichen \u00dcbertragungsvolumen sinkt. Standardm\u00e4\u00dfig gelten jedoch f\u00fcr die meisten ausgehenden \u00dcbertragungen die Basispreise, und Teams k\u00f6nnen selten absch\u00e4tzen, wie schnell sich diese Gigabyte \u00fcber mehrere Dienste und Regionen hinweg ansammeln.<\/p>\n\n\n\n
Die Funktionsweise ist wie folgt: Ihr Cloud-Anbieter misst jedes Byte, das eine definierte Grenze verl\u00e4sst \u2013 unabh\u00e4ngig davon, ob es sich bei dieser Grenze um ein Rechenzentrum, eine Region oder den Rand des globalen Netzwerks des Anbieters handelt. Am Ende des Abrechnungszeitraums wird das gesamte ausgehende Datenvolumen mit der jeweils geltenden Tarifstufe multipliziert. Da die Erfassung auf Infrastrukturebene erfolgt, haben Anwendungsteams oft erst bei Erhalt der Rechnung Einblick in das von ihren Workloads erzeugte \u00dcbertragungsvolumen.<\/p>\n\n\n\n
Was dies besonders schwierig macht, ist die Tatsache, dass die Preise f\u00fcr den Datenausgang nicht einheitlich sind. Die Tarife variieren je nach Zielort der Daten, dem Dienst, der die \u00dcbertragung generiert, und der betreffenden geografischen Region. Eine \u00dcbertragung von einem Speicher-Bucket zu einer virtuellen Maschine in derselben Region kann kostenlos sein, w\u00e4hrend dieselbe \u00dcbertragung \u00fcber Regionen hinweg deutlich mehr kosten kann.<\/p>\n\n\n\n
Ausgangsgeb\u00fchren fallen bei jeder Daten\u00fcbertragung an, die eine von Ihrem Cloud-Anbieter festgelegte Abrechnungsgrenze \u00fcberschreitet. Die h\u00e4ufigsten Ausl\u00f6ser sind ausgehende \u00dcbertragungen ins \u00f6ffentliche Internet, regionen\u00fcbergreifende \u00dcbertragungen zwischen zwei Regionen desselben Anbieters sowie cloud\u00fcbergreifende \u00dcbertragungen zu einem anderen Cloud-Anbieter oder in eine lokale Umgebung.<\/p>\n\n\n\n
In der Praxis fallen bei den folgenden \u00dcbertragungsarten am h\u00e4ufigsten Ausgangsgeb\u00fchren an:<\/p>\n\n\n\n
\u201eIngress\u201c, also der Datenstrom in die Cloud, ist fast immer kostenlos. Diese Asymmetrie ist beabsichtigt und schafft einen strukturellen Anreiz, der es kosteng\u00fcnstig macht, Daten in das \u00d6kosystem eines Anbieters zu \u00fcbertragen, w\u00e4hrend die \u00dcbertragung aus diesem heraus kostspielig ist.<\/p>\n\n\n\n
Die Kosten f\u00fcr den Datenausgang lassen sich nur schwer vorhersagen, da sie verbrauchsabh\u00e4ngig sind und sich aus dem Verhalten der Anwendung ergeben und nicht aus einer bereitgestellten Ressource mit festem Preis. Im Gegensatz zu Rechenleistung oder Speicher, bei denen sich die Kosten anhand einer bekannten Konfiguration absch\u00e4tzen lassen, h\u00e4ngt das Datenausgangsvolumen davon ab, wie viele Daten Ihre Anwendung tats\u00e4chlich \u00fcbertr\u00e4gt \u2013 was wiederum von der Nutzeraktivit\u00e4t, dem Datenwachstum und den architektonischen Entscheidungen der Entwicklerteams abh\u00e4ngt.<\/p>\n\n\n\n
Mehrere Faktoren tragen zu dieser Unvorhersehbarkeit bei:<\/p>\n\n\n\n
Genau diese Kombination aus dezentraler Entscheidungsfindung und undurchsichtiger Preisgestaltung ist der Grund daf\u00fcr, dass Ausgangsgeb\u00fchren selbst in Unternehmen, die andere Cloud-Kostenkategorien aktiv verwalten, als \u00dcberraschungen auf den Cloud-Rechnungen auftauchen.<\/p>\n\n\n\n
Alle drei gro\u00dfen Cloud-Anbieter erheben Geb\u00fchren f\u00fcr den Datenausgang ins Internet, doch ihre Tarife, die Obergrenzen f\u00fcr kostenlose Kontingente und die Preisstrukturen f\u00fcr regionen\u00fcbergreifende \u00dcbertragungen unterscheiden sich erheblich. Google Cloud hat im Vergleich zu AWS und Azure in der Vergangenheit wettbewerbsf\u00e4higere Preise f\u00fcr den Datenausgang und gro\u00dfz\u00fcgigere kostenlose Kontingente angeboten, w\u00e4hrend AWS f\u00fcr \u00dcbertragungen zwischen Verf\u00fcgbarkeitszonen Geb\u00fchren erhebt, die sich von den Praktiken der anderen Anbieter unterscheiden.<\/p>\n\n\n\n
AWS berechnet f\u00fcr Daten, die ins Internet \u00fcbertragen werden, eine gestaffelte Geb\u00fchrenstruktur und bietet ein kleines monatliches Freikontingent an. Regions\u00fcbergreifende \u00dcbertragungen innerhalb von AWS werden zu einem Pauschalpreis pro GB abgerechnet, der je nach Regionenpaar variiert. Bemerkenswert ist, dass AWS auch den Datenverkehr zwischen Availability Zones (AZs) innerhalb derselben Region in Rechnung stellt, was viele Teams \u00fcberrascht, da Availability Zones innerhalb einer einzigen Region zwar wie eine einheitliche Umgebung wirken, jedoch als separate Abrechnungsbereiche behandelt werden.<\/p>\n\n\n\n
Azure verwendet ein zonenbasiertes Modell, bei dem Regionen in Abrechnungszonen zusammengefasst sind und die \u00dcbertragungsraten f\u00fcr ausgehenden Internetverkehr davon abh\u00e4ngen, zu welcher Zone die Quellregion geh\u00f6rt. Auch regionen\u00fcbergreifende \u00dcbertragungen innerhalb von Azure sind kostenpflichtig. Die Preisstruktur von Azure ist im Gro\u00dfen und Ganzen mit der von AWS vergleichbar, allerdings unterscheiden sich die Zonengruppierungen und Tarifstufen, was einen direkten Vergleich erschwert, ohne die Zahlen f\u00fcr Ihre spezifische Kombination aus Workload und Region zu berechnen.<\/p>\n\n\n\n
Google Cloud bietet in der Regel niedrigere Ausgangsgeb\u00fchren f\u00fcr Internet\u00fcbertragungen und stellt kostenlosen Datenausgang f\u00fcr den \u00fcber sein CDN bereitgestellten Datenverkehr zur Verf\u00fcgung, was die Kosten f\u00fcr inhaltsintensive Workloads erheblich senken kann. Regions\u00fcbergreifende \u00dcbertragungen innerhalb von Google Cloud werden zu Tarifen abgerechnet, die je nach Zielregion variieren. Google bietet in bestimmten Konfigurationen zudem eine kostenlose Ausgehdaten-Stufe f\u00fcr Daten, die an andere Google-Dienste \u00fcbertragen werden, was f\u00fcr Unternehmen von Vorteil sein kann, die bereits mehrere Google-Produkte nutzen.<\/p>\n\n\n\n
Die praktische Erkenntnis daraus ist, dass es keinen Anbieter gibt, der in allen Ausgehdatenstrom-Szenarien am g\u00fcnstigsten ist. Der richtige Vergleich h\u00e4ngt von den spezifischen \u00dcbertragungsmustern, Regionen und Zieltypen Ihrer Workloads ab.<\/p>\n\n\n\n
Teams k\u00f6nnen die Kosten f\u00fcr den ausgehenden Datenverkehr senken, ohne die Architektur komplett umgestalten zu m\u00fcssen, indem sie sich auf die Leitwegf\u00fchrung, das Caching und die \u00dcbertragungsoptimierung auf Konfigurationsebene konzentrieren. Diese \u00c4nderungen erfordern zwar die Mitwirkung der Entwickler, machen jedoch eine Neugestaltung der zugrunde liegenden Anwendungsarchitektur \u00fcberfl\u00fcssig.<\/p>\n\n\n\n
Zu den wirksamsten Taktiken geh\u00f6ren:<\/p>\n\n\n\n
Diese Optimierungen sind am effektivsten, wenn die Entwicklungsteams einen \u00dcberblick dar\u00fcber haben, welche Dienste und Workloads den gr\u00f6\u00dften ausgehenden Datenverkehr verursachen. Ohne diese Detailgenauigkeit ist es schwierig, Priorit\u00e4ten zu setzen und zu entscheiden, worauf man den Fokus legen soll.<\/p>\n\n\n\n
FinOps-Verfahren bringen die Kosten f\u00fcr den Datenausgang unter Kontrolle, indem sie die erforderliche Transparenz, Verantwortlichkeit und den notwendigen Entscheidungsrhythmus schaffen, um auf Daten zu den \u00dcbertragungskosten zu reagieren, anstatt diese lediglich zu beobachten. Die zentrale Herausforderung beim Datenausgang besteht nicht darin, dass die Daten nicht verf\u00fcgbar sind, sondern darin, dass niemand die Verantwortung daf\u00fcr \u00fcbernimmt und es keinen Prozess gibt, um diese Daten in konkrete Ma\u00dfnahmen umzusetzen.<\/p>\n\n\n\n
Die folgenden FinOps-Ma\u00dfnahmen wirken sich direkt auf die ausgehenden Daten\u00fcbertragungskosten aus:<\/p>\n\n\n\n
Der \u00fcbergeordnete Punkt ist, dass Egress-Kosten immer wieder f\u00fcr \u00dcberraschungen sorgen, wenn sich das Cloud-Kostenmanagement auf die Transparenz beschr\u00e4nkt. Um Transparenz in konkrete Ma\u00dfnahmen umzusetzen, sind Governance-Strukturen und funktions\u00fcbergreifende Zusammenarbeit erforderlich, wie sie eine ausgereifte FinOps-Praxis bietet. Mehr \u00fcber den Aufbau einer solchen Praxis erfahren Sie auf unserer Seite zu den FinOps-Diensten<\/a>.<\/p>\n\n\n\n Die Egress-Kosten sind eines der deutlichsten Beispiele f\u00fcr ein allgemeines Muster: Cloud-Ausgaben, die zwar technisch sichtbar, aber praktisch nicht gesteuert werden. Wir unterst\u00fctzen Unternehmen dabei, den Schritt von der reinen Beobachtung der Cloud-Kosten hin zu deren aktiver Steuerung zu vollziehen \u2013 wobei die Egress-Kosten als konkreter und messbarer Ausgangspunkt dienen.<\/p>\n\n\n\n Arbeiten Sie mit uns zusammen an Optimierung der Cloud-Kosten<\/a>, dann erh\u00e4lt man:<\/p>\n\n\n\nSo unterst\u00fctzen wir Sie bei der Steuerung Ihrer Cloud-Ausgangskosten<\/a><\/h2>\n\n\n\n