Kann VPC Lattice AWS Transit Gateway ersetzen?

VPC Lattice bietet einen neuen Mechanismus, um Microservices über AWS-Konten und VPCs hinweg auf eine entwicklerfreundliche Weise zu verbinden. Wenn VPC Lattice hält, was es verspricht, könnte es die Art und Weise, wie wir Landing Zones entwerfen, verändern. Die Frage ist: Glauben Sie, dass VPC Lattice für die erste Zeit bereit ist? Wenn Sie heute eine brandneue Landezone entwerfen, würden Sie dann VPC Lattice sofort einführen? Oder wenn Sie eine bestehende Landing Zone mit AWS Transit Gateway haben, planen Sie bereits, diese durch VPC Lattice zu ersetzen? In diesem Blogbeitrag werden wir uns ansehen, was VPC Lattice ist, wie es im Vergleich zu den Alternativen abschneidet, und wir werden einige Meinungen dazu abgeben, ob wir es jetzt einführen würden.

Der Kontext: Einer unserer wichtigsten Werte bei Xebia ist das Teilen von Wissen. Zweimal im Monat treffen wir uns mit Kollegen und organisieren eine interne Konferenz mit Präsentationen, Diskussionen, Brainstorms und Workshops. Letzten Monat haben wir mit 6 Mitarbeitern den VPC Lattice Workshop von Amazon durchlaufen und unsere Ergebnisse diskutiert. Hier ist eine Zusammenfassung!

Welches Problem löst VPC Lattice?

Bei unseren Kunden beobachten wir den Trend, große Monolithen in kleinere Services aufzuteilen. Die Services werden zunehmend von Teams genutzt, wobei jedes Team über ein eigenes AWS-Konto mit einer eigenen VPC verfügt. Dies ist eine großartige Möglichkeit, die IAM-Berechtigungen zu vereinfachen (jedes Team kann nur auf sein eigenes AWS-Konto zugreifen) und die Kosten zu verfolgen (jedes Team kann seine AWS-Ausgaben auf Kontoebene verfolgen). Allerdings entsteht dadurch auch die Herausforderung, VPCs über Konten hinweg miteinander zu verbinden.

Wie haben wir das vor VPC Lattice gelöst?

Es gibt zahlreiche Technologien, die Ihnen helfen, VPCs und Konten miteinander zu verbinden:

• VPC-Peering ermöglicht Verbindungen zwischen 2 VPCs. Es ist einfach und unkompliziert, lässt sich aber nicht gut skalieren, wenn die Anzahl der VPCs wächst.
• Transit-VPCs sind eine spezielle Hub-and-Spoke-Netzwerktopologie, mit der versucht wird, das VPC-Peering skalierbarer zu machen. Dies erfordert jedoch einen selbstverwalteten Netzwerkrouter in der Transit-VPC und Sie müssen sehr darauf achten, dass sich die CIDR-Bereiche der VPCs nicht überschneiden.
• AWS Transit Gateway wurde erstmals auf der re:Invent 2018 vorgestellt und bietet einen verwalteten Service, um VPCs miteinander zu verbinden. Er macht einen selbstverwalteten Netzwerk-Router überflüssig und bietet eine fein abgestufte Kontrolle über das Routing des Layer-3-Netzwerkverkehrs. Sie müssen jedoch sicherstellen, dass es keine überlappenden CIDR-Bereiche zwischen den VPCs gibt. Die Entwickler, die die Microservices erstellen, verbringen in der Regel nicht gerne Zeit mit Netzwerkkonfigurationen und wenden sich an Netzwerkspezialisten, um die Konnektivität einzurichten.
• AWS PrivateLink wurde erstmals im November 2017 eingeführt und bietet einen Mechanismus für den Zugriff auf Services über AWS-Konten und VPCs hinweg, ohne dass Sie sich um überlappende CIDR-Bereiche kümmern müssen. AWS PrivateLink eignet sich besonders gut für die Konnektivität mit SaaS-basierten Services, bei denen Sie eine strikte Trennung zwischen Partner und Kunde wünschen. Sie können AWS PrivateLink auch verwenden, um Ihre VPCs über Konten hinweg miteinander zu verbinden. In einer größeren Einrichtung würden Sie jedoch mit einer zunehmenden Anzahl von Punkt-zu-Punkt-Verbindungen für jedes Paar aus Service und Kunde enden. Dies wird kostspielig und ist schwer zu pflegen.
• Mit AWS Resource Access Manager können Sie eine einzige große VPC für mehrere Konten freigeben. Dies ist eine einfache und oft übersehene Strategie, die das Beste aus beiden Welten bietet: eine strikte Trennung von IAM-Richtlinien und Kostenzuweisung mit einer einfachen Verbindung auf Netzwerkebene. Die Kehrseite dieses Arguments ist eine begrenzte Isolierung zwischen den Diensten. Ein Dienst könnte die verfügbaren IP-Adressen erschöpfen und die Skalierung der anderen Dienste beeinträchtigen. Für kleine Einrichtungen oder für frühe IPv6-Anwender (was einen eigenen Blogbeitrag wert ist) könnte dies ein akzeptables Risiko sein.

