AWS-Netzwerkkonzepte als Diagramm

• Um die komplexen Einträge im AWS-VPC-Dashboard besser zu verstehen, wurde eine Mindmap erstellt, die die Beziehungen zwischen AWS-Netzwerkressourcen auf einen Blick zeigt
• Als wichtigste Referenz diente Toni Pasanens AWS Networking Fundamentals; die netzwerkbezogenen Ressourcen wurden mit Fokus auf ihre Verbindungsstruktur geordnet
• AWS-Networking wird komplex, weil es viele verschiedene Verbindungstypen gibt, darunter Verbindungen zwischen Account und On-Premises, Account und Account, VPC und VPC, Subnetz und Subnetz, VPC und Internet sowie zwischen VPC und AWS-Services
• Das Ergebnis ist eine Mindmap, die AWS-Networking-Komponenten miteinander verbindet; auch die Lucidchart-Originaldatei ist einsehbar
• Entwickler, die AWS-Networking erstmals strukturieren, können sie nutzen, um visuell zu erfassen, wie verschiedene Ressourcen miteinander in Beziehung stehen

---

Verwirrung ausgehend vom VPC-Dashboard

• Vor März 2023 war es schwer zu verstehen, was im AWS-VPC-Dashboard vor sich geht
• Im linken Panel gab es so viele Einträge, dass die Scrollleiste lang war, und es war schwierig nachzuvollziehen, wie die einzelnen Ressourcen miteinander verbunden sind

Referenzmaterial und Ansatz der Strukturierung

• Um die verschiedenen Ressourcen zu verstehen, die an AWS-Networking beteiligt sind, wurde Toni Pasanens AWS Networking Fundamentals größtenteils gelesen
• Nach der Lektüre des Buchs wurde festgehalten, dass es deshalb so viele AWS-Networking-Ressourcen gibt, weil es viele mögliche Verbindungsarten gibt

Verbindungstypen im AWS-Networking

• AWS-Networking umfasst mehrere Arten von Verbindungen
  • Verbindungen zwischen AWS-Account und On-Premises
  • Verbindungen zwischen Account und Account
  • Verbindungen zwischen VPC und VPC
  • Verbindungen zwischen Subnetz und Subnetz
  • Verbindungen zwischen VPC und Internet
  • Verbindungen zwischen VPC und bestimmten AWS-Services

Ergebnis: Mindmap

• Um die vielen Teile miteinander zu verbinden, wurden die AWS-Networking-Konzepte als Mindmap dargestellt
• Die editierbare Originalversion ist über den Lucidchart-Link verfügbar
• Es wird um Feedback gebeten, ob sie nützlich ist oder Fehler enthält

[GN⁺]

Kommentare auf Hacker News

