Die versteckten Kosten eines Cloud-gehosteten SD-WAN für IaaS

Viele Unternehmen verfolgen die Strategie, sich zunächst um die Cloudmigration und dann um die Anwendungsmodernisierung zu kümmern – einschließlich SD-WAN. Der Wechsel zu einer Cloud-nativen Architektur mit Containerisierung, Microservices oder serverlosen Architekturen wie SD-WAN kann mit der Zeit die Kosten senken, die Skalierbarkeit verbessern, Entwicklungszyklen beschleunigen und die Markteinführungszeit verkürzen.

Als nächster Schritt muss jedoch dafür gesorgt werden, dass Zweigstellen die nun modernisierte Anwendung in der öffentlichen Cloud erreichen können. Doch was ist, wenn sich noch immer einige alte Anwendungen in der privaten Cloud oder Dienste in den öffentlichen Clouds von Zweit- oder Drittanbietern befinden?

Mit der Beliebtheit von SD-WAN und zunehmenden Migrationen von Unternehmens-WANs von MPLS zu breitbandbasierten Underlays bewegt sich nun geschäftskritischer Datenverkehr über öffentliche Internetverbindungen ohne Leistungsgarantie. Es ist klar, dass dieser neuerliche Trend zur „Cloud-basierten Zweigstelle“ eine Modernisierung aus Sicht der Unternehmensarchitektur erfordert.

SD-WAN vs MPLS – entdecken Sie Gemeinsamkeiten und Unterschiede in unserem Blog-Post.

Eine Option besteht darin, Cloud-basierten Datenverkehr von den Zweigstellen zurück zum Rechenzentrum und dann zur Cloud zu leiten, idealerweise über private Konnektivität. Das kann gut funktionieren; je nachdem, in welcher geografischen Lage sich das Rechenzentrum des Unternehmens befindet, können daraus aber auch Flaschenhälse resultieren, die zu erheblich mehr Latenz und geringerer Anwendungsperformance führen. Die zweite Option besteht darin, den Zweigstellen eine direkte Kommunikation mit der Cloud zu erlauben. Um dies zu erreichen, gibt es verschiedene Methoden, darunter:

• VPN-Gateways von Cloud Service Providern (AWS VPG, Azure VNG, Google Cloud VPN)
• Cloud-basiertes SD-WAN (beispielsweise AWS Transit VPC, Azure Virtual WAN, Google Cloud NCC)
• NaaS (Megaport Virtual Edge)

Standard-Zweigstelle-zu-Cloud mit VPN-Tunneln

Nehmen wir ein mittelgroßes Einzelhandelsunternehmen mit etwa 40 über die USA verteilten Zweigstellen, die auf eine Point-of-Sale-/Lagerverwaltungsplattform in der Cloud zugreifen müssen. Eine schnelle und zuverlässige Lösung bestünde darin, das standardmäßige Standort-zu-Standort-VPN-Gateway zu verwenden, das von den Cloudanbietern bereitgestellt wird.

In einer AWS-Umgebung hieße das, IPsec-Tunnel über das öffentliche Internet zu einem virtuellen privaten Gateway aufzubauen, das mit einer einzelnen Virtual Private Cloud (VPC) verbunden ist. Der Nachteil dieses Designs ist die Eins-zu-Eins-Regel, die auch für Azure gilt, da dessen Äquivalent (VPN Gateway) ebenfalls nur mit einem einzelnen VNet verbunden werden kann. Da ein virtuelles Netzwerk auf nur ein Gateway beschränkt ist, bedeutet das, dass der Aufbau eines zweiten virtuellen Netzwerks ein zweites VGW und neue IPsec-Tunnel zu allen 40 Zweigstellen erfordert. Cloudanbieter haben die Zahl der Zweigstellentunnel, die mit einem einzelnen VPN-Gateway verbunden werden können, auf einen bestimmten Wert begrenzt. Bei Azure ist dieser Wert 30 und bei AWS 10 (allerdings kann eine Erhöhung angefragt werden).

