Dieses Dokument unterstützt Cloud-Architekten und Experten für den Systembetrieb bei der Entscheidung, wie Google Cloud mit anderen Cloud-Dienstanbietern (Cloud Service Providers, CSPs) wie Amazon Web Services (AWS) und Microsoft Azure verbunden werden soll. In einer Multi-Cloud-Umgebung ermöglichen Verbindungen zwischen CSPs Datenübertragungen zwischen Ihren virtuellen Netzwerken. Dieses Dokument enthält auch Informationen zum Implementieren der von Ihnen ausgewählten Option.
Viele Organisationen nutzen mehrere Cloud-Plattformen, entweder provisorisch während einer Migration oder im Rahmen einer langfristigen Multi-Cloud-Strategie.
Dieses Dokument bietet Informationen zu den zahlreichen Methoden für den Datenaustausch zwischen Google Cloud und anderen CSPs:
- Datenübertragung mit öffentlichen IP-Adressen über das Internet
- Verwenden eines verwalteten VPN-Diensts zur Verbindung der GCP mit dem anderen CSP
- Verwenden von Partner Interconnect auf der GCP zur Verbindung mit einem Partner, der eine Direktverbindung mit dem anderen CSP herstellen kann
- Verwenden von Dedicated Interconnect auf der GCP zum Übertragen von Daten an den anderen CSP über einen gemeinsamen POP (Point of Presence)
- Cross-Cloud Interconnect in Google Cloud für eine verwaltete Verbindung zu einem anderen CSP verwenden.
Diese Optionen unterscheiden sich in Bezug auf Übertragungsgeschwindigkeit, Latenz, Zuverlässigkeit, Service Level Agreements (SLAs), Komplexität und Kosten. Im Folgenden finden Sie eine detaillierte Beschreibung aller Optionen samt deren Vor- und Nachteile sowie einen abschließenden Vergleich.
In diesem Dokument werden Datenübertragungen zwischen virtuellen Maschinen in Google Cloud und den virtuellen Netzwerken anderer CSPs behandelt. Informationen zu Daten, die in anderen Google Cloud-Produkten, wie etwa Cloud Storage und BigQuery, gespeichert sind, finden Sie im Abschnitt zu diesen Produkten.
Verwenden Sie dieses Dokument als Leitfaden für die Bewertung der Optionen zur Datenübertragung zwischen Google Cloud und einem oder mehreren anderen CSPs entsprechend Ihren Anforderungen und Möglichkeiten.
Die beschriebenen Konzepte gelten in mehreren Fällen:
- Wenn Sie planen, kurzfristig große Datenmengen übertragen, z. B. für ein Datenmigrationsprojekt.
- Wenn Sie fortlaufende Datenübertragungen zwischen mehreren Cloud-Anbietern ausführen, z. B. weil Ihre Computing-Arbeitslasten von einem anderen CSP verarbeitet werden, während Ihre Big-Data-Arbeitslasten Google Cloud verwenden.
Erste Überlegungen
Bevor Sie sich für eine Verbindung Ihrer Cloud-Umgebungen entscheiden, müssen Sie sich überlegen, welche Regionen Sie in den einzelnen Umgebungen auswählen und wie Sie Daten übertragen, die nicht in virtuellen Netzwerkumgebungen gespeichert sind.
Cloudregionen auswählen
Wenn sowohl die Ressourcen von Google Cloud als auch von anderen CSPs in geografisch nah beieinander liegenden Regionen gehostet werden, ergeben sich für Datenübertragungen zwischen Cloud-Anbietern geringere Kosten und Latenzen.
Das folgende Diagramm veranschaulicht die Datenübertragung zwischen Google Cloud und anderen CSPs.
Unabhängig von der Übertragungsmethode fließen die Daten von Google Cloud zum anderen CSP so:
- Aus der Google Cloud-Region, in der Ressourcen für den Edge-POP von Google gehostet werden.
- Über eine Drittanbietereinrichtung zwischen der GCP und dem anderen CSP.
- Vom Edge-POP des anderen CSP bis zu der Region, in der sich die Ressourcen im Netzwerk des anderen CSP befinden.
Daten, die vom anderen CSP zu Google Cloud fließen, werden über denselben Pfad übertragen, jedoch in umgekehrter Richtung.
Der gesamte Pfad bestimmt die Latenz der Datenübertragung. Bei einigen Lösungen steigen die Netzwerkkosten auch, wenn sich die Edge-POPs beider Anbieter nicht in einer Metropolregion befinden. Details finden Sie im folgenden Abschnitt zu den Preisen für jede Lösung.
Wählen Sie in jeder Cloud geeignete Hostregionen für Ihre geplanten Arbeitslasten aus. Siehe hierzu die Seite Standorte für Google Cloud und ähnliche Seiten für andere CSPs, z. B. die AWS-Regionentabelle oder Azure-Produkte nach Region. Allgemeine Hilfe zur Auswahl eines oder mehrerer Standorte in Google Cloud finden Sie unter Best Practices für die Auswahl der Region in Compute Engine.
Daten aus Cloud Storage oder BigQuery übertragen
Nur Daten, die sich in einer Google Cloud-VPC-Umgebung befinden, werden standardmäßig über einen Cloud VPN-Tunnel oder eine Cloud Interconnect-Verbindung übertragen.
Wenn Sie Daten zu und von anderen Google-Diensten übertragen möchten, können Sie Private Service Connect und Privater Google-Zugriff für lokale Hosts aus der Umgebung des anderen CSP verwenden.
Wenn Sie den Objektspeicher, die Datenbank, das Data Warehouse oder andere Produkte eines anderen CSP übertragen möchten, sehen Sie in dessen Dokumentation nach, ob Daten über dessen Interconnect oder verwaltetes VPN übertragen werden können. Andernfalls können Sie diese Daten möglicherweise über Proxy-VMs übertragen, die Sie zu diesem Zweck in der jeweiligen CSP-Umgebung einrichten.
Zum Übertragen von Daten an Cloud Storage oder BigQuery können Sie auch den Storage Transfer Service oder den BigQuery Data Transfer Service verwenden.
Datenübertragung mit externen IP-Adressen über das Internet
Am einfachsten lassen sich Daten zwischen Google Cloud und einem anderen CSP per Internet über externe IP-Adressen übertragen.
Das folgende Diagramm zeigt die Bestandteile dieser Lösung.
Zwischen dem Edge-Netzwerk von Google und dem Edge-Netzwerk des anderen CSP werden Daten über das Internet oder per Direct Peering zwischen Google Cloud und dem anderen CSP übertragen. Daten können nur zwischen Ressourcen übertragen werden, denen öffentliche IP-Adressen zugewiesen sind.
Verbindung von Google zu anderen Netzwerken herstellen
Google ist über Edge-POPs mit anderen Netzwerken verbunden, die zusammen das Internet bilden. Google ist an zahlreichen Standorten weltweit präsent.
Im Internet wird jedem Netzwerk eine autonome Systemnummer (ASN) zugewiesen, die die interne Netzwerkinfrastruktur und die internen Netzwerkverbindungen umfasst. Die primäre ASN von Google ist 15169.
Es gibt zwei primäre Möglichkeiten, wie ein Netzwerk Traffic an Google senden oder von Google empfangen kann:
- Erwerb eines Internetdienstes von einem Internetanbieter, der bereits eine Verbindung zu Google (AS15169) hat. Diese Option wird im Allgemeinen als IP-Transit bezeichnet. Sie ist mit dem vergleichbar, was Nutzer und Unternehmen für die Dienste zu Hause und in Unternehmen von Zugriffsanbietern erwerben.
- Direkte Verbindung zu Google (AS15169). Mit dieser Option, Peering genannt, kann ein Netzwerk Traffic direkt an Google senden und von dort empfangen (AS15169), ohne ein Drittanbieternetzwerk zu verwenden. Im Allgemeinen wird das Peering gegenüber dem Transit bevorzugt, da Netzwerkbetreiber damit mehr Kontrolle darüber haben, wie und wo der Traffic ausgetauscht wird, und so Leistung und Kosten optimieren können. Peering ist ein freiwilliges System. Wenn Sie das Peering auswählen, entscheiden die Netzwerkbetreiber gemeinsam, zu welchen Einrichtungen eine Verbindung hergestellt wird, wie viel Bandbreite bereitgestellt wird, wie die Infrastrukturkosten aufgeteilt werden sowie über alle weitere Details, die zum Einrichten der Verbindungen erforderlich sind. AS15169 hat eine offene Peering-Richtlinie, d. h., Google führt ein Peering für ein Netzwerk aus, wenn es die technischen Anforderungen erfüllt.
Peering ist eine private, beidseitig vorteilhafte Vereinbarung zwischen zwei unabhängigen Netzwerken. Dabei zeigen Netzwerke in der Regel nicht öffentlich an, mit wem sie an bestimmten Standorten ein Peering herstellen, wie viel Bandbreite verfügbar ist usw. Aufgrund der Skalierungsmöglichkeiten und einer offenen Richtlinie kann Google aber per Peering direkt mit fast allen großen Internetanbietern und Cloud-Dienstanbietern an mehreren Standorten und Regionen verbunden werden. Das Google-Netzwerkteam arbeitet direkt mit den Pendants bei diesen Netzwerken zusammen, um eine für den Bedarf ausreichende Peering-Kapazität bereitzustellen.
Weitere Informationen zur Funktionsweise des Internet-Peerings finden Sie unter The Internet Peering Playbook.
Implementierung
Bei diesem Setup müssen alle virtuellen Maschinen, die Daten zwischen Google Cloud und anderen Cloud-Dienstanbietern übertragen, über eine öffentliche IP-Adresse verfügen. Die Firewall muss an einem Ende der Verbindung geöffnet sein, damit eine Verbindung von der öffentlichen IP-Adresse des anderen Cloudanbieters hergestellt werden kann. Es sind keine zusätzlichen Schritte erforderlich, da der Datenaustausch über die vorhandene Internetverbindung erfolgt.
Übertragungsgeschwindigkeit und Latenz
Zwar können für Internetverbindungen keine Garantien bezüglich Übertragungsgeschwindigkeit und Latenz gemacht werden, aber große CSPs und Google tauschen Daten in der Regel direkt an mehreren Standorten auf der ganzen Welt aus. Die Bandbreite wird mit anderen Kunden und Services geteilt. Aufgrund der direkten Verbindung zwischen beiden Anbietern ist die Latenz jedoch ähnlich oder geringer als bei anderen Optionen.
Testen Sie am besten die Latenz und Bandbreite zwischen Google Cloud und den anderen CSPs in den von Ihnen ausgewählten Regionen. Mit Tools wie iperf oder netperf können Sie schnelle Benchmarks durchführen. Alternativ führen Sie umfassendere benutzerdefinierte Benchmarks speziell für Ihre Anwendung aus. Auch wenn sich die Bedingungen im Laufe der Zeit ändern können, gibt ein Benchmark Aufschluss über die zu erwartende Leistung und ob diese Lösung Ihre Anforderungen erfüllt. Wenn Sie dedizierte Bandbreite zwischen beiden Umgebungen benötigen, sollten Sie eine andere Lösung wählen.
Die Produkte der verschiedenen Anbieter können unterschiedliche Leistungsmerkmale haben, die nicht immer kompatibel sind. Beispielsweise kann die IPsec-VPN-Kapazität pro Tunnel von Anbieter zu Anbieter variieren.
Sicherheit
Der Datenverkehr über das Internet ist nicht verschlüsselt und kann über Internetanbieter (ISPs), autonome Systeme und Einrichtungen von Drittanbietern übertragen werden. Daher sollten Sie vertraulichen Datenverkehr auf Anwendungsebene verschlüsseln oder eine andere Lösung auswählen.
Zuverlässigkeit und SLA
Google Cloud verfügt in der Regel über mehrere unterschiedliche Pfade für die Internetverbindung in verschiedenen Regionen und es bestehen Direct-Peering-Verbindungen zu anderen großen CSPs an mehreren Standorten weltweit.
Google Cloud bietet jedoch keine SLAs für die Anbindung an andere CSPs über das Internet. Zur Sicherheit sollten Sie die SLAs der anderen CSPs prüfen. Diese beziehen sich in der Regel aber nur auf die Internetverbindung im Allgemeinen und nicht auf bestimmte Anbieter.
Je nach Anbieter können unterschiedliche Routingrichtlinien gelten, die sich gegebenenfalls auf die Verfügbarkeit auswirken. Auf der Seite peeringdb zeigt Amazon zum Beispiel, dass viele AWS-Regionen nur lokale Routen anbieten, da AWS-VPCs nur regional sind (Google Cloud-VPCs sind global). Das bedeutet, dass Kunden möglicherweise Verbindungen an nur einem einzigen Peering-Standort nutzen, da der von der Google Cloud ausgehende Traffic nur mit diesen Verbindungen das Ziel erreichen kann. Wenn Traffic nur in einer Region ausgetauscht wird, ist dies im Normalfall kein Problem. Für Kunden ist es aber empfehlenswert, Bereitstellungen für mehrere Regionen zu erstellen, um regionale Ausfälle aufzufangen. Dies kann z. B. durch Einrichten zusätzlicher Gateways, HA VPNs, virtuelles Netzwerk-Peering oder anderer multiregionaler Topologien in der Drittanbieter-Cloud erreicht werden.
Anwendungen sollten außerdem so aufgebaut sein, dass sie Fehler ignorieren ("fail-open"), wie von Google SRE im SRE-Handbuch empfohlen. Wenn Sie beispielsweise eine Anwendung erstellen, für die ein Drittanbieterdienst über das Internet-Routing erreichbar sein muss, sollten Sie dafür sorgen, dass bei Verbindungsproblemen die Anwendung weiterhin funktioniert oder zumindest aussagekräftige Fehlermeldungen an den Nutzer ausgibt.
Wenn Probleme mit dem Internet-Routing auftreten, versucht das Google-Netzwerkteam, die Verbindung mit dem Drittanbieter wiederherzustellen. Es können jedoch nicht alle Probleme von Google behoben werden. In einigen Fällen kann die Reparatur daher von einem Drittanbieter (Internetdienstanbieter oder Cloud-Anbieter) abhängig sein, der entsprechende Maßnahmen ergreifen muss. Wie Netzwerkbetreiber auf Ausfälle reagieren, hängt weitgehend von den Kunden ab. Sorgen Sie also dafür, dass Sie bei allen Anbietern den nötigen Support haben und einen Plan zur Eskalation, wenn Probleme auftreten. Führen Sie auch regelmäßige BCP-Prozesse (Business Continuity) aus, um die Robustheit von Anwendungen in der Multi-Cloud zu gewährleisten.
Preise
Für von Google Cloud ausgehende Datenübertragungen über das Internet gelten die normalen Preise für ausgehenden Internettraffic. Ist Latenz kein kritischer Faktor, bietet die Standard-Netzwerkdienststufe ein niedrigeres Preissegment.
Die anderen CSPs erheben eigene Gebühren für die Datenübertragung. In vielen Fällen berechnen sie nur den ausgehenden Traffic ihres Netzwerks. Siehe hierzu die Preisliste Ihres CSP, z. B. die EC2-Datenübertragungsgebühren für AWS und die Preisübersicht für Bandbreite von Azure.
Verwaltetes VPN zwischen Cloudanbietern
Sie können verwaltete VPN-Dienste von beiden Cloud-Anbietern verwenden, was zwei Vorteile bietet. Hierdurch wird ein verschlüsselter Kanal zwischen virtuellen Netzwerken in beiden Cloud-Umgebungen bereitgestellt und die Übertragung von Daten über private IP-Adressen ermöglicht. Dies ist eine Erweiterung der vorherigen Lösung zur Übertragung über das Internet, ohne dass Hardware oder Partner erforderlich sind.
Das folgende Diagramm zeigt die Bestandteile dieser Lösung.
Bei dieser Lösung werden Daten in Google Cloud mit Cloud VPN und einer VPN-Lösung des anderen CSP verschlüsselt. Die Datenübertragung zwischen Google Cloud und dem anderen CSP erfolgt wie in der vorherigen Lösung über das Internet.
Implementierung
Google bietet Cloud VPN als verwalteten VPN-Dienst für verschlüsselte IPsec-Tunnel an, die auf Google-Seite verwendet werden können. Andere CSPs bieten ihre eigenen verwalteten VPN-Produkte an, mit denen Sie IPsec-VPN-Tunnel zwischen beiden Umgebungen erstellen können. AWS bietet beispielsweise AWS Site-to-Site-VPN und Azure bietet Azure VPN Gateway. Sie können Ihre virtuellen Netzwerke über VPN-Tunnel zwischen den Umgebungen verbinden.
IP-Adressen in den beiden Umgebungen dürfen sich nicht überschneiden, da in Cloud VPN keine NAT-Funktion (Network Address Translation) verfügbar ist. Auf dem Cloud Router können sich überschneidende Routen vom Austausch zwischen Umgebungen ausgeschlossen werden. In diesem Fall ist jedoch keine Kommunikation zwischen Diensten über die betreffenden IP-Adressen mehr möglich.
Befindet sich Cloud Router im Modus für globales dynamisches Routing, lassen sich alle Regionen in einem globalen VPC-Netzwerk erreichen. Dazu werden nur VPN-Tunnel zu dieser Region benötigt. Für andere CSPs benötigen Sie möglicherweise VPN-Tunnel pro Region. Befinden sich in einer Cloud-Umgebung mehrere virtuelle Netzwerke ohne Peering, müssen alle virtuellen Netzwerke, die unabhängig miteinander kommunizieren sollen, per VPN verbunden werden.
Google Cloud bietet Interoperabilitätsleitfäden mit Schritt-für-Schritt-Anleitungen zum Einrichten von VPN-Tunneln für andere große Cloud-Anbieter:
- Alibaba Cloud VPN Gateway ohne Redundanz: nur statisches Routing
- Alibaba Cloud VPN-Gateway mit Redundanz: nur statisches Routing
- AWS unterstützt dynamisches Routing per Cloud Router.
- Microsoft Azure: unterstützt dynamisches Routing per Cloud Router.
Übertragungsgeschwindigkeit und Latenz
Bei verwalteten VPN-Tunneln folgen die Daten weiterhin demselben Internetpfad, so als würden sie direkt über öffentliche IP-Adressen ausgetauscht. Die Latenz liegt durch den VPN-Tunnel nur geringfügig höher als bei der vorherigen Lösung. Die verfügbare Bandbreite wird durch die maximale Bandbreite pro VPN-Tunnel in Google Cloud, die maximale Bandbreite der Tunnel des anderen CSP und die verfügbare Bandbreite über den Internetpfad begrenzt.
Für eine höhere Bandbreite können Sie mehrere Tunnel parallel bereitstellen. Weitere Informationen zum Bereitstellen einer solchen Lösung finden Sie unter VPNs mit hohem Durchsatz erstellen.
Sie können die Latenz und Bandbreite wie im letzten Abschnitt beschrieben testen. Die Bedingungen können sich jedoch im Laufe der Zeit ändern und es gibt keine Garantie für die Latenz oder Bandbreite.
Sicherheit
Der Traffic über IPSec-VPN-Tunnel wird mithilfe von Chiffren verschlüsselt, die von beiden CSPs akzeptiert werden. Weitere Informationen finden Sie unter Von Cloud VPN unterstützte IKE-Chiffren, AWS FPN FAQ und IPsec-/IKE-Parameter in Azure VPN.
Zuverlässigkeit und SLA
Cloud VPN bietet eine SLA von 99,9 % bis 99,99 %, abhängig davon, ob Classic VPN oder HA VPN ausgewählt ist. Andere CSPs bieten manchmal SLAs für verwaltete VPN-Produkte an, z. B. das SLA von AWS Site-to-Site VPN und das SLA von Azure für VPN-Gateway. Diese SLAs decken jedoch nur die Verfügbarkeit von VPN-Gateways ab und umfassen nicht die Verbindung zu anderen CSPs über das Internet. Daher gibt es kein übergreifendes SLA für die gesamte Lösung.
Zum Erhöhen der Zuverlässigkeit sollten Sie mehrere VPN-Gateways und -Tunnel sowohl auf Google Cloud als auch für die anderen CSPs verwenden.
Preise
Für den verwalteten VPN-Service fallen Gebühren an. Für Google Cloud wird eine stündliche Gebühr erhoben, siehe Cloud VPN-Preise. Informationen zu anderen CSPs finden Sie in deren Preislisten, z. B. für AWS unter Preise für AWS Site-to-Site VPN oder für Azure unter VPN Gateway – Preise.
Zusätzlich zum stündlichen Preis für den VPN-Service fallen Gebühren für über die VPN-Gateways übertragenen Daten an. Für Google Cloud und viele CSPs fallen die Standardgebühren für die Internetdatenübertragung an, wie unter Datenübertragung mit externen IP-Adressen über das Internet beschrieben. In vielen Fällen übersteigen die Datenübertragungsgebühren die Fixkosten für diese Lösung.
Partner Interconnect mit Multi-Cloud-fähigen Partnern
Mit Partner Interconnect können Sie eine Virtual Private Cloud über das Netzwerk ausgewählter Partner, die direkte Multi-Cloud-Lösungen anbieten, mit den virtuellen Netzwerken eines anderen CSP verbinden. Sie stellen eine Verbindung her, indem Sie eine oder mehrere virtuelle Routinginstanzen bereitstellen, die für das Einrichten des erforderlichen Border Gateway Protocol (BGP) sorgen.
Das folgende Diagramm zeigt einen redundanten Aufbau mit zwei Partner Interconnect-Verbindungen.
Routen werden zwischen Cloud Router und dem Gateway des anderen CSP über eine virtuelle Routinginstanz ausgetauscht, die von dem Partner verwaltet wird, der die Verbindung bereitstellt. Der Traffic fließt durch das Partnernetzwerk zwischen Google Cloud und dem anderen CSP.
Implementierung
Für diese Lösung müssen mehrere Komponenten eingerichtet werden:
- Richten Sie Partner Interconnect in Google Cloud mit einem Interconnect-Dienstanbieter ein, der Ihre Google Cloud-Regionen bedient und dem anderen CSP Multi-Cloud-Konnektivität bietet.
- Für den anderen CSP müssen Sie dessen Interconnect-Produkt verwenden, um eine Verbindung zum gleichen Partner herzustellen. In AWS können Sie beispielsweise Direct Connect verwenden, in Azure hingegen ExpressRoute.
- Auf der Seite des Dienstanbieters müssen Sie die virtuellen Routinggeräte konfigurieren, die die BGP-Sitzungen für Google Cloud und den anderen CSP bereitstellen.
Wenn sich der IP-Adressbereich zwischen beiden CSP-Umgebungen überschneidet, bietet Ihr Partner eventuell NAT-Funktionen für die virtuelle Routing-Geräte an. Weitere Informationen finden Sie in der Partnerdokumentation.
Übertragungsgeschwindigkeit und Latenz
Diese Lösung bietet eine dedizierte Kapazität zwischen Google Cloud und anderen CSPs. Abhängig vom Partner und dem anderen CSP kann die verfügbare Anhangskapazität variieren. Auf Google Cloud ist Partner Interconnect mit einer Verbindungskapazität zwischen 50 Mbit/s und 50 Gbit/s verfügbar.
Die Latenz dieser Lösung summiert sich aus folgenden Werten:
- Latenz zwischen der Hostregion Ihrer Ressourcen auf Google Cloud und dem Interconnect-Standort, über den der Partner eine Verbindung zu Google Cloud herstellt.
- Latenz im Partnernetzwerk zur, von der und durch die virtuelle Routinginstanz zum anderen CSP.
- Latenz vom Edge-Standort des anderen CSP, an dem die Verbindung mit dem Partner stattfindet, zu der Region des CSP, in der die Ressourcen gehostet werden.
Für eine möglichst geringe Latenz sollten sich die Edge-Standorte von Google Cloud und des anderen CSP zusammen mit der virtuellen Routinginstanz in derselben Metropolregion befinden. Beispielsweise kann geringere Latenz erzielt werden, wenn sich sowohl die Cloudregionen des CSP als auch der Edge-POP und die virtuelle Routinginstanz im Gebiet von Ashburn, Virginia, befinden.
Während Google Cloud und viele andere CSPs keine Latenzgarantien für den Traffic zu ihrem Edge-Netzwerk bieten, da der Partner über einen dedizierten Pfad und eine dedizierte Kapazität verfügt, ist die Latenz bei dieser Lösung normalerweise weniger variabel als bei Verwendung von externen IP-Adressen oder einer VPN-Lösung.
Sicherheit
Traffic über Partner Interconnect ist standardmäßig nicht verschlüsselt. Zum Schutz Ihres Traffics können Sie HA VPN über Cloud Interconnect auf der Google Cloud-Seite der Verbindung bereitstellen. Die verwalteten VPN-Dienste einiger anderer CSPs können über Interconnect-Verbindungen verwendet werden, z. B. AWS Site-to-Site-VPN über AWS Direct Interconnect. Alternativ können Sie eine virtuelle Appliance verwenden, die den Traffic seitens des anderen CSP verschlüsselt.
Eine weitere Option ist die Verschlüsselung Ihres Traffics auf Anwendungsebene, anstatt ein VPN zu verwenden.
Zuverlässigkeit und SLA
Diese Lösung umfasst drei verschiedene SLAs: eine von Google, eine vom Interconnect-Partner und eine vom anderen CSP.
Bei redundanter Verwendung von Partner Interconnect bietet Google je nach gewählter Topologie monatliche SLAs von 99,9 % bis 99,99 % an. Es gibt keine SLA für eine einzelne Partner Interconnect-Verbindung.
Das SLA für das Interconnect-Produkt des anderen CSP finden Sie in der entsprechenden Dokumentation, z. B. in SLA von AWS Direct Connect oder SLA von Azure ExpressRoute.
Das SLA zur Verfügbarkeit der Verbindung und virtuellen Routinginstanz finden Sie in der Dokumentation oder den Bedingungen des Partner-Dienstanbieters für die Partner Interconnect-Verbindung. Siehe zum Beispiel die weltweite Leistungsvereinbarung von Megaport.
Preise
Auf Google Cloud-Seite fällt eine Monatsgebühr für jeden Partner Interconnect-Anhang an, je nach Bandbreite. Über den Partner Interconnect ausgehender Traffic wird zu einem niedrigeren Preis als der Internet-Traffic abgerechnet. Weitere Informationen finden Sie auf der Partner Interconnect-Preisseite.
Informationen zu den Interconnect-Produkten der anderen CSPs finden Sie auf deren Preisseiten, z. B. AWS Direct Connect – Preise oder Azure ExpressRoute – Preise. In der Regel fallen Monatsgebühren für den Interconnect und Gebühren für die Datenübertragung über den Interconnect an, die mit einem günstigeren Tarif abgerechnet werden als Internet-Traffic.
Der Partner rechnet Interconnect-Servicegebühren gemäß seinen eigenen Preisen ab, die auf seiner Website oder beim zuständigen Vertriebsteam angefragt werden können. Für Datebübertragungen in der gleichen Metropolregion fallen in der Regel deutlich geringere Gebühren an, als für Übertragungen über lange Strecken in einem Partnernetzwerk.
Wenn regelmäßig ausreichend große Datenmengen übertragen werden, kann diese Lösung, abhängig von den Preisen des anderen CSP, aufgrund der reduzierten Tarife für ausgehenden Traffic die günstigste Lösung darstellen. Selbst unter Berücksichtigung der monatlichen Kosten für den Interconnect für Partner Interconnect, den anderen CSP und den Dienstanbieterpartner sind mit dieser Lösung erhebliche Einsparungen möglich. Da sich die Preise von Partnern und anderen CSPs ohne vorherige Ankündigung ändern können, sollten Sie immer die aktuellen Angebote aller beteiligten Parteien vergleichen.
Dedicated Interconnect über einen gemeinsamen POP
Wenn Sie ein oder mehrere physische Routinggeräte an einem gemeinsamen Interconnect zwischen Google Cloud und dem anderen CSP verwenden, können Sie beide Cloud-Anbieter mithilfe von Dedicated Interconnect auf der Seite von Google Cloud und einem entsprechenden Produkt seitens des CSP verbinden. Der Interconnect-Standort muss nicht unbedingt derselbe Standort sein wie die Hostregion Ihrer Ressourcen.
Das folgende Diagramm zeigt einen redundanten Aufbau mit zwei Dedicated Interconnect-Verbindungen:
Routen werden zwischen dem Cloud Router und dem Gateway des anderen CSP über einen physischen Router ausgetauscht, der sich an einem gemeinsamen Interconnect-Standort befindet. Traffic zwischen Google Cloud und dem anderen CSP wird über diesen Router abgewickelt.
Implementierung
Bei dieser Lösung müssen physische Routinggeräte in einer Colocations-Einrichtung gehostet und betrieben werden, die von Google und dem betreffenden CSP genutzt werden. Von diesem Routinggerät aus geben Sie zwei physische Verbindungen bei der Einrichtung in Auftrag: eine über Dedicated Interconnect zu Google Cloud und eine über ein gleichwertiges Produkt, beispielsweise AWS Direct Connect oder Azure ExpressRoute, zum anderen Dienstanbieter. Auf Ihrem Routinggerät müssen Sie BGP so konfigurieren, dass der Routenaustausch zwischen den beiden Cloudumgebungen möglich ist.
Geeignete Standorte für diese Lösung finden Sie anhand der Standortliste für Colocations-Einrichtungen von Google Cloud und der Liste Ihres anderen CSP, z. B. unter AWS Direct Connect-Standorte oder Azure ExpressRoute-Peeringstandorte.
Die IP-Adressbereiche zwischen Ihren virtuellen Netzwerken sollten sich nicht überschneiden, es sei denn, das physische Routinggerät unterstützt NAT zwischen den Umgebungen oder Sie beschränken den Routenaustausch zwischen den Umgebungen.
Diese Lösung eignet sich, wenn Sie die dedizierte Verbindung verwenden, um zusätzlich zur Verbindung mit einem anderen CSP auch eine Verbindung zu Ihrer lokalen Umgebung herzustellen.
In anderen Fällen erweist sich diese Lösung als kompliziert, da physische Geräte betrieben und ein Vertrag mit der Colocations-Einrichtung erstellt werden muss. Wir empfehlen diese Lösung nur, wenn mindestens eine der folgenden Bedingungen erfüllt ist:
- Sie verfügen bereits über ein Gerät in einer geeigneten Einrichtung und einen bestehenden Vertrag mit der Einrichtung.
- Sie übertragen regelmäßig große Datenmengen, sodass dies eine kostengünstige Option ist, oder Ihr Bandbreitenbedarf kann von Partnern nicht gedeckt werden.
Übertragungsgeschwindigkeit und Latenz
Diese Lösung bietet eine Verbindung mit dedizierter Bandbreite zwischen Google Cloud und einem anderen CSP. Aufseiten von Google Cloud ist Dedicated Interconnect über eine oder mehrere Leitungsverbindungen mit 10 oder 100 Gbit/s verfügbar.
Die Latenz dieser Lösung summiert sich aus folgenden Werten:
- Latenz zwischen der Region, in der Ihre Ressourcen in Google Cloud gehostet werden, und dem Interconnect-Standort, an dem Sie eine Interconnect-Verbindung zu Google Cloud herstellen
- Latenz durch die Einrichtung und Ihre physischen Geräte, die im Vergleich zu einer Latenz aufgrund der Faserlänge in der Regel vernachlässigbar ist.
- Latenz vom Interconnect-Standort über das Netzwerk des anderen CSP zur Region, in der die Ressourcen beim anderen CSP gehostet werden.
Zwar werden keinerlei Latenzgarantien gegeben, aber diese Lösung bietet in der Regel die niedrigste Latenz und die höchste Übertragungsgeschwindigkeit zwischen Google Cloud und anderen Cloud-Umgebungen über private IP-Adressen.
Sicherheit
Der Traffic über Dedicated Interconnect wird standardmäßig nicht verschlüsselt. Zum Schutz Ihres Traffics können Sie HA VPN über Cloud Interconnect auf der Google Cloud-Seite der Verbindung bereitstellen. Die verwalteten VPN-Dienste einiger anderer CSPs können über Interconnect-Verbindungen verwendet werden, z. B. AWS Site-to-Site-VPN über AWS Direct Interconnect. Alternativ kann Traffic seitens des anderen CSP ebenfalls auch über eine virtuelle Appliance verschlüsselt werden.
Eine weitere Option ist die Verschlüsselung Ihres Traffics auf Anwendungsebene, anstatt ein VPN zu verwenden.
Zuverlässigkeit und SLA
Bei redundanter Verwendung von Dedicated Interconnect bietet Google je nach gewählter Topologie monatliche SLAs von 99,9 % bis 99,99 % an. Es gibt keine SLA für eine einzelne Dedicated Interconnect-Verbindung.
Das SLA für das Interconnect-Angebot des anderen CSP finden Sie in der entsprechenden Dokumentation, z. B. in SLA von AWS Direct Connect oder SLA von Azure ExpressRoute.
Die Colocations-Einrichtung oder der Hardwareanbieter der physischen Routing-Geräte bieten möglicherweise auch SLAs für ihre Services an.
Preise
Auf der Google Cloud-Seite fällt eine Monatsgebühr für jeden Dedicated Interconnect-Port sowie für jeden VLAN-Anhang an, der mit einer VPC-Umgebung verbunden wird. Über Dedicated Interconnect ausgehender Traffic wird zu einem günstigeren Tarif abgerechnet als Internet-Traffic. Weitere Informationen finden Sie auf der Preisseite für Dedicated Interconnect.
Informationen zu den Interconnect-Produkten der anderen CSPs finden Sie auf deren Preisseiten, z. B. AWS Direct Connect – Preise oder Azure ExpressRoute – Preise. In der Regel fallen Monatsgebühren für den Interconnect und Gebühren für die Datenübertragung über den Interconnect an, die mit einem günstigeren Tarif abgerechnet werden als Internet-Traffic.
Zusätzlich sind die Gebühren der Colocations-Einrichtung für Leistungen wie Räumlichkeiten, Strom und physische Verbindungen zu beiden Cloudumgebungen sowie alle Kosten und laufenden Serviceverträge mit dem Anbieter der physischen Routing-Geräte zu berücksichtigen. Wenn die Verbindung zwischen beiden CSPs nicht in derselben Einrichtung hergestellt werden kann und Sie eine Verbindung zwischen zwei Einrichtungen herstellen müssen, liegen die Kosten für diese Services möglicherweise deutlich höher.
Von Cross-Cloud Interconnect verwaltete Verbindungen
Sie können Ihre Google Cloud-VPC-Netzwerke über die Netzwerkstruktur von Google mit Ihren virtuellen Netzwerken in einem anderen CSP verbinden. In diesem Sinne funktioniert diese Einrichtung wie Partner Interconnect, wobei jedoch das Google-SLA sowohl die Google-Netzwerke als auch die Interconnect-Verbindungen selbst abdeckt.
Das folgende Diagramm zeigt eine Cross-Cloud Interconnect-Konfiguration mit der Mindestanzahl von Verbindungen.
Routen werden zwischen dem Cloud Router und dem Gateway des anderen CSP über die Netzwerkstruktur von Google ausgetauscht. Traffic zwischen Google Cloud und dem anderen CSP wird über diese Struktur abgewickelt.
Implementierung
Wenn Sie Cross-Cloud Interconnect erwerben, stellt Google eine dedizierte physische Verbindung zwischen dem Google-Netzwerk und dem eines anderen Cloud-Dienstanbieters bereit. Sie können diese Verbindung für das Peering Ihres Google Cloud-VPC-Netzwerks (Virtual Private Cloud) mit einem Netzwerk verwenden, das von einem unterstützten Cloud-Dienstanbieter gehostet wird.
Nachdem Sie die Verbindung bereitgestellt haben, unterstützt Google die Verbindung bis zu dem Punkt, an dem sie das Netzwerk des anderen Cloud-Dienstanbieters erreicht. Google sichert keine Betriebszeit von anderen Cloud-Dienstanbietern zu. Google bleibt jedoch der primäre Ansprechpartner für den gesamten Dienst und benachrichtigt Sie, wenn Sie eine Supportanfrage beim anderen CSP eröffnen müssen.
Bei dieser Lösung müssen Sie die Einrichtungsschritte für den anderen CSP ausführen und dabei auswählen, wo die beiden Netzwerke miteinander verbunden werden. Es werden nur bestimmte Cloud-Speicheranbieter unterstützt.
Übertragungsgeschwindigkeit und Latenz
Diese Lösung bietet eine Verbindung mit dedizierter Bandbreite zwischen Google Cloud und einem anderen CSP. Auf der Google Cloud-Seite ist Dedicated Interconnect über ein oder mehrere Paare von physischen Verbindungen mit 10 Gbit/s oder 100 Gbit/s verfügbar.
Die Latenz dieser Lösung summiert sich aus folgenden Werten:
- Latenz zwischen der Region, in der Ihre Ressourcen in Google Cloud gehostet werden, und dem cloudübergreifenden Standort.
- Latenz zwischen dem Edge-Standort von Google und dem Edge-Standort des anderen CSP (häufig in derselben Einrichtung)
- Latenz vom Edge-Standort des anderen CSP, an dem die Cross-Cloud Interconnect-Verbindung in der Region bereitgestellt wird, in der die Ressourcen beim anderen CSP gehostet werden.
Zwar werden keinerlei Latenzgarantien gegeben, aber diese Lösung bietet in der Regel die niedrigste Latenz und die höchste Übertragungsgeschwindigkeit zwischen Google Cloud und anderen Cloud-Umgebungen über private IP-Adressen.
Sicherheit
Da der Traffic über Cross-Cloud Interconnect nicht verschlüsselt ist, empfehlen wir die Verschlüsselung von vertraulichem Traffic auf Anwendungsebene.
Wenn der gesamte Traffic verschlüsselt werden muss, können virtuelle Appliances, die über Google Cloud-Partner im Cloud Marketplace verfügbar sind, Lösungen zum Verschlüsseln des Traffics in die Umgebung des anderen CSP bereitstellen.
Zuverlässigkeit und SLA
Cross-Cloud Interconnect verwendet das SLA. Damit das SLA erfüllt werden kann, muss Ihre Cross-Cloud Interconnect-Konfiguration ein oder mehrere Verbindungspaare verwenden, wie im Abschnitt Service Level Agreement der Cross-Cloud Interconnect-Übersicht beschrieben.
Das SLA deckt alles auf der Google-Seite bis zum Rand des Netzwerks des anderen Cloud-Anbieters ab. Sie gilt nicht für das Netzwerk des anderen Cloud-Serviceanbieters. Das SLA für das Interconnect-Angebot des anderen CSP finden Sie in der entsprechenden Dokumentation, z. B. unter SLA von AWS Direct Connect oder Azure-SLA für Azure ExpressRoute.
Preise
Für jede Cross-Cloud Interconnect-Verbindung und für jeden VLAN-Anhang, der eine Verbindung zu einer VPC-Umgebung herstellt, fällt eine stündliche Gebühr an. Über Cross-Cloud Interconnect ausgehender Traffic wird zu einem niedrigeren Preis als der Internet-Traffic abgerechnet. Weitere Informationen finden Sie unter Cross-Cloud Interconnect-Preise.
Informationen zu den Interconnect-Produkten der anderen CSPs finden Sie auf deren Preisseiten, z. B. AWS Direct Connect – Preise oder Azure ExpressRoute – Preise. Für die Interconnect-Verbindung fällt in der Regel eine monatliche Gebühr an. Die Gebühren für die Datenübertragung über die Interconnect-Verbindung sind in der Regel niedriger als die Gebühren für die Datenübertragung über das Internet.
Für Interconnect-Standorte und -Geräte fallen keine separaten Kosten an.
Vergleich der Optionen
Die hier dargestellten Optionen variieren in Bezug auf Geschwindigkeit, Verfügbarkeit, Komplexität, Sicherheit und Kosten. Vergleichen Sie die Optionen gründlich anhand Ihrer Anforderungen.
Das folgende Flussdiagramm bietet eine einfache Entscheidungshilfe für die Auswahl einer der Lösungen in diesem Dokument.
In der Regel sind folgende Lösungen empfehlenswert:
- Wenn Daten gelegentlich oder in geringen Mengen ausgetauscht werden und die Übertragungen nicht kritisch ist, stellt die Datenübertragung über das Internet oftmals die einfachste Option dar und bietet dennoch eine relativ geringe Latenz und hohe Bandbreite.
- Wenn eine Verschlüsselung oder Übertragung von kleineren Datenmengen über private IP-Adressen erforderlich ist, empfiehlt sich die Verwendung von Cloud VPN und eines verwalteten VPN-Dienstes des anderen CSP.
- Beim Übertragen großer Datenmengen bietet die Verwendung von Partner Interconnect mit einem Multi-Cloud-fähigen Partner mehrere Vorteile: dedizierte Kapazität, geringere Kosten für die Datenübertragung und je nach Topologie ein SLA für jeden Bestandteil der Lösung. Die Partner Interconnect-Kapazität liegt normalerweise unter 10 Gbit/s pro Verbindung.
- Wenn Sie Ihre lokalen Geräte mit mehreren Clouds verbinden, empfiehlt es sich häufig, Dedicated Interconnect über einen gemeinsamen POP zu verwenden. Jedoch fällt ein Mehraufwand für die Verwaltung Ihrer eigenen Hardware und Verträge mit einer Colocations-Einrichtung an. Sofern Sie nicht bereits über die nötige Infrastruktur verfügen, eignet sich diese Lösung nur, wenn Daten regelmäßig mit mindestens 10 Gbit/s übertragen werden.
- Wenn Sie den Aufwand für die Verwaltung von Cross-Connect-Verbindungen und Routingsystemen in Remote-POPs vermeiden möchten, bietet Cross-Cloud Interconnect eine verwaltete Lösung, bei der Google das alles für Sie übernimmt.
Nächste Schritte
- Reihe zu Hybrid- und Multi-Cloud-Mustern und -Praktiken
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center