Neben den Hosting-Kosten sind beim Bereitstellen von Dateien in der Cloud die sogenannten Egress-Kosten ein wichtiger Aspekt. Um was für Kosten es sich dabei handelt und wie man diese potenziell senken kann, das möchte ich gerne in diesem Blogpost aufzeigen.
Ich traf kürzlich in einem Projekt auf die Fragestellung, ob das vorgesehene Budget für die Nutzung von Amazon S3 für die Bereitstellung umfangreicher Dateien ausreicht. Diese Problemstellung war eng verbunden mit der Frage, wie man Nutzende dazu bekommen könnte, möglichst keine unnötigen Downloads zu tätigen.
Dies sind spannende Fragestellungen, vor allem wenn es sich bei den Daten um umfangreiche offene Daten oder offene Verwaltungsdaten (Open Data bzw. Open Government Data) handelt, die grundsätzlich ohne Einschränkungen der Öffentlichkeit zur Verfügung gestellt werden sollen. Denn in diesem Umfeld fällt die Möglichkeit ausser Betracht, den Zugriff auf die Daten materiell irgendwie einzuschränken (beispielsweise, indem man einen Login erfordert oder Ähnliches).
Bevor wir uns damit befassen, sollten wir aber zuerst ein paar grundlegende Begriffe klären.
Egress vs. Ingress?
Wenn man Dateien in der Cloud speichert, berechnen sich die Kosten üblicherweise gemäss der Nutzung. Doch was heisst «Nutzung» im Cloud-Kontext überhaupt? Weshalb gibt es die Unterscheidung zwischen Ingress, Hosting und Egress? Und was bedeuten diese Begriffe überhaupt?
«Nutzung» kann für die Cloud tatsächlich unterschiedlich verstanden werden. Gebräuchlich sind die folgenden drei Begriffe, wovon der erste noch der am breitesten verstandene ist (vgl. auch die Abbildung):
- Hosting: Prozess der Aufbewahrung von Daten im System: z.B. Aufbewahren einer Datei in der Cloud (kostenpflichtig)
- Ingress: Prozess, in dem Daten ins System kommen (meist kostenlos): z.B. ein Upload einer Datei in die Cloud
- Egress: Prozess, in dem aus dem System fliessen (meist kostenpflichtig): z.B. ein Download einer Datei aus der Cloud
Cloud-Anbieter verrechnen Egress-Kosten unter anderem häufig, weil ihnen selbst durch Egress effektiv Kosten entstehen: Sie müssen die nötige Bandbreite für Downloads zur Verfügung stellen und entsprechende Verbindungen mit Internet-Service-Providern (ISPs) bereithalten. Die Verrechnung von Egress-Kosten dient auch dazu, die Nutzung der Dienste der Cloud-Anbieter zu steuern und zum Beispiel nicht regelmässig grosse Datenmengen über das öffentliche Internet zu verschieben.
Kostenvergleich
Zufälligerweise bin ich vor einigen Tagen über einen Artikel gestossen, der die Egress-Kosten von verschiedenen Cloud-Anbietern vergleicht. Die Unterschiede zwischen den Anbietern sind enorm. Wenn man die grossen Player im Markt vergleicht, gibt es eine Gemeinsamkeit: die Egress-Kosten sind in der Regel so ausgelegt, dass Kundinnen und Kunden einen grossen Anreiz haben, möglichst viele Teile ihrer Infrastruktur beim gleichen Anbieter zu haben. Ein Beispiel: wenn ich das Backup meiner Dateien in einer anderen Cloud habe als das Hosting, habe ich für jeden Backup-Vorgang Egress-Kosten. Typischerweise sind die Gebühren für Datentransfers innerhalb der gleichen Cloud sehr tief.
Es gibt aber auch Ausreisser: Wer nicht auf zum Beispiel spezifische Funktionen oder andere Aspekte des Angebots einer der grossen Dienstleister angewiesen ist, kann sich aktuell Egress-Kosten komplett sparen, wenn er oder sie beispielweise Cloudflare R2 (ein S3-kompatibler Object Storage) einsetzt. Ein Vergleich der Cloudanbieter lohnt sich in jedem Fall, mit möglichst konkreten Zahlen und Anforderungen für den eigenen Anwendungsfall. Je nach Dienst und Region können die Preise stark variieren. Dabei sind auch die häufig vorhandenen Freigrenzen («free allowance») und natürlich mögliche weitere Unterschiede der Angebote zu beachten.
Aber auch unabhängig davon, bei welchem Anbietern man ist, gibt es Möglichkeiten, wie die Egress-Kosten reduziert werden können.
Nutzende mit guter User Experience führen
Angesichts von Egress-Kosten spart jeder nicht gemachte Download Geld. Hinter dieser Binsenwahrheit steckt mehr als auf den ersten Blick ersichtlich ist: Wer viele und umfangreiche Downloads anbietet, die aus der Cloud kommen, tut gut daran, seine Nutzenden so zu führen, dass sie nur wirklich relevante Downloads auslösen. Gerade Anbieter von offenen Daten (Open Data bzw. OGD) stehen hier vor einem Dilemma: einerseits sollen die offenen Daten einer möglichst breiten Öffentlichkeit zugänglich sein, andererseits soll das Download-Budget (Egress) nicht schon bereits nach wenigen Monaten aufgebraucht sein bzw. die Kosten beliebig steigen.
Nutzende müssen also im Idealfall vor einem Download wissen, welche Daten sie vor sich haben. Es braucht klare Inhaltsangaben (Metadaten), Hinweise über die zeitliche, räumliche und/oder allenfalls thematische Abdeckung, idealerweise verbunden mit einer Vorschau der Daten und möglichen Anwendungsfällen – am besten kombiniert mit Hinweisen zur Grösse der Datei, der voraussichtlichen Download-Dauer und allenfalls Angaben zur digitalen Suffizienz (z.B. CO₂-Ausstoss pro Download) und mit der Möglichkeit des Downloads von Testdaten (in Form einer kleinen Stichprobe).
Um das alles zu erreichen, braucht es ein User Interface, das die Nutzenden zielgenau zu den für sie richtigen Daten führt. Umgekehrt müssen die Daten auch so strukturiert vorliegen, wie die Nutzenden diese (am häufigsten) brauchen: Wenn ich Messdaten typischerweise monatlich analysiere, diese aber nur als Gigabyte-grosse Datei über ein ganzes Jahr vorliegen, lade ich immer (für meinen Anwendungsfall) «zu viel» herunter. Dazu ist es unerlässlich mit den eigenen Nutzerinnen und Nutzern zu sprechen, ihre Bedürfnisse zu antizipieren und ihr tatsächliches Verhalten zu analysieren. All dies gehört übrigens zur Expertise unseres User Experience (UX)-Teams.
Technische Massnahmen
Neben einem gut gestalteten User Interface und der angenehmen User Experience gibt es auch noch verschiedene technische Massnahmen, die dabei helfen, die Egress-Kosten zu senken:
- Einsatz eines Content Delivery Networks (CDN): Ein CDN ist ein Cache, der räumlich bzw. «internet-topologisch» möglichst nah bei den Nutzenden Daten zur Verfügung stellt. Dadurch können die Kosten für Datentransfers aus der Cloud selbst reduziert werden.
- Verwendung geeigneter Dateiformate und/oder von Kompression: Ein passendes Datenformat kann die Dateigrösse stark beeinflussen (zum Beispiel Parquet anstatt CSV). Alternativ kann die ganz klassische Kompression, beispielsweise mit Zip/BZip/GZip/Brotli, helfen.
- Monitoring: Um die eigenen Kosten im Griff zu haben, ist es wichtig, ein geeignetes Monitoring aufzusetzen. So kann man frühzeitig Nutzungsmuster erkennen und bei Bedarf (zum Beispiel bei Serien-Downloads) geeignete Massnahmen ergreifen.
- Einschränkung des Zugriffs: Wenn Nutzende die Infrastruktur übermässig beanspruchen, dann ist die Ultima Ratio, den Zugriff zu sperren oder Downloads zumindest zu drosseln (d.h. die Geschwindigkeit von Downloads künstlich zu verringern). Der «Nutzende» kann in diesem Fall beispielsweise ein Skript sein, das zu oft Daten herunterlädt. Zu diesem Zweck ist es hilfreich, entsprechende Bestimmungen in den eigenen Nutzungsbestimmungen zu haben, zum Beispiel eine sogenannte Fair-Use-Klausel, wie sie beispielsweise das Bundesamt für Landestopografie swisstopo kennt.
Stehen Sie auch vor praktischen Herausforderungen bezüglich der Nutzung der Cloud oder vor praktischen UX/UI-Fragen rund um Daten und Online-Angebote? Ich stehe Ihnen gerne für einen Austausch zur Verfügung. Kontaktieren Sie mich unverbindlich.
Headerbild: CC-BY J. Triepke (via Flickr)
Erlaube mir einige ergänzende Gedanken zu den diskutierten Punkten:
Die Idee, die Egress-Kosten auf die Nutzer abzuwälzen, ist sicherlich ein interessanter Ansatz. Insbesondere die "Requester Pays"-Möglichkeit bei AWS S3 bietet eine attraktive Option, die Kosten gerechter zu verteilen. Bei grossen Datenmengen, wie sie z.B. bei der Wetter- und Klimamodellierung anfallen, kann dies eine sinnvolle Strategie sein. Ein möglicher Ansatz wäre, verschiedene Szenarien zu modellieren und bei Erreichen bestimmter Schwellenwerte den "Requester Pays"-Ansatz einzuführen. Dies stellt sicher, dass diejenigen, die die Daten intensiv nutzen, auch angemessen an den entstehenden Kosten beteiligt werden, ohne das Prinzip von Open Data zu gefährden.
Es ist richtig, darauf hinzuweisen, dass bei grossen Datenmengen die Zahl der Nutzer, die diese Daten herunterladen, vergleichsweise gering ist. In vielen Fällen ist es effizienter und sinnvoller, die Daten direkt in der Cloud zu nutzen, anstatt sie herunterzuladen. Dies entspricht dem Businesskonzept der Hyperscaler, die Speicher und Rechenleistung dort zur Verfügung stellen, wo sie benötigt werden. So wird Kundenbindung geschaffen ;-). Darum ist es wichtig, dass die Kontrolle über die Rohdaten in den Händen der Datenherren bleibt, um die digitale Souveränität zu gewährleisten. Daher sollte der Publikationspfad so gestaltet werden, dass ein Wechsel zwischen verschiedenen Hyperscalern problemlos möglich ist, um ein Vendor-Lock-in zu vermeiden.
Der erste Schritt in die Cloud ist, sich selbst die Frage zu stellen, wie man sie wieder verlassen kann um einen Vendor-Lock-in zu vermeiden.
Danke Dave für deine Gedanken. Die Möglichkeit von „Requester Pays“ sind tatsächlich interessant und ich denke es wäre möglich, das auch für Open Data anzubieten. Das würde bedeutet es gibt einen freien Zugang zu den Daten der entsprechend gedrosselt ist, dass das für „normale“ Downloads ausreicht. Wenn man aber regelmässig grössere Datenmengen beziehen will, muss man sich entsprechend authentisieren und dann auch selbst für die Kosten aufkommen.
Ich bin gespannt wie sich das weiterentwickelt mit dem „Daten direkt in der Cloud nutzen“. Mit cloud-native Formaten gibt es ja bereits sehr schöne Anwendungfälle, wie die Blogposts meiner Kollegen zeigen: https://digital.ebp.ch/category/cloud-native/