Darüber hinaus gilt auch für die erreichbare Netzwerkgeschwindigkeit ein Höchstwert. Oft wird geglaubt, die Geschwindigkeit von IPsec-Tunneln zur Cloud sei auf 1,25 Gbit/s beschränkt – dabei ist dies der Gesamtdurchsatz des Gateway. Wenn Sie also 40 Zweigstellen konfigurieren, teilen sich diese 1,25 Gbit/s untereinander auf, was zu ca. 30 Mbit/s Durchsatz je Standort führt. Außerdem sollte bedacht werden, dass die 30 Mbit/s einer Zweigstelle zu 100 % durch das öffentliche Internet vermittelt werden, wobei mit unvorhersehbaren Problemen wie Jitter, Paketverlust und Latenz gerechnet werden muss. Und da der Cloud-zu-Zweigstelle-Datenverkehr über das öffentliche Internet verläuft, entfallen darauf die üblichen Gebühren für Datenausgang oder DTO-Gebühren (Data Transfer Out) der Cloudanbieter von ca. 10 Cent für jedes Gigabyte, das Ihr virtuelles Netzwerk verlässt.

Cloud-gehostetes SD-WAN-Edge

Um die oben genannten Hürden eines üblichen auf VPN-Tunneln basierenden Designs zu überwinden, haben die Cloudanbieter und traditionellen Anbieter für Netzwerkhardware (z. B. die Megaport-Partner Cisco und Fortinet ) Lösungen entwickelt, die in ein Unternehmens-SD-WAN integriert werden können.

Fortinet Secure SD-WAN ist jetzt auf Megaport Virtual Edge (MVE) aktiviert. Lesen Sie den Blog-Post hier.

SD-WAN ist eine virtualisierte WAN-Architektur, die einen Mix aus grundlegenden Übertragungsmethoden wie MPLS, Breitband und LTE verwendet, um Zweigstellen an Anwendungen in der privaten und öffentlichen Cloud anzubinden. Einer der Hauptvorteile von SD-WAN ist die Zentralisierung von Steuerungs- und Routing-Funktionen, die den Datenverkehr durch das Overlay-WAN vermitteln.

Abgesehen von kleinen Variationen bewirkt diese Architektur im Prinzip eine Erweiterung der SD-WAN-Struktur in die öffentliche Cloud, indem Infrastructure as a Service (IaaS) verwendet und dann Software des SD-WAN-Anbieters vom Marktplatz des Cloudanbieters geladen wird (BYOL oder „Bring Your Own License“). Dies ermöglicht eine sehr schnelle Bereitstellung, ein hohes Maß an Automatisierung und einen vereinfachten Betrieb über die Verwaltungskonsole des SD-WAN-Anbieters.

Sehen wir uns zunächst eine IaaS-basierte Lösung in AWS samt ihrer zentralen Komponenten an. Zunächst wird Transit VPC als zentrales Hub für jeglichen Datenverkehr zu und von den Zweigstellen sowie als Durchgang zu den virtuellen privaten Clouds (VPCs) für die Anwendungen verwendet.

Zwei virtuelle Maschinen werden im Transit VPC aktiviert, und anschließend wird ein Image des SD-WAN-Anbieters geladen, um zwei virtuelle Router zu erstellen, die über Cisco vManage, FortiManager oder ein äquivalentes System verwaltet werden können. Die stündliche Gebühr für die zugrunde liegenden AWS VMs ist von den bei der Entwicklung ausgewählten Spezifikationen abhängig.