Bisher war AWS Transit Gateway die gängigste Lösung, da sie sich am besten mit zunehmender Komplexität skalieren lässt. Aus diesem Grund zieht der Titel dieses Blogbeitrags einen Vergleich zwischen VPC Lattice und AWS Transit Gateway.

Was sind die wichtigsten Konzepte in VPC Lattice?

Auf der höchsten Ebene unterscheidet VPC Lattice zwischen Services und Service-Netzwerken. Ein Service ist die Zugriffseinheit, um die sich die Entwicklungsteams kümmern - entweder bei der Nutzung der Service-Abhängigkeit oder beim Anbieten ihres eigenen Service für andere Nutzer. Ein Servicenetzwerk ist das, was mehrere Services logisch miteinander verbindet, um Konnektivität zu ermöglichen. Ein Dienst gehört immer nur zu einem einzigen Servicenetzwerk.

Um einen Dienst mit Ziel-Workloads zu verbinden, verwenden Sie das Konzept der Zielgruppen. Dies ähnelt einem bekannten Konzept aus Elastic Load Balancing. Eine Zielgruppe kann sich auf Instanzen, IP-Adressen, eine Lambda-Funktion oder einen Application Load Balancer beziehen. Es ist auch möglich, sich auf eine Auto Scaling Group zu beziehen und automatisch Instanzen hinzuzufügen oder zu entfernen, wenn sie skaliert. In diesem Fall müssen Sie - etwas kontraintuitiv - die Auto Scaling Group so konfigurieren, dass sie auf die VPC-Gitterzielgruppe verweist.

Was sind die Stärken von VPC Lattice?

Wie in der Einleitung erwähnt, haben wir den VPC Lattice-Workshop durchlaufen. Während und nach dem Workshop haben wir unsere Teilnehmer gefragt, was ihnen an VPC Lattice gefällt und welche Bedenken sie haben, wenn Sie VPC Lattice heute einsetzen. Beginnen wir mit den positiven Aspekten, die zur Sprache kamen:

• Den Teilnehmern gefiel die Tatsache, dass VPC Lattice mit lesbaren Domainnamen arbeitet und dass es möglich ist, diese durch CNAME-Einträge in Route 53 anzupassen.
• Die Teilnehmer waren besonders erfreut darüber, dass Sie Dienste und Dienstnetzwerke mit IAM-Richtlinien absichern können. IAM-Richtlinien ermöglichen eine feinkörnige Autorisierung auf API-Ebene.
• Die Teilnehmer waren mit der Serviceabstraktion über EC2 / EKS / Lambda zufrieden, die eine Interkonnektivität zwischen verschiedenen Stacks ermöglicht, ohne dass man sich um die zugrunde liegenden Details kümmern muss.
• Teilnehmer, die Probleme mit IAM-Berechtigungen hatten, lobten die Lesbarkeit der Fehlermeldungen, die es einfach machen, das Problem zu lokalisieren und zu beheben. Wenn Sie sich schon einmal durch CloudTrail-Protokolle gewühlt haben und aws sts decode-authorization-message benötigen, werden Sie die Einfachheit zu schätzen wissen.

Was sind die heutigen Vorbehalte, die Sie beachten müssen?

Bei all diesen Stärken und Vorteilen könnten Sie denken: Worauf warten wir noch? Warum nicht schon heute VPC Lattice einführen? Die Antwort auf diese Frage hängt von Ihrem Kontext und Ihren Anforderungen ab. Es gibt ein paar Dinge, die Sie berücksichtigen sollten:

