Im Vergleich: Private Konnektivität mit AWS, Azure und Google Cloud

Wir klären auf, worin sich die Private-Connectivity-Angebote der führenden Hyperscaler unterscheiden.

Multicloud-Strategien sind auf dem Vormarsch. Deshalb lohnt es sich für Unternehmen, einmal genauer unter die Lupe zu nehmen, was die führenden Hyperscaler in Sachen private Konnektivität zu bieten haben. Die Vorteile privater Datenverbindungen sind zahlreich: Sie können mit einem höheren Datendurchsatz einhergehen, zur Senkung der Netzwerkkosten beitragen und eine stabilere Benutzererfahrung als das öffentliche Internet aufweisen. Unabhängig davon, ob Sie eine private Verbindung zu einem neuen Cloud Service Provider (CSP) einrichten möchten oder Ihre alte Internet-VPN ausgedient hat – dieser Artikel vermittelt Ihnen ein grundlegendes Verständnis der verschiedenen Konnektivitätsmodelle, wichtigsten Begriffe und zentralen Komponenten von Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform (GCP).

Die genannten Cloudanbieter nutzen teils ähnliche Terminologie, definieren diese jedoch unterschiedlich. Werfen wir zunächst einen Blick auf die Google Cloud Platform.

Nach diesem Einblick in zentrale CSP-Terminologie widmen wir uns als Nächstes AWS Direct Connect.

AWS Direct Connect

Die wichtigsten Bestandteile von AWS Direct Connect sind virtuelle Schnittstellen (VIFs), Gateways – Virtual Private Gateway (VGW), Direct Connect Gateway (DGW/DXGW), Transit Gateway (TGW) – und physische bzw. Direct Connect-Verbindungen.

AWS Direct Connect umfasst verschiedene Konnektivitätsoptionen: dedizierte Verbindungen, gehostete Verbindungen und gehostete VIFs. Bevor Sie sich für eine dieser Lösungen entscheiden, sollten Sie sich genau mit den einzelnen Modellen vertraut machen, um herauszufinden, inwieweit diese für Ihren konkreten Anwendungsfall geeignet sind.

Dedizierte Verbindung: Eine physische Verbindung, die über die AWS-Konsole angefordert wird und einem Einzelkunden vorbehalten ist. Sie erhalten hierfür einen „Letter of Authorization and Connecting Facility Assignment“ (LOA-CFA), mit dem Ihr Rechenzentrumsbetreiber oder AWS-Partner dann eine Querverbindung zwischen Ihrer Infrastruktur und AWS herstellen kann. Die verfügbaren Portgeschwindigkeiten betragen 1 Gbit/s und 10 Gbit/s.

Gehostete Verbindung: Eine physische Verbindung, die ein AWS Direct Connect Partner im Auftrag eines Kunden bereitstellt. Kunden müssen ihren AWS-Partner kontaktieren, um die Einrichtung der Verbindung in die Wege zu leiten. Die verfügbaren Geschwindigkeiten sind 50 Mbit/s, 100 Mbit/s, 200 Mbit/s, 300 Mbit/s, 400 Mbit/s, 500 Mbit/s, 1 Gbit/s, 2 Gbit/s, 5 Gbit/s und 10 Gbit/s.

Gehostete VIF: Virtuelle Schnittstellen, die einem Kunden durch den Eigentümer einer physischen Direct Connect-Verbindung bereitgestellt werden können. Die Bandbreite dieser Ausgangsverbindung wird von allen VIFs in Anspruch genommen.

Im Gegensatz zu anderen CSPs verfügt AWS über verschiedene Gateway-Typen, die in Verbindung mit Direct Connect zum Einsatz kommen können: Virtual Private Gateways, Direct Connect Gateways und Transit Gateways.

Virtual Private Gateway (VGW): Dies ist eine logische, vollständig redundante, dezentrale Edge-Routing-Funktion, die an eine VPC angebunden ist, um ein privates Routing des Datenverkehrs in die und aus der VPC heraus zu ermöglichen.

Direct Connect Gateway (DGW): Ein Direct Connect Gateway ist eine global verfügbare Ressource, die zum Anhängen mehrerer VPCs an eine einzelne Direct Connect-Verbindung (oder mehrere) verwendet werden kann. Dieses Gateway bietet jedoch keine Konnektivität zwischen VPCs.

Transit Gateway (TGW): Ein Transit Gateway verbindet sowohl Ihre VCPs als auch Ihre lokalen Netzwerke über ein zentrales Hub miteinander. Dies vereinfacht Ihr Netzwerk und setzt komplexen Peering-Beziehungen ein Ende.