Im obigen Diagramm sehen Sie, dass die virtuellen Router nach Norden verlaufende IPsec-Tunnelverbindungen zu den Produktions-, Entwicklungs- und Test-VPCs über die entsprechenden virtuellen privaten Gateways (VPGs) haben. Beide virtuellen Router haben außerdem nach Süden laufende internetbasierte IPsec-Verbindungen zu jeder Zweigstelle im SD-WAN. Aus Redundanzgründen sollte jede Zweigstelle einen Tunnel zu jedem virtuellen Router aufbauen. Mit einem Routing-Protokoll nach dem BGP-Prinzip werden die privaten Subnetze in der VPC der Anwendung den virtuellen Routern angekündigt, und diese kündigen wiederum diese Subnetze den 40 Zweigstellen an (zur besseren Darstellung zeigt das Diagramm nur fünf Zweigstellen).

Sie benötigen Zweigstelle-zu-Azure-Konnektivität auf Cisco SD-WAN? Sehen Sie sich hier unser Schritt-für-Schritt-Video an.

Mit steigender Zahl von SD-WAN-Zweigstellen werden möglicherweise weitere virtuelle Maschinen (Router) benötigt, da aufgrund der benötigten Verschlüsselung/Entschlüsselung der IPsec-Tunnel bestimmte CPU- und Bandbreitenbeschränkungen gelten.

Diese SD-WAN-Lösung nutzt noch immer das öffentliche Internet, sodass die üblichen Gebühren für Datenausgang gelten. Ein weiterer versteckter Kostenfaktor ist die Möglichkeit von doppelten Gebühren für Datenausgang. Da die nach Norden verlaufenden Verbindungen internetbasierte IPsec-Tunnel verwenden, wird für jedes Gigabyte, das die VPCs der Anwendung in Richtung Transit VPC verlässt, eine Gebühr erhoben. Falls der Datenverkehr zu einer Zweigstelle hin verläuft, wird eine weitere Gebühr pro Gigabyte erhoben, wenn die Daten die Transit VPC in Richtung Süden verlassen. Effektiv zahlt der Kunde somit für jedes Gigabyte, das eine Zweigstelle erreicht, doppelte Gebühren für Datenausgang.

Abhängig von Workloads und Datenverkehr kann die IaaS-basierte SD-WAN-Lösung für einige Unternehmen extrem gut funktionieren. Sehen wir uns an, was passiert, wenn ein zweiter Cloudanbieter hinzugezogen wird, um eine langfristige Anbieterbindung zu vermeiden, Geschäftskontinuität herzustellen oder eine neue interne Anwendung zu verwenden, die beispielsweise mit Microsoft Azure am besten funktioniert. Die Architektur wird extrem komplex, da jetzt alle 40 Zweigstellen auf sowohl AWS VPCs als auch die neuen Azure VNets zugreifen können müssen.

In einer Azure-Umgebung würde ein virtuelles WAN bereitgestellt, und es würde ein VNet mit virtuellem Hub erstellt (in vielerlei Hinsicht einem AWS Transit VPC ähnlich). In diesem Hub würden erneut zwei VMs aktiviert, und darüber würde SD-WAN-Software geladen werden, um eine Network Virtual Appliance (NVA) zu erstellen. Eine vorhandene Zweigstelle verbindet sich anschließend über IPsec-Tunnel mit beiden NVAs im virtuellen Hub von Azure (zusätzlich zu den vorhandenen zwei Tunneln zu AWS). Wie im Diagramm zu sehen ist, gibt es jetzt Hunderte von IPsec-Tunneln.

Bislang haben wir nur Multicloud mit Zweigstelle-zu-Cloud-Vermittlung berücksichtigt, jedoch wird möglicherweise auch eine Cloud-zu-Cloud-Konnektivität benötigt; ein Beispiel hierfür könnte eine Datenreplikation von Cloud zu Cloud sein. Hier kann entweder der Datenverkehr durch den Flaschenhals zurück zum lokalen Rechenzentrum geleitet werden (was die Latenz erhöht), oder es können neue IPsec-Tunnel zwischen dem virtuellen Hub von Azure und der AWS Transit VPC aufgebaut werden, was logischerweise mit weiteren Gebühren für Datenausgang und Beschränkungen der Tunnelgeschwindigkeiten einhergeht.