• VPC Lattice ist großartig, wenn Ihr gesamter VPC-übergreifender Netzwerkverkehr aus HTTP/HTTPS/GRPC besteht. In einer gut ausgebauten Microservice-Architektur ist die Wahrscheinlichkeit groß, dass dies der Fall ist. Allerdings hat dies auch Konsequenzen. Zum Beispiel gibt es keinen VPC-übergreifenden SSH- oder RDP-Verkehr. Sie können dies umgehen, indem Sie Session Manager anstelle von SSH oder Fleet Manager anstelle von RDP verwenden. Und der Netzwerkverkehr zwischen dem Microservice und seiner Datenbank bleibt in der Regel innerhalb derselben VPC, was kein Problem darstellt.
• VPC Lattice wird mit einem Servicekontingent von 10 Gbps pro Availability Zone (AZ) / 10k Anfragen pro Sekunde (RPS) pro AZ geliefert. Dies ist für die meisten Anwendungsfälle ausreichend. Wenn Sie jedoch eine sehr große Einrichtung haben, müssen Sie dies berücksichtigen.
• VPC Lattice wird auf Stundenbasis abgerechnet. Wenn Sie von einer Einrichtung mit Application Load Balancern vor EC2-Instanzen kommen, sieht die Preisgestaltung für VPC Lattice ziemlich ähnlich aus. Wenn Sie jedoch von einer AWS Lambda-basierten serverlosen Einrichtung kommen, die auf Null skaliert, erhöht VPC Lattice Ihre Rechnung um einen erheblichen festen Mindestbetrag.
• Im Gegensatz zu AWS Transit Gateway bietet VPC Lattice derzeit keine Möglichkeit, eine regionenübergreifende Konnektivität zu ermöglichen. Sie würden es nur für eine Lösung für eine einzige Region verwenden.
• Schließlich ist die regionale Verfügbarkeit etwas eingeschränkt. Die gute Nachricht ist: AWS hat vor nur 2 Wochen bereits 4 Regionen in die Liste aufgenommen.

Wie schneidet VPC Lattice im Vergleich zu AWS Transit Gateway ab?

Abgesehen von der Reife, der Funktionsunterstützung und der regionalen Verfügbarkeit besteht der grundlegende Unterschied zwischen AWS Transit Gateway und VPC Lattice darin, dass Transit Gateway ein Konstrukt der Netzwerkschicht 3 ist, während VPC Lattice ein Konstrukt der Schicht 7 ist. Aus diesem Grund dient Transit Gateway als grobkörniger Mechanismus für das Routing von IP-Verkehr, unabhängig von Protokoll, Port oder Paketinhalt. Es weiß nicht, ob Sie SSH- oder HTTPS-Verkehr senden und kümmert sich ganz sicher nicht um Ihre HTTP-Header, Methoden oder Pfade.

Da VPC Lattice ein Layer 7-Konstrukt ist, versteht es das HTTP-Protokoll und gibt Ihnen eine fein abgestufte Kontrolle darüber, wohin Ihr Datenverkehr auf der Grundlage genau dieser Parameter wie HTTP-Header, Methoden und Pfade gesendet werden soll. Zusätzlich zu dieser feinkörnigen Steuerung ermöglicht es auch feinkörnige IAM-Berechtigungen, die dies berücksichtigen.

Schlussfolgerung: Kann VPC Lattice heute AWS Transit Gateway ersetzen?

Die Antwort lautet: vielleicht. Wenn Sie eine saubere HTTPS-basierte Microservice-Architektur haben, die in einer einzigen Region in angemessenem Umfang läuft, sollten Sie auf jeden Fall VPC Lattice in Betracht ziehen. Es gibt Ihnen eine fein abgestufte Kontrolle über die Sicherheit durch IAM-Berechtigungen und nimmt Ihnen einen großen Teil der Last ab, die mit der Verwaltung großer Multi-VPC-Netzwerke verbunden ist. Allerdings ist es noch sehr früh, und das Verschieben Ihrer VPC- und kontoübergreifenden Netzwerkverbindung ist ein invasiver Vorgang. Wenn Sie also ein typischer Early Adopter sind und dies interessant aussieht, empfehlen wir Ihnen zumindest einen PoC durchzuführen!

Wenn Sie noch am Überlegen sind und sich darüber unterhalten möchten, können Sie mir gerne eine E-Mail an adriaan.dejonge@xebia.com schicken.

Mit Dank an Jacco Kulman, Joris Conijn, Kevin Kessels, Konstantinos Bessas, Laurens Knoll und Tibor Hercz für die Teilnahme an den VPC Lattice-Workshops und den Austausch von Meinungen, die als Input für diesen Blogbeitrag dienten.

Bildlizenz für das Bannerbild: Creative Commons CC0