Die Art des von Ihnen genutzten Gateways sowie die Beschaffenheit der öffentlichen oder privaten Infrastruktur, die Sie letztendlich anvisieren, bestimmen, welche Art von VIF verwendet werden sollte.

Werfen wir einen genaueren Blick auf die drei unterschiedlichen VIF-Typen: privat, öffentlich und Transit.

Private VIF – eine private virtuelle Schnittstelle: Mit einer privaten VIF können Sie über private IP-Adressen auf eine Amazon-VPC zugreifen. Sie können AWS bis zu 100 Präfixe ankündigen.

Hinweis: Die private VIF kann an ein Virtual Private Gateway (VGW) oder Direct Connect Gateway (DGW) angebunden werden.

Public VIF – eine öffentliche virtuelle Schnittstelle: Eine öffentliche virtuelle Schnittstelle kann auf alle öffentlichen AWS-Dienste über öffentliche IP-Adressen (S3, DynamoDB) zugreifen. Sie können AWS bis zu 1.000 Präfixe ankündigen.

Hinweis: Öffentliche VIFs sind keinem Gateway zugeordnet oder an dieses angebunden.

• Verbinden Sie sich global mit allen öffentlichen AWS-IP-Adressen (öffentliche IP für BGP-Peering erforderlich).
• Greifen Sie auf öffentlich routbare Amazon-Dienste in jeder beliebigen AWS-Region (außer AWS China) zu.

Transit VIF – eine virtuelle Transitschnittstelle: Mit einer virtuellen Transitschnittstelle lässt sich über ein Transit Gateway, das einem Direct Connect-Gateway zugewiesen ist, auf eine oder mehrere Amazon-VPCs zugreifen. Sie können virtuelle Transitschnittstellen mit AWS-Direct Connect-Verbindungen mit 1/2/5/10 Gbit/s verwenden und AWS bis zu 100 Präfixe ankündigen.

Azure ExpressRoute

Egal, ob Sie ExpressRoute Direct oder das Partnermodell verwenden – die Hauptkomponenten bleiben identisch: die Peerings (privat oder Microsoft), VNet-Gateways und die physische ExpressRoute-Verbindung***.*** Anders als bei anderen CPSs ist Azure ExpressRoute mit zwei Verbindungen für HA-/Redundanz- und SLA-Zwecke ausgestattet.

Ähnlich den dedizierten und gehosteten AWS-Modellen bietet Azure eigene Angebote für ExpressRoute Direct und Partner ExpressRoute.

Bei ** ** Azure ExpressRoute Direct ist der Kunde Eigentümer des ExpressRoute-Ports, und das LOA-CFA wird von Azure bereitgestellt. Die Glasfaser-Querverbindungen werden vom Kunden in dessen Rechenzentrum beschafft. Die unterstützten Port-Geschwindigkeiten sind 10-Gbit/s- oder 100-Gbit/s-Schnittstellen.

Beim ** ** ExpressRoute Partner-Modell wird der Service Provider mit dem ExpressRoute-Port verbunden. Das LOA-CFA wird von Azure bereitgestellt und dem Service Provider oder Partner übergeben. Die Glasfaser-Querverbindungen werden vom Partner bereitgestellt. Der Kunde arbeitet mit dem Partner gemeinsam an der Bereitstellung von ExpressRoute-Verbindungen, wobei die vom Partner bereits eingerichteten Verbindungen verwendet werden; der Service Provider ist Eigentümer der physischen Verbindungen zu Microsoft. Kunden können ExpressRoutes mit folgender Bandbreite erstellen: 50 Mbit/s, 100 Mbit/s, 200 Mbit/s, 500 Mbit/s, 1 Gbit/s, 2 Gbit/s, 5 Gbit/s, 10 Gbit/s**.**

Azure bietet außerdem ein einzigartiges Konnektivitätsmodell mit dem Namen Azure ExpressRoute Local. ExpressRoute Local ist so etwas wie ein Sonderfall im Vergleich zu den Konnektivitätsmodellen der anderen CSPs und ermöglicht Azure-Kunden die Anbindung an einen spezifischen Azure-Peer-Standort. Die Verbindung zu einer oder zwei lokalen Regionen, die dem Peer zugeordnet sind, bietet den zusätzlichen Vorteil unbegrenzter Datennutzung. Einen detaillierten Überblick über ExpressRoute Local finden Sie in einem früheren Blog-Artikel: So vermeiden Sie mit Azure ExpressRoute Local und Megaport böse Überraschungen bei der Abrechnung.

Azure bietet zwei Arten von Peering, die wir wie zwei Äpfel miteinander vergleichen können: mit privater VIF von AWS und mit öffentlicher VIF.