Megaport Virtual Edge (MVE)

Megaport Virtual Edge (MVE) in Kombination mit privater Layer-2-Cloudkonnektivität wie z. B. AWS Direct Connect, Azure ExpressRoute oder Google Cloud Interconnect löst viele der Probleme, die in den ersten beiden Lösungen auftreten.

MVE verbessert Ihre vorhandene Unternehmens-SD-WAN-Plattform, indem Sie die Möglichkeit erhalten, strategisch optimale Wege zu kritischen Anwendungen aufzubauen, wo auch immer sich diese befinden. Im Wesentlichen ermöglicht MVE Unternehmen den Aufbau ihrer eigenen regionalen PoPs in wenigen Minuten und eine Vergrößerung der Reichweite ihres WAN durch das globale softwaredefinierte Netzwerk (SDN) von Megaport. Derzeit gibt es weltweit 22 MVE-Metroregionen, jede davon mit mindestens zwei Rechenzentren und Internet-Übertragungsanbietern, die MVE-Verfügbarkeitszonen unterstützen, um eine hohe End-to-End-Ausfallsicherheit des WAN zu bieten.

Schauen wir MVE einmal unter die Haube, um seine Kernelemente und Fähigkeiten zu verstehen.

MVE ist ein virtualisiertes, bedarfsgesteuertes SD-WAN-Edge-Gerät, das in drei Größen basierend auf Kombinationen von vCPU, IP-Transit und der Zahl der zu verbindenden Zweigstellen erhältlich ist. Die Software des SD-WAN-Anbieters kann vom Kunden gewählt werden; MVE unterstützt derzeit Cisco und Fortinet, und weitere sind im Laufe des Jahres 2021 geplant. Von diesem Punkt an wird MVE effektiv wie ein reguläres SD-WAN-Gerät innerhalb der WAN-Struktur des Unternehmens verwaltet und kann über Cisco vManage, FortiManager oder ein äquivalentes System konfiguriert werden.

Der Zweigstellen-Datenverkehr gelangt auf der ersten Meile über das örtliche Internet zum MVE, was abhängig von der Nähe in der Regel weniger als ~10 ms dauert. Von dort aus hat das MVE Zugang zur globalen Megaport-Struktur, die über 235 öffentliche Cloud On-Ramps umfasst und private Layer-2-Verbindungen (z. B. AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect und andere) ermöglicht.

So funktioniert es

SD-WAN-Zweigstellen können IPsec-Anhänge zum MVE über die enthaltene redundante Tier-1-IP-Übertragung mit von Megaport bereitgestellten IP-Adressen aufbauen. Nachdem der Zweigstellen-Datenverkehr am MVE angelangt ist, können Unternehmen diesen an einem zentralen MVE-Standort bündeln, schnell aus den IPsec-Tunneln im öffentlichen Internet heraus übertragen und diesen Datenverkehr über den Megaport-Backbone zurück zu den großen Cloudanbietern zurückleiten, was eine Vielzahl von Vorteilen bietet.

Vorteile

1. Anwendungsperformance: Zweigstellen, die zuvor über das öffentliche Internet auf Cloud-basierte Anwendungen zugegriffen haben, werden leistungsfähiger. Jetzt verläuft nur die „erste Meile“ über das Internet, während ein Großteil des Weges über den Megaport-Backbone geht, um Jitter, Latenz und Paketverlust zu vermeiden.

2. Zugang zur Megaport-Struktur: MVE bietet Zugang zum Megaport-Ökosystem aus mehr als 360 Service Providern und über 700 aktivierten Rechenzentren weltweit einschließlich 235+ Cloud On-Ramps (der größten Zahl aller neutralen Anbieter für Network as a Service (NaaS)).

