Google öffnet sein internes WAN für Cloud-Kunden und verkauft Latenz als Frontend-Thema

Was Google tatsächlich angekündigt hat

Auf der Next 25 hat Google Cloud WAN angekündigt und macht sein globales Weitverkehrsnetz erstmals externen Kunden zugänglich. Das Netzwerk läuft seit 25 Jahren intern und umfasst heute 3,2 Millionen Kilometer aktive Glasfaser, 33 Seekabel und 202 Netzwerk-Edge-Standorte, die 42 Cloud-Regionen und 127 Cloud-Zonen verbinden.

Der Pitch an Unternehmen lautet Konsolidierung. Group Product Manager Satish Kondalam beschreibt Kunden, die separate Lösungen für Standortvernetzung, Internetzugang und Cloud-Dienste zusammenflicken — mit dem Ergebnis fragmentierter Netzwerke und inkonsistenter Sicherheit. Cloud WAN verbindet Niederlassungen, Campusstandorte, öffentliche und private Cloud-Anwendungen, SaaS und das Internet über Cloud Interconnect und Cross-Cloud Interconnect.

Der rote Faden ist durchgängig die KI-Ära: Google zufolge haben KI-gestützte Apps und Modelltraining zwischen 2020 und 2025 zu einer siebenfachen Steigerung der WAN-Bandbreite geführt, bewältigt durch eine „Multi-Shard-Horizontal-Netzwerkarchitektur“, bei der jeder Shard eine unabhängige Instanz des Netzwerks ist, die intern oder durch das Hinzufügen weiterer Shards skaliert werden kann.

Das Premium-Tier-Detail, das für nutzerorientierte Apps zählt

Mitten in der Infrastrukturgeschichte steckt eine Aussage, die direkt an alle geht, die ein Frontend ausliefern: Das Premium-Tier-Netzwerk „stellt sicher, dass Traffic über den geografisch nächstgelegenen Netzwerk-Edge-Standort mit Cloud WAN verbunden wird — für geringere Latenz und ein besseres Nutzererlebnis.“

Das ist Edge-Routing als Produkt verkauft. Bei einer Web- oder Mobile-Anwendung ist die Distanz zwischen Nutzer und dem Punkt, an dem dessen Traffic ins Backbone des Anbieters eintritt, eine der wenigen Latenz-Stellschrauben, die sich nicht im Code beheben lässt. Google bietet an, diesen ersten Hop über 202 Edge-Standorte zu verkürzen.

Der Kundenbeleg ist eine Performance-Zahl, keine Bandbreiten-Spezifikation. Nestlé berichtete nach der Einführung von Cloud WAN und dem Einsatz des Premium-Tier-Netzwerks zur Anbindung von Niederlassungen an das eigene Cloud-Ökosystem, dass die App-Performance um 40 % gestiegen sei — bei gleichzeitig gesunkenen Kosten. Das ist die Art von Zahl, mit der ein Frontend- oder Platform-Team etwas anfangen kann — sie macht das Backbone zu etwas, das Endnutzer spüren.

Die Resilienz-Geschichte ist eine Delivery-Geschichte

Der Artikel beginnt mit der Beschädigung von Seekabeln vor Westafrika im März 2024, bei der vier Seekabel durchtrennt wurden und sich Ausfälle von Côte d'Ivoire bis Südafrika ausbreiteten. Googles Equiano-Kabel, das über mehr als 14.000 Kilometer von Portugal nach Südafrika verläuft, blieb aktiv — Unternehmen, die es nutzten, blieben online, während andere zusätzliche Kapazität kaufen mussten, um wieder Anschluss zu bekommen.

Für Anwendungen ist diese Resilienz nicht abstrakt. Subhasree Mandal beschreibt die Entwicklung des Netzwerks als Abfolge von Delivery-Problemen: Zuverlässigkeit und Skalierung für Search und Ads, hochwertiges Video für YouTube, und schließlich regionale Zuverlässigkeit und Sicherheit, sobald Google nicht mehr nur den eigenen, sondern auch den Traffic von Kunden trug.

Wir haben Cloud WAN ursprünglich nur für Google gebaut, und jetzt bauen wir es für alle. Bei der Vielfalt der Anwendungen, die wir betreiben, und dem Datenvolumen ist das eine enorme Verantwortung — man könnte fast sagen: unangenehm aufregend.Montana Labs

Die Konsequenz: Routing wird zur Build-Time-Entscheidung

Was sich für Anwendungsteams durch Cloud WAN ändert, ist die Frage, wo die Verantwortung für Latenz und Resilienz liegt. Bisher blieb die Wahl, wie der Traffic der Nutzer die eigene Cloud erreicht, oft dem überlassen, was das Firmennetzwerk oder das öffentliche Internet gerade lieferte. Cloud WAN macht aus diesem Pfad etwas, das man selbst bereitstellt und bezahlt — mit einer Stufe, die den Eintrittspunkt der Nutzer gezielt optimiert.

Der ehrliche Vorbehalt: Die Beleglage ist dünn — ein namentlich genannter Kunde, eine selbst berichtete 40-%-Zahl und keine erkennbare Methodik dahinter. Teams sollten diese Zahl als zu prüfende Behauptung gegen den eigenen Traffic behandeln, nicht als Benchmark. Die Richtung ist trotzdem klar: Google lädt Frontend- und Platform-Engineers ein, das Backbone als Teil ihres Performance-Budgets zu betrachten — genauso, wie sie bereits über CDN-Platzierung und Bundle-Größe nachdenken.