Privates Peering – Privates Peering unterstützt Verbindungen von einem lokalen/privaten Rechenzentrum des Kunden, um auf dessen Azure Virtual Networks (VNets) zuzugreifen.

• Zugriff auf Azure-IT-Dienste, vorrangig virtuelle Maschinen (IaaS) und Clouddienste (PaaS), die in einem virtuellen Netzwerk bereitgestellt werden.

• Verwendung von privaten IPs für den Peer (RFC-1918). Kunden benötigen /28 aufgeteilt auf zwei /30: einmal für den primären und einmal für den sekundären Peer.

• Privates Peering wird über logische Verbindungen unterstützt. BGP wird zwischen den lokalen Geräten des Kunden und Microsoft Enterprise Edge-Routern (MSEE) hergestellt.

Hinweis: Der Standort der MSEEs, mit denen Sie ein Peering einrichten, wird durch den Peering-Standort bestimmt, der bei der Bereitstellung von ExpressRoute ausgewählt wurde.

• Abhängig von der ausgewählten ExpressRoute SKU kann ein einzelner privater Peer mehr als 10 VNets über mehrere geografische Regionen hinweg unterstützen.

• Die maximale Zahl an Präfixen, die vom Peering unterstützt werden, beträgt standardmäßig 4.000; mit der Premium-SKU werden bis zu 10.000 unterstützt.

Microsoft Peering – Microsoft Peering wird verwendet, um öffentliche Azure-Ressourcen wie z. B. BLOB-Speicher anzubinden. Die Anbindung an Microsoft-Onlinedienste (Office 365 und Azure PaaS-Dienste) erfolgt über Microsoft-Peering.

• Office 365 ist auf eine sichere und zuverlässige Nutzung über das Internet ausgelegt. Um O-365-Routen über ExpressRoute zu erhalten, ist eine Genehmigung von Microsoft erforderlich.

• Bevor Kunden Routen über Microsoft-Peering empfangen, müssen Routenfilter erstellt werden. BGP-Communitys werden mit Routenfiltern verwendet, um Routen für Kundenservices zu empfangen.

Mit Azure ExpressRoute gibt es nur eine Art von Gateway: VNet Gateway.

VNet Gateway: Ein VNet-Gateway ist eine logische Routing-Funktion, die VGW von AWS ähnelt. ExpressRoute VNet Gateway wird genutzt, um Datenverkehr im Netzwerk auf eine private Verbindung zu leiten, indem der Gateway-Typ „ExpressRoute“ verwendet wird. Dieser wird auch als ExpressRoute-Gateway bezeichnet.

Mit einem Standard-Azure ExpressRoute können mehrere VNets nativ in einem Hub-and-Spoke-Modell an eine einzelne ExpressRoute-Verbindung angebunden werden, wodurch Ressourcen in mehreren VNets über eine einzelne Verbindung verfügbar werden. In diesem Sinne kann die Standard-Azure ExpressRoute-Produktfamilie mit dem AWS Direct Connect Gateway-Modell verglichen werden.

Google Cloud Interconnect

Das letzte, aber sicherlich nicht unbedeutendste private Konnektivitätsmodell eines CSP, das wir noch besprechen müssen, ist GCP Interconnect. Glücklicherweise verfolgt GCP für seine Konnektivität und Komponenten einen relativ schlanken Ansatz und bietet ohne Zweifel das einfachste Modell der drei.

Wie AWS und Azure hat GCP sowohl Partnerverbindungen als auch dedizierte Verbindungsmodelle im Angebot.

Dedicated Interconnect: GCP Dedicated Interconnect bietet eine direkte physische Verbindung zwischen Ihrem lokalen Netzwerk und dem Google-Netzwerk. Ähnlich wie bei den anderen CSPs übernehmen Sie das LOA-CFA von GCP und arbeiten mit Ihrem Colocation-Anbieter/Rechenzentrumsbetreiber zusammen, um die Querverbindung einzurichten.

• Eine dedizierte 10- oder 100-Gbit/s-Schnittstelle für die lokale Adressierung der kundenseitigen IPv4-Verbindung (Auswahl aus dem Bereich 169.254.0.0/16 für Peer-Adressen)
• LACP, selbst wenn Sie ein EBGP-4 für einzelne Leitungen mit Multi-Hop 802.1Q-VLANs verwenden

Partner Interconnect: Wie Dedicated Interconnect stellt auch Partner Interconnect über einen Provider oder Partner eine Verbindung zwischen Ihrem lokalen Netzwerk und Ihrem VPC-Netzwerk her. Eine Partner Interconnect-Verbindung ist ideal für Sie, wenn sich Ihr Rechenzentrum in einer von der Dedicated Interconnect-Colocation getrennten Einrichtung befindet oder wenn Ihr Datenaufkommen keine 10-Gbit/s-Verbindung erfordert.