• Ich verstehe nicht, warum das Debugging von IAM-Richtlinien und Authentifizierungsproblemen bei AWS so ein Chaos ist.
  Wer ein Wettbewerber werden will, sollte sich genau darauf konzentrieren. Ich habe Stunden damit verschwendet, die Ursache für „keine Berechtigung“-Fehler zu finden, und die offizielle Dokumentation sagt im Grunde, man solle sich manuell durch rund acht möglicherweise greifende Richtlinientypen wie SCPs, IAM und Ressourcenrichtlinien wühlen.
  Selbst wenn man schließlich die Dokumentation zu Athena und CloudTrail findet, fehlt die Hälfte der Requests ohne erkennbaren Grund, und obwohl die Fehlermeldung eine Request-ID enthält, lässt sich damit nicht einfach suchen. Man sollte direkt nach der Request-ID suchen können und klar angezeigt bekommen, welche Richtlinie die Anfrage abgelehnt hat.
  Von Anfang bis Ende ist das ein komplettes Durcheinander, und manchmal wirkt es so, als müsse dieser Zustand erhalten bleiben, um mehr Supportverträge verkaufen zu können.

  • Zynisch betrachtet freue ich mich sogar über diese Lage. Firmen, die auf den AWS-Hype aufgesprungen sind, zahlen nun den Preis dafür, und mein Gehalt ist darin enthalten.
    Für private Projekte wähle ich, von sehr seltenen Ausnahmen abgesehen, fast immer Alternativen, die ein besseres Preis-Leistungs-Verhältnis bieten. Vor etwa zehn Jahren wurde AWS sinngemäß verkauft mit „wir verwalten die Systeme, also entlasst eure Systemadministratoren“. Heute sind gute AWS-DevOps-Engineers teuer und schwer zu finden, und wenn man die AWS-Empfehlungen gerade in großen Setups korrekt befolgt, wird es außerdem enorm kostspielig.
  • Bei Azure war die Kombination aus System Managed Identity und AAD meiner Erfahrung nach wirklich angenehm.
    Wenn man einer Function App Zugriff auf eine SQL-Datenbank geben wollte, reichte der tatsächliche Name der Function App; bei Aliasen konnte man auf die Objektkennung eingrenzen. Passwörter oder Zertifikate braucht man nicht mehr, es funktioniert einfach.
    Wenn man Authentifizierungspakete zusammen mit Dingen wie Application Insights nutzt, bleibt man – vorausgesetzt, man kann Logs lesen – kaum noch lange bei der Frage hängen: „Was zum Teufel ist hier passiert?“
    Allerdings muss man auch bei Azure vorher wissen, wo die Landminen liegen; wenn nicht, gerät man in ähnliche Frustration. Microsoft hinterlässt zwar deutlich bessere Hinweise auf die Position der Landminen als AWS, aber einige Hinweise fehlen praktischerweise, sodass man fast jemanden mit 20 Jahren Erfahrung und Zaubererqualitäten braucht, um durch den letzten Vorhang zu kommen und zu vermeiden, dass Kosten und Komplexität um den Faktor 5 bis 10 explodieren.
  • Bei AWS und GCP sind Zugriffskontrolle und Least Privilege wirklich schwierig.
    Das Debugging von Service Accounts wird noch mühsamer, weil dafür manchmal sogar Maschinen oder Cluster neu gestartet werden müssen. Ein Tool wie ein „Cloud-traceroute“, das genau zeigt, wo das Problem entsteht, wäre großartig.
    Fairerweise gibt es Tools für Least Privilege, die ich noch nicht ausprobiert habe: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
  • Fast alles an der AWS API grenzt an Chaos. Ohne echten Grund werden Objekte in andere Objekte verpackt und dann noch einmal verpackt, wodurch die Last, komplexe Datenstrukturen zu lernen und zu implementieren, auf die Kunden abgewälzt wird.
    Das ist wirklich nervig; solche Dinge sollten mit UX-Designern und Engineers gemeinsam entworfen werden, aber das passiert nicht.
  • Mehr Debugging-Informationen bei IAM-Fehlern bereitzustellen, würde auch Angreifern eine zusätzliche Informationsschicht öffnen.
    Wenn ein solcher Dienst Kunden zur Verfügung steht, könnte er potenziell auch Angreifern zur Verfügung stehen, und tatsächlich könnte das gegen die Security- und Compliance-Richtlinien mancher Unternehmen verstoßen.
    Trotzdem sollte man Kunden die Option geben, wenn sie ein Dokument unterschreiben, das ein großes Risiko anerkennt – ähnlich wie „gefährliche Dinge mit dem AWS-Root-Benutzer tun“.
    Weil AWS-Requests so stark verteilt sind, würde konzeptionell eine GraphQL-ähnliche Architektur wohl gut zu einem solchen System passen. Von Tracing-Systemen wie OTEL ist das auch nicht allzu weit entfernt.