3. Senkung der Betriebskosten: Indem die private Verbindung des Hyperscalers anstelle von Internet-IPsec-Tunneln verwendet wird, können die Gebühren für Datenausgang um 70 bis 80 % gesenkt werden. In Nordamerika bedeutet dies eine Reduzierung von durchschnittlich 10 Cent pro Gigabyte auf ca. 2 Cent pro Gigabyte. Vergleichen wir neben den Gebühren für Datenausgang zusätzlich MVE mit einer SD-WAN-Übertragungslösung auf Basis von IaaS für unsere eingangs erwähnten 40 Zweigstellen mit zwei AWS-VMs (C5 groß), die monatlich 10 TB aus der Cloud zu den Zweigstellen transportieren, kostet die MVE-Lösung monatlich 15 % weniger.

4. Vereinfachung des Netzwerks: Bei der IaaS-Lösung würde unser Beispiel mit 40 Zweigstellen mindestens vier IPsec-Tunnel je Standort erfordern, woraus sich insgesamt mindestens 160 Tunnel ergeben. Diese erfordern jeweils /30 IP-Adressen sowie Verbindungsstatus-Benachrichtigungen und belegen wertvolle CPU-Ressourcen sowohl in der Zweigstelle als auch in den Cloud-basierten virtuellen Routern. Durch den Wechsel zu MVE kann ein Unternehmen die Komplexität seiner Netzwerkarchitektur erheblich reduzieren.

5. Effizienz von SD-WAN: Die Integration Ihrer SD-WAN-Plattform in MVE ermöglicht den Aufbau strategischer Übertragungswege für die mittlere Meile durch Ihr WAN über Megaport Virtual Cross Connects (VXCs). SD-WAN-Traffic-Shaping-Dienste nutzen diese effizienteren Wege sofort für End-to-End-Anwendungsströme.

6. Bedarfsgesteuert: Es müssen keine Geräte gekauft oder in einem Rechenzentrum installiert und keine Querverbindungen hergestellt werden. MVE kann (wie die IaaS-Lösungen) in Echtzeit bereitgestellt und innerhalb von Minuten betriebsbereit gemacht werden.

7. Cloud-zu-Cloud: Da MVE eine private Layer-2-Konnektivität zu AWS und Azure bietet, können diese Verbindungen von jedem beliebigen Cloud-zu-Cloud-Datenverkehr genutzt werden, um einen kostspieligen IPsec-Tunnel oder die Umleitung des Datenverkehrs durch einen Flaschenhals zurück zu Ihrem lokalen Router zu vermeiden.

Viele erstmalige SD-WAN-Bereitstellungen sind durch das langfristige Ziel motiviert, teure MPLS-Verbindungen zu Zweigstellen durch kostengünstige Lösungen wie Breitband oder LTE zu ersetzen. Parallel dazu verfolgen die gleichen Unternehmen Strategien zur Cloudmigration und Anwendungsmodernisierung. Megaport Virtual Edge erfüllt alle diese Anforderungen, indem es als Brücke zwischen SD-WAN und der Cloud (inklusive privaten, öffentlichen, hybriden und Multiclouds) dient.

Erfahren Sie hier, wie SD-WAN Ihr Unternehmensnetzwerk verbessern kann.

SD-WAN-Technologie ist extrem leistungsfähig. Ihr Kern liegt in der Fähigkeit, den Anwendungsdatenverkehr zu formen und über mehrere WAN-Übertragungen hinweg zu lenken. Die Integration von Megaport Virtual Edge in Ihre Unternehmens-WAN-Struktur bietet mehr Flexibilität und Kontrolle über Ihr WAN, um Ihre Anwendungen zu optimieren (was mit einem Cloud-gehosteten SD-WAN-Edge nicht immer möglich ist). Durch MVE können Sie außerdem hohe Kosten in Form von Gebühren für Datenausgang einsparen und gleichzeitig Ihr Netzwerk erheblich vereinfachen.

Megaport Virtual Edge kann virtuelle Instanzen Ihrer SD-WAN-Edge-Router an 22 Standorten in Nordamerika, Asien-Pazifik und Europa hosten. Um mehr zu erfahren, klicken Sie hier .