Die einzige Gateway-Option für GCP Interconnect ist der Google Cloud Router.

Google Cloud Router: Ein Cloudrouter tauscht dynamisch Routen zwischen Ihrem VPC-Netzwerk und Ihrem lokalen Netzwerk über das Border Gateway Protocol (BGP) aus.

Ein GCP-Cloudrouter ist nicht nur auf eine einzelne VPC, sondern auch auf eine einzelne Region dieser VPC beschränkt. Dies kann als 1:1-Zuordnung oder -Beziehung angesehen werden. Dazu kommen die Peering-Einrichtungen, die GCP als VLAN-Anhänge bezeichnet.

VLAN-Anhänge: Ein VLAN-Anhang, auch bekannt als Interconnect-Anhang, ist eine logische Verbindung zwischen Ihrem lokalen Netzwerk und einer einzelnen Region in Ihrem VPC-Netzwerk. Anders als Azure und AWS bietet GCP nur eine private Peering-Option über seine Verbindung. Um die öffentlichen Dienste und APIs von GCP zu erreichen, können Sie einen privaten Google-Zugang über Ihre Verbindung einrichten, um Ihre lokalen Hosts aufzunehmen. Allerdings ermöglicht ein privater Google-Zugang keine G Suite-Konnektivität. Hierfür müssen Sie eine Verbindung / ein Peering dorthin über einen Internetknoten (IX) einrichten oder über das Internet auf diese Dienste zugreifen.

Fazit

Nachfolgend möchten wir die wichtigsten Erkenntnisse aus diesem Artikel noch einmal zusammenfassen. Wir hoffen, dass wir Ihnen einen besseren Einblick in die Optionen dieser CSPs für private Konnektivität vermitteln konnten.

AWS Direct Connect bietet mehrere Arten von Gateways und Konnektivitätsmodellen, die genutzt werden können, um öffentliche und private Ressourcen von Ihrer lokalen Infrastruktur aus zu erreichen. Ob dies in Form eines Transit Gateway, das einem Direct Connect-Gateway zugeordnet ist, oder einer 1:1-Zuordnung einer privaten VIF-Anbindung auf einem VGW erfolgt, hängt vom Einzelfall und Ihren Zukunftsplänen ab.

Mit Azure ExpressRoute können Sie sowohl ein Microsoft-Peering (für den Zugang zu öffentlichen Ressourcen) als auch ein privates Peering über die einzelne logische Layer-2-Verbindung konfigurieren. Jedes ExpressRoute verfügt über zwei konfigurierbare Verbindungen, die bei der Bestellung Ihres ExpressRoute inbegriffen sind. Mit dem Standard-ExpressRoute können Sie mehrere VNets innerhalb derselben geografischen Region an eine einzelne ExpressRoute-Verbindung anbinden und eine Premium-SKU (globale Reichweite) konfigurieren, um Konnektivität von jedem VNet auf der Welt zur gleichen ExpressRoute-Verbindung zu ermöglichen.

GCP hält seine Anbindung leicht verständlich. Über die Anbindung von GCP können Sie nativ nur auf private Ressourcen zugreifen. Wenn Konnektivität mit öffentlichen GCP-Ressourcen (z. B. Cloudspeicherung) erforderlich ist, können Sie einen privaten Google-Zugang für Ihre On-Premises-Ressourcen konfigurieren. Dies umfasst nicht G Suite, das SaaS-Angebot von GCP. G Suite ist immer über das öffentliche Internet oder ein Peering via IX erreichbar. Wenn der GCP-Cloudrouter eine 1:1-Zuordnung zu einer einzelnen VPC und Region hat, werden die Peerings (oder eher VLAN-Anhänge) zusätzlich zum Cloudrouter erstellt. Diese Funktionalität und dieses Modell ähneln AWS Direct Connect und erstellen eine VIF direkt auf einem VGW.

Abschließend möchten wir noch erwähnen, dass Megaport Sie nicht nur mit all diesen drei CSPs (und vielen weiteren) verbindet, sondern dass wir auch Cloud-zu-Cloud-Konnektivität zwischen den Anbietern ermöglichen, ohne dass der Datenverkehr zurück zu Ihrer lokalen Infrastruktur geleitet werden muss.

Zögern Sie nicht, uns zu kontaktieren! Wir sind gespannt darauf, von Ihren Cloud-Plänen und aktuellen Herausforderungen zu erfahren und unterstützen Sie gerne bei der Umsetzung Ihrer Initiativen.