• Deshalb mag ich es nicht, mit AWS arbeiten zu müssen. Das zu lernen ist kein technisches Wissen, sondern Produktwissen.
  Die Reihe TCP/IP Illustrated habe ich von Anfang bis Ende gelesen und vollständig verinnerlicht, und dieses Wissen war jahrzehntelang nützlich.
  AWS-Wissen dagegen ist zwar für sich genommen komplex, aber ich sträube mich jedes Mal dagegen, es zu lernen. Wenn ich mir dieses Diagramm ansehe, bin ich mir nicht sicher, wie erfolgreich das war, falls das Ziel Vereinfachung war.

  • Wenn es einen Kompromiss mit anderen Zielen als Einfachheit gibt, kann ich das eher nachvollziehen.
    Wenn das Ziel zum Beispiel ist, Enterprise-Kunden die Nachbildung eines virtuellen Enterprise-Netzwerks oder eines virtuellen Rechenzentrumsnetzes zu ermöglichen, dann sind diese deutlich komplexer als ein Client-TCP-Stack.
    Für einfache Nutzung sind auch die Defaults einfach. In komplexen Fällen braucht man zwar AWS-spezifisches Produktwissen, aber die meisten Grundkonzepte teilt man mit anderen Clouds oder On-Premises-Netzwerken. Ähnlich wie das Erlernen der n-ten Programmiersprache.
  • Nicht unbedingt; es ist vor allem eine Frage der Perspektive aus einem anderen Fachgebiet.
    TCP/IP ist nützliches Wissen für Netzwerkprogrammierer. In Uni-Kursen zu Netzwerken haben wir mit echter Hardware Netzwerke, Subnetze, Routing-Tabellen, Routing-Protokolle wie RIP, OSPF und BGP, NAT usw. behandelt, und dank starker Cisco-Förderung waren wir am Ende des Semesters auf CCNA-Zertifizierungsniveau.
    Wir haben auch viel „Produktwissen“ gelernt, etwa wie Cisco-Produkte funktionieren, aber das meiste davon habe ich vergessen; die Kernkonzepte lassen sich gut auf Azure, AWS und GCP übertragen. Eine Cloud-VPC ist das virtuelle Gegenstück zu einem echten Netzwerk, so wie eine virtuelle Maschine das Gegenstück zu einer echten Maschine ist.
    Besonders NAT verwirrt die Leute wirklich. Noch grundlegender tun sich viele Engineers schon mit CIDR-Notation oder TCP selbst schwer. Zum Beispiel glauben sie, dass send() den übergebenen Buffer als eine Einheit sendet, oder dass recv() immer eine vollständige „Message“ erhält. Auch der Unterschied zwischen Verbindungs-Timeout und Peer-Reset sorgt oft für Verwirrung.
    Allerdings wünschte ich, dieses Wissen wäre nicht nötig. IPv6 macht Netzwerke so groß, dass viele Dinge wie die Planung von Subnetzgrößen wegfallen. NAT darf gerne in der kalten Hölle verschwinden. VPNs will ich auch nie wieder sehen; man kann einfach TLS verwenden. Cloud-Firewalls, die IP-Adressen wie Authentifizierung behandeln, und die dadurch entstehenden irreführenden Fehler würde ich ebenfalls gern abschaffen. Azure ist in dieser Hinsicht furchtbar.
  • Ich sehe das als eine Situation mit dem langsam gekochten Frosch. AWS’ Ziel ist nicht Einfachheit, sondern Marktanteil.
    Wie viele professionelle Software war es anfangs aus Notwendigkeit einfach, wurde aber mit der Zeit komplexer; AWS ist durch die Attraktivität vollständig verwalteter On-Demand-Infrastrukturdienste und die Ressourcen, die Amazon hineingepumpt hat, schnell aufgebläht.
    Der Wert, sich nicht direkt mit Hardware befassen zu müssen, ist weiterhin groß, aber neben dem Listenpreis zahlt man eindeutig auch den Preis von schwer portierbarem, anbieterspezifischem Wissen.
  • Es wäre gut gewesen, wenn sie Standardbegriffe verwendet hätten. Zum Beispiel hätte ein Konzept wie ein virtueller Router gereicht, mit dem man Internet, NAT, Verbindungen zu anderen VPCs, Firewall-Regeln usw. konfigurieren kann.
    Stattdessen gibt es jede Menge Einmalkonzepte wie „internet gateway“, „NAT gateway“, „egress only internet gateway“ und „transit gateway“. Am Ende entsteht wohl eine Generation von Engineers, die nur „Cloud“ verstehen, aber nicht, wie es tatsächlich funktioniert.
  • Das ist undifferenzierte Schwerstarbeit. Unternehmen müssen keine Engineers mehr ausbilden und einstellen, die tiefes Wissen über TCP/IP und Hardware-Router haben, und müssen auch nicht das Chaos aufräumen und warten, nachdem diese gegangen sind.
    Man kann alle „undifferenzierten“ Komponenten an AWS abgeben und sich auf das Geschäft konzentrieren, in dem man gut ist.

