Hyperscaler

Als Hyperscaler bezeichnet man die Betreiber sehr großer Cloud-Infrastrukturen — Amazon Web Services, Microsoft Azure, Google Cloud, dazu Meta, Oracle und die chinesischen Anbieter. Gemeint ist nicht nur Größe, sondern eine andere Bauweise.

Was Hyperscaler anders machen

Sie skalieren in die Breite. Statt einzelne Maschinen größer zu bauen, werden viele gleichartige nebeneinandergestellt und über Software zusammengeschaltet. Ausfälle einzelner Server werden dabei eingeplant, nicht vermieden — die Verfügbarkeit entsteht in der Anwendungsschicht, nicht in der Hardware.

Sie bauen ihre eigene Technik. Server, Racks, Netzkarten, teils eigene Prozessoren, eigene Schaltschränke, eigene Betriebssysteme. Was ein Colocation-Kunde kauft, entwerfen sie selbst, weil sich bei ihren Stückzahlen jede eingesparte Komponente rechnet.

Sie bauen ihre eigenen Netze. Eigene Glasfaserstrecken zwischen den Standorten, Beteiligungen an Seekabeln, direkte Anbindung an Austauschpunkte. Ein Hyperscaler ist zugleich ein großer Netzbetreiber.

Region, Zone, Edge

Die Begriffe sind bei allen Anbietern ähnlich aufgebaut, und sie erklären, warum die Frage nach dem Standort selten die Antwort bekommt, die man erwartet.

Eine Region ist ein geografisches Gebiet — etwa Frankfurt oder Irland —, in dem ein Anbieter Dienste bereitstellt. Sie ist die Einheit, in der Kunden buchen und in der Datenhaltung zugesagt wird.

Eine Availability Zone ist ein Teil davon, der eigenständig mit Strom, Kühlung und Netz versorgt wird und weit genug von den anderen Zonen entfernt liegt, dass ein lokales Ereignis nicht alle trifft. Eine Zone besteht aus einem oder mehreren Rechenzentren. Wer Ausfallsicherheit will, verteilt seine Anwendung über mehrere Zonen — das ist die Georedundanz der Cloud, in kleinerem Maßstab.

Edge Locations sind kleine, weit verteilte Standorte nahe am Nutzer, für Auslieferung und kurze Antwortzeiten. Sie enthalten keine vollständige Region.

Warum es keine Adressen gibt

Hyperscaler veröffentlichen Regionen und Zonen, aber keine Gebäudeanschriften. Begründet wird das mit Sicherheit, und die Begründung ist nicht vorgeschoben: Ein Gebäude, dessen Funktion öffentlich bekannt ist, wird zum Ziel.

Für Verzeichnisse hat das eine unangenehme Folge. Die Standorte dieser Anbieter sind in Datenbanken wie PeeringDB kaum zu finden, weil sie dort allenfalls ihre Peering-Präsenz eintragen — und die liegt in fremden Carrier-Hotels, nicht in ihren eigenen Häusern.

Wo sie dennoch sichtbar werden, liegt es an der Bauverwaltung: Baugenehmigungen, Umspannwerke und Lokalpresse machen Vorhaben öffentlich, lange bevor der Betreiber etwas sagt. Im Rechenzentrums-Verzeichnis tauchen Hyperscaler deshalb fast nur als Bauprojekte auf, kaum als Bestand.

Peering-Standort und eigenes Rechenzentrum zu verwechseln, ist der häufigste Fehler beim Lesen solcher Daten. Dass ein Anbieter in einem Frankfurter Colocation-Haus erreichbar ist, heißt nicht, dass seine Server dort stehen.

Abgrenzung zum Colocation-Anbieter

Ein Colocation-Betreiber vermietet Fläche, Strom, Kühlung und Anbindung; die Technik gehört dem Kunden. Sein Geschäft ist das Gebäude, und er ist daran interessiert, möglichst viele Netze ins Haus zu holen.

Ein Hyperscaler betreibt die Technik selbst und verkauft deren Leistung. Das Gebäude ist für ihn Mittel zum Zweck und wird meist selbst gebaut, sobald die Größe es rechtfertigt.

Beide brauchen einander trotzdem: In der Anfangsphase einer Region mietet auch ein Hyperscaler zu, und seine Peering-Präsenz bleibt dauerhaft in fremden Häusern.

Souveränitätsangebote

Auf die Diskussion um den CLOUD Act haben die großen Anbieter mit eigenständig verfassten europäischen Einheiten reagiert: getrennte Gesellschaften, europäisches Personal, getrennte Schlüsselverwaltung, teils Betrieb durch einen lokalen Partner.

Technisch sind das weiterhin dieselben Plattformen. Ob die rechtliche Trennung hält, ist nicht entschieden — und genau das ist der Punkt, an dem europäische Anbieter ihr Argument ansetzen.