Bei DoiT unterstützen wir unsere Partner dabei, Architekturen für Skalierung und operative Exzellenz auszulegen. Ein Thema, bei dem wir Kunden eng begleiten, ist die Planung der Netzwerkarchitektur für künftiges Wachstum – damit das eigentliche Versprechen der Cloud auch eingelöst wird.
Standalone-VPC-Architektur
Standalone-VPCs sind isolierte Netzwerkumgebungen, die innerhalb eines Cloud-Accounts oder Projekts eigenständig betrieben werden. Jede VPC bringt ihre eigene Netzwerkkonfiguration, eigene Sicherheitsregeln und eigene Routing-Richtlinien mit. Damit eignet sie sich ideal für Szenarien mit strikter Isolation oder einfachen Netzwerkanforderungen.
Wesentliche Merkmale
Jede Standalone-VPC ist vollständig von anderen VPCs abgeschottet und arbeitet als in sich geschlossene Umgebung mit eigenen, dedizierten Netzwerkressourcen. Netzwerkkonfigurationen – einschließlich Routing-Tabellen und Zugriffskontrollen – werden unabhängig verwaltet, sodass sich Richtlinien passgenau auf die Anforderungen einzelner Workloads zuschneiden lassen.
Standalone-VPCs werden je nach Konnektivitätsbedarf per Peering verbunden – bis hin zum vollständigen Service Mesh, in dem alle VPCs untereinander vernetzt sind.
Eine Standalone-VPC-Architektur passt besonders gut zu Organisationen mit überschaubaren Anwendungen, einfachen Netzwerkanforderungen und ohne nennenswerten netzübergreifenden Datenverkehr. Sie spielt ihre Stärken in Entwicklungs- und Testumgebungen aus, in denen Isolation entscheidend ist, um gegenseitige Beeinflussung zu verhindern. Auch Organisationen mit spezifischen Compliance-Vorgaben setzen häufig auf Standalone-VPCs, um sensible Workloads sauber vom restlichen Netzwerk zu trennen. Kleinere Organisationen mit begrenzten Cloud-Ressourcen profitieren zudem von der Schlichtheit und den klaren Grenzen dieses Ansatzes.
Nachteile
Durch ihre Eigenständigkeit führen Standalone-VPCs oft zu erheblichen Doppelstrukturen über verschiedene Umgebungen hinweg – mit entsprechend höheren Betriebskosten und Wartungsaufwand. Sobald Konnektivität zwischen mehreren VPCs hergestellt werden soll, steigt die Komplexität spürbar: Es braucht aufwendige Peering-Konfigurationen, mehrere Verbindungspunkte und mitunter NAT-Lösungen, um CIDR-Überlappungen aufzulösen. Mit dem Wachstum der Organisation wird der Betrieb mehrerer Standalone-VPCs zunehmend anspruchsvoll, vor allem wenn einheitliche Richtlinien über alle Umgebungen hinweg gelten sollen. Ohne zentrale Verwaltungsfunktionen ist es schwer, standardisierte Sicherheitsrichtlinien und Netzwerkkonfigurationen über viele VPCs hinweg konsistent zu halten.
Shared-VPC-Architektur
Shared VPC in Google Cloud und VPC Sharing in AWS ermöglichen es Organisationen, eine gemeinsame Netzwerkinfrastruktur aufzubauen, die sich über mehrere Projekte (bzw. Accounts in AWS) hinweg nutzen lässt. So entsteht ein zentrales Netzwerkmanagement bei gleichzeitiger Isolation und Sicherheit auf Projektebene.
Wesentliche Komponenten
Im Zentrum der Shared-VPC-Architektur steht ein Host-Projekt, das die gemeinsam genutzte VPC-Netzwerkinfrastruktur enthält und verwaltet. Service-Projekte nutzen dieses Netzwerk und behalten zugleich ihre eigene Ressourcenverwaltung und Zugriffskontrolle. Subnetze lassen sich gezielt für einzelne Projekte freigeben – mit präziser Steuerung der Ressourcenverteilung. Firewall-Regeln werden zentral verwaltet, können bei Bedarf aber für einzelne Service-Projekte individuell angepasst werden.
Die VPC wird in einem Projekt angelegt und von weiteren Projekten genutzt.
Google Cloud Shared VPC vs. AWS VPC Sharing
Die Bezeichnungen ähneln sich, und die Kernfunktion – Netzwerkressourcen zwischen Cloud-Projekten zu teilen – ist in beiden Diensten vorhanden. Google Cloud Shared VPC unterstützt hybride Konnektivität (z. B. Verbindungen zu On-Premise-Hosts) jedoch von Haus aus: Sobald im Host-Projekt eine hybride Verbindung besteht (etwa ein Cloud-VPN-Tunnel in die On-Premise-Umgebung), lässt sich der Zugriff auf den Remote-Standort einzeln je Service-Projekt freischalten. AWS VPC Sharing hingegen setzt zusätzliche Netzwerkkomponenten voraus. Eine davon ist das AWS Transit Gateway, das wir im Folgenden betrachten.
AWS Transit Gateway
Während sich AWS VPC Sharing auf das account-übergreifende Teilen von Subnetzen einer einzelnen VPC konzentriert, verbindet das Transit Gateway mehrere VPCs, VPNs und Direct-Connect-Gateways miteinander. Damit eignet es sich für komplexe Multi-VPC-Szenarien sowie für Hybrid-Cloud-Architekturen.
Jeder AWS-Account kann eine oder mehrere VPCs betreiben – alle lassen sich über das Transit Gateway miteinander verbinden.
Wir hoffen, dieser Artikel hilft Ihnen, sich im Geflecht der Netzwerkarchitekturen souverän zu bewegen. Mehr zu unseren Kompetenzbereichen finden Sie unter https://www.doit.com/services/.