• Hätte man einfach normale globale Adressierung und Firewalls bereitgestellt, wäre der Großteil dieser Komplexität verschwunden.
  Wir vergessen leicht, wozu das Internet auf IP-Ebene da ist und welche Probleme eine Ende-zu-Ende-Architektur löst.
  Was AWS als „Well-Architected™“-Networking lehrt, ist in Wahrheit eher ein profitabler Cargo-Kult und führt zu Komplexität, einem Labyrinth aus lauter ähnlichen 10.x-Netzen, Adresskonflikten, grobschlächtigen Proxys, wenn man sie miteinander kommunizieren lassen will, geringerer tatsächlicher Sicherheit und Vendor Lock-in. Komplexität ist der Feind der Sicherheit.

  • Es ergibt auch keinen Sinn, Senior Engineers mit Domänenexpertise für die Lösung von Geschäftsproblemen herzusetzen und ihnen zu sagen, sie sollten dank „Cloud“ zu DevOps/NetworkOps/SecOps werden und mit Terraform die Netzwerk-, Firewall- und Cybersicherheitslösung für die Anwendung fertigstellen.
    Frühere Systemadministratoren bekamen ja nicht nur die Hälfte oder ein Viertel meiner Vergütung, und normalerweise verwaltete eine Person genug Hardware für 100 Entwickler. Der Overhead dafür, dass der Rest diese Ausweitung des Aufgabenbereichs und den Hirnschaden vermeiden konnte, lag also bei ungefähr 0,5 %.
    Bei AWS erleben wir wieder einmal ganz buchstäblich den Tod der Expertise.
  • Die Formulierung „profitabler Cargo-Kult führt zu Komplexität“ erklärt ziemlich sauber das meiste, was man in der Tech-Branche sieht.
  • Ich glaube, Amazon Lightsail ist bis zu einem gewissen Grad so etwas. Ich habe es zwar nicht wirklich genutzt, aber soweit ich weiß, abstrahiert es die Networking-Konfiguration.
    Und globale Adressierung plus Firewall ist im Grunde doch möglich, wenn man eine VPC nur mit öffentlichen Subnetzen erstellt und Security Groups wie eine Firewall verwendet, oder? Best Practice sind öffentliche/private Subnetze und NAT-Gateways, aber es scheint nicht unmöglich zu sein, sich nur auf Security Groups zu verlassen.
  • Meinst du so etwas wie bei Google Cloud, wo VPCs global sind und man standardmäßig Subnetze pro Region erstellen kann?
    Das liegt außerdem hinter globalen Anycast-IPs.
  • Es ist komplizierter als das. Die Sicherheitsabteilungen vieler Unternehmen wollen die Sicherheitskonzepte, die sie On-Premises genutzt haben, unverändert in die Cloud übertragen, und Regulierungsbehörden tun das oft ebenfalls.
    Dadurch entsteht ein großer Teil der unnötigen Komplexität, die wir bei Cloud-Networking sehen.

• Diese Mindmap ließe sich vermutlich noch auf ein paar Networking-Konzepte vereinfachen.
  Dann würden die meisten Beziehungen und Pfeile verschwinden, und die AWS-Konzepte ließen sich auch auf andere Clouds oder das Heimnetzwerk abbilden.
  https://news.ycombinator.com/item?id=18925350 ist eine sehr gute Visualisierung der Grundlagen. Wenn man damit anfängt, was ein Netzwerk ist und was innen und außen bedeutet, wird das mentale Modell viel einfacher, und AWS-Funktionen ergeben ziemlich viel Sinn, auch ohne alle Details zu kennen.

  • Die Diagramme im Original zeigen die von AWS angebotenen Services aus der Perspektive der direkten Planung, und als Ergebnis einer Mindmap hat es dem Autor sicher geholfen, die Komplexität von AWS zu verstehen.
    Im Ergebnis fasst es ein komplexes System klar und prägnant zusammen. Das ist Material, auf das ich zurückkommen werde, wenn ich mich das nächste Mal durch den AWS-Wald schlage.
  • Netzwerkdiagramme für AWS habe ich im Grunde immer als verschachtelte Rechtecke gezeichnet.
    Zum Beispiel liegen Subnetze in einem Rechteck für eine Availability Zone, darum herum eine VPC, und dieses Rechteck liegt in einer Region. Ungefähr so, nur schöner gezeichnet: https://images.edrawsoft.com/articles/aws-diagram-examples/e...

• Ich erinnere mich an die aufregenden frühen Cloud-Zeiten, als AWS-Networking noch einfach war.
  Trotzdem war klar, dass es so kommen würde. Wenn man für alle alles sein will, muss man am Ende zwangsläufig den Wahnsinn von Legacy-IPv4-Data-Center-Networking nachbilden.
  Kürzlich wollte ich in Azure etwas konzeptionell Einfaches tun: ein Storage Account mit Datenbank-Backups nicht dem Internet aussetzen, sodass jeder daran herumstochern kann.
  Ich dachte, man müsste nur die Firewall einschalten, aber in die Allowlist konnte man nur Subnetze eintragen, und zwar jedes Subnetz einzeln. Kein virtuelles Netzwerk, und auch kein „alle meine virtuellen Netzwerke“, was anderswo gut funktioniert.
  Es gibt auch die Funktion Private Endpoint, aber die senkt die Performance und kostet extra. Offenbar muss man die Cloud-Feen dafür entschädigen, dass es schwierig ist, in einer softwaredefinierten Netzwerkkonfiguration eine Adresse von „public“ auf „private“ umzustellen.
  In der Praxis funktioniert es aber nicht. Man muss DNS überschreiben, damit Clients es finden; als ich es an die AD-Domain gehängt habe, konnte der PaaS-Service nicht mehr darauf zugreifen.
  Am Ende verging eine Woche damit, eine zusätzliche kostenpflichtige private DNS-Zone anzulegen, sie mit dem Hub-Netzwerk zu verbinden, noch den ebenfalls kostenpflichtigen DNS-Resolver-Service anzubinden und eine Unmenge an Regeln einzurichten, damit die AD-Domain weiter funktioniert.
  Eigentlich ging es nur darum, dass russische Hacker nicht auf die Backups zugreifen können, falls ein Storage Key geleakt wird. Vielleicht kann ich nächste Woche das Subscription-Template aktualisieren, damit die virtuellen Netzwerke mit aktualisierten DNS-Einstellungen erneut bereitgestellt werden. Nicht idempotent? Kommt vielleicht irgendwann nächstes Jahr als Preview.

  • Wenn man in einem VNET einen Private Endpoint einrichtet und Azure DNS sowie das eigene DNS so konfiguriert, dass sie auf magische Weise miteinander sprechen, kann man das Gewünschte erreichen.
    Für die öffentliche Seite nimmt man danach ein public gateway oder Front Door. Ich mag es nicht, aber es war auch früher nicht unbedingt extrem unkompliziert. Es ist nur so, dass Entwickler jetzt stärker dem irren Chaos von Enterprise-Networking ausgesetzt sind, das früher strikt Aufgabe des Betriebsteams war.
    Ich nenne die DNS-Konfiguration Magie, weil das ein Bereich ist, den ich nicht selbst anfasse. Besonders bei App Service und mehreren Subscriptions kann man Subnetze nicht teilen, und man muss im Voraus planen, damit einem durch App Slots nicht der IP-Adressraum ausgeht.
    Was ich bei Azure nicht verstehe: Warum ist der Enterprise-Default nicht „gar nichts im Internet“? Wenn etwas ins Internet soll, sollte man es öffnen müssen. Man muss ohnehin mehrere Dinge wie Load Balancer konfigurieren, also ist der Weg ins Internet sowieso komplex. Zumindest in Enterprise-Einstellungen sollte die Standardeinstellung außerhalb des Internets sein.
    Vielleicht muss Microsoft es schwierig machen, weil sie Azure-Zertifizierungen verkaufen, aber ich verstehe nicht, warum man sich 2023 schon bei den Defaults mit dieser Komplexität beschäftigen muss. Dass es sehr stark anpassbar ist, ist in Ordnung.

• Das Material ist wirklich großartig. Ich hatte das Gefühl, dass die Google-Cloud-Dokumentation solche Komplexität relativ gut einführt, wenn man sie braucht, aber so eine vollständige Übersicht habe ich noch nicht gesehen.
  Allerdings musste ich mich ziemlich abmühen, um das Bild anzusehen. Auf der Seite ist es zu klein und nicht anklickbar; öffnet man es in einem neuen Tab, landet man auf einer nutzlosen imgur-ähnlichen Seite und sieht es immer noch klein. Am Ende musste ich das Bild herunterladen, um es richtig betrachten zu können.

• Das Material ist beeindruckend. Es zeigt gut, wie mächtig Mindmaps und Diagramme beim Lernen von Cloud-Produkten oder anderen Konzepten sein können.
  Ich habe sie viel beim Lernen für AWS-Zertifizierungen genutzt; selbst wenn ich lange Notizen schrieb, verstand ich deutlich mehr, wenn ich die verbundenen Services als Map sah, statt als Abfolge von Seiten. Natürlich lernen Menschen unterschiedlich.

• Ich verstehe die Kritik in diesem Thread nicht ganz. Die meisten von AWS bereitgestellten Networking-Systeme nutzt man, wenn man sie braucht.
  Elegant ist es nicht, aber es erledigt die Aufgabe. Außerdem entsprechen viele AWS-spezifische Komponenten direkt echten Networking-Konzepten. AZ entspricht einem Cage, VPC einem VLAN, PL ungefähr einem accountübergreifenden P2P-VPN.
  Der Großteil des Rests sind ebenfalls gewöhnliche Networking-Bausteine, wie man sie in typischen großen Umgebungen findet.
  Das Unternehmen, bei dem ich arbeite, betreibt ein ziemlich komplexes globales Netzwerk und ist über DX an mehreren PoPs mit AWS verbunden. Wir nutzen alles in diesem Diagramm, und jede Komponente hat einen klar definierten Zweck.
  Wenn dieses Diagramm übermäßig komplex wirkt, liegt das wahrscheinlich daran, dass man entweder nicht alles davon nutzt, es nicht für den vorgesehenen Zweck nutzt oder eben kein Network Engineer ist.

• Kann das Bild tatsächlich jemand lesen? Ich bin am Desktop und kann es nicht in einer lesbaren Auflösung ansehen.
  https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... ist ebenfalls noch eine Webseite, und das Bild ist zwar größer, aber nicht besser lesbar.

  • Völlig kaputt. Als ich „Bild in neuem Tab öffnen“ gewählt habe, sah es so aus.
    Speichern funktioniert immerhin. Danach braucht man einen großen Bildschirm. Die Größe beträgt 7.763 × 4.684 Pixel.
  • Ich bin der Autor des Originalposts, ich habe es behoben. Wäre gut zu wissen, ob es jetzt korrekt angezeigt wird.
  • Auf Mobilgeräten musste ich lange drücken und dann das Bild in einem neuen Tab öffnen.

• Wirkt unglaublich komplex. Von den drei großen Cloud-Anbietern kenne ich nur GCP; auch dort ist Networking nicht gerade simpel, aber doch einigermaßen intuitiv und konsistent.
  Es wäre interessant, wenn jemand mit mehr Multi-Cloud-Erfahrung vergleichen könnte, wie leicht oder schwierig die Einrichtung interner und externer Kommunikation bei den Big 3 jeweils ist.

  • Ich habe es nie direkt gemappt, aber fast alle Networking-Konzepte und -Module von AWS dürften in GCP in gewissem Maße direkte Entsprechungen haben.
    Das ist nicht überraschend, denn die meisten haben auch in den Networking-Standards selbst direkte Entsprechungen. Beide sind im Grunde nur unterschiedliche Blickwinkel auf die Welt des Software-defined Networking.