Freigegebene VPC

Diese Seite bietet eine Übersicht über freigegebene VPCs in Google Cloud. Eine freigegebene VPC (Virtual Private Cloud) ermöglicht einer Organisation, Ressourcen von mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können.

Wenn Sie eine freigegebene VPC verwenden, bestimmen Sie ein Projekt zum Hostprojekt und fügen ihm ein oder mehrere Dienstprojekte hinzu. Die VPC-Netzwerke im Hostprojekt werden als freigegebene VPC-Netzwerke bezeichnet. Zulässige Ressourcen aus Dienstprojekten können Subnetze im freigegebenen VPC-Netzwerk verwenden.

Über eine freigegebene VPC können Organisationsadministratoren administrative Aufgaben wie das Erstellen und Verwalten von Instanzen an Dienstprojektadministratoren delegieren, ohne die zentrale Steuerung von Netzwerkressourcen wie Subnetzen, Routen und Firewalls aus der Hand zu geben. Mit diesem Modell können Organisationen Folgendes tun:

  • Als Best Practice zur Sicherheit die geringste Berechtigung für Verwaltung, -Prüfung und Zugriffssteuerung des Netzwerks implementieren. Administratoren der freigegebenen VPC können Aufgaben der Netzwerkverwaltung an Netzwerk- und Sicherheitsadministratoren im freigegebenen VPC-Netzwerk delegieren, ohne Dienstprojektadministratoren die Möglichkeit zu geben, Änderungen mit Auswirkungen auf das Netzwerk durchzuführen. Dienstprojektadministratoren können nur Instanzen erstellen und verwalten, die das freigegebene VPC-Netzwerk verwenden. Weitere Informationen finden Sie im Abschnitt Administratoren und IAM.
  • Konsistente Richtlinien zur Zugriffssteuerung auf Netzwerkebene für mehrere Dienstprojekte in der Organisation anwenden und erzwingen und gleichzeitig administrative Aufgaben delegieren. Beispielsweise können Dienstadministratoren in ihrem Projekt Compute-Instanzadministratoren sein und somit Instanzen erstellen und löschen, die genehmigte Subnetze im freigegebenen VPC-Hostprojekt verwenden.
  • Budgets oder interne Kostenstellen über Dienstprojekte voneinander trennen. Weitere Informationen finden Sie im Abschnitt Abrechnung.

Konzepte

Organisationen, Ordner und Projekte

Eine freigegebene VPC verbindet Projekte innerhalb einer Organisation. Verknüpfte Projekte können sich im selben Ordner oder in verschiedenen Ordnern befinden. Wenn sie sich in verschiedenen Ordnern befinden, muss der Administrator für beide Ordner die Berechtigungen eines Administrators für freigegebene VPC haben. Weitere Informationen zu Organisationen, Ordnern und Projekten finden Sie in der Google Cloud-Ressourcenhierarchie.

Beteiligte Host- und Dienstprojekte müssen derselben Organisation angehören. Die einzige Ausnahme bildet die Migration Ihrer Projekte von einer Organisation zu einer anderen. Während der Migration können sich Dienstprojekte vorübergehend in einer anderen Organisation als das Hostprojekt befinden. Weitere Informationen zum Migrieren von Projekten finden Sie unter Projekte migrieren.

Ein Projekt, das einer freigegebenen VPC angehört, kann entweder ein Hostprojekt oder ein Dienstprojekt sein.

  • Ein Hostprojekt enthält mindestens ein freigegebenes VPC-Netzwerk. Ein Administrator für freigegebene VPC muss zuerst ein Projekt als Hostprojekt aktivieren. Danach kann er ein oder mehrere Dienstprojekte anhängen.

  • Ein Dienstprojekt ist ein Projekt, das durch einen Administrator für freigegebene VPC an ein Hostprojekt angehängt wurde. Dieser Anhang ermöglicht die Teilnahme an der freigegebenen VPC. Üblicherweise werden separate Dienstprojekte von verschiedenen Abteilungen oder Teams einer Organisation abgewickelt und verwaltet.

  • Es kann aber nicht gleichzeitig ein Hostprojekt und ein Dienstprojekt sein. Ein Dienstprojekt kann daher kein Hostprojekt für weitere Dienstprojekte sein.

  • Sie können mehrere Hostprojekte erstellen und verwenden. Jedes Dienstprojekt kann jedoch nur an ein einzelnes Hostprojekt angehängt werden. Eine Illustration finden Sie unter Beispiele mit mehreren Hostprojekten.

  • Sie können Netzwerke, Subnetze, sekundäre Adressbereiche, Firewallregeln und andere Netzwerkressourcen im Hostprojekt erstellen. Das Hostprojekt kann dann ausgewählte Subnetze, einschließlich sekundäre Bereiche, für die Dienstprojekte freigeben. Dienste, die in einem Dienstprojekt ausgeführt werden, können über eine freigegebene VPC mit Ressourcen kommunizieren, die in den anderen Dienstprojekten ausgeführt werden.

Aus Gründen der Klarheit wird ein Projekt, das kein Teil einer freigegebenen VPC ist, als eigenständiges Projekt bezeichnet. So wird deutlich gemacht, dass es sich weder um ein Hostprojekt noch um ein Dienstprojekt handelt.

Ein eigenständiges VPC-Netzwerk ist ein nicht freigegebenes VPC-Netzwerk, entweder zu einem eigenständigen Projekt oder einem Dienstprojekt gehört.

Netzwerke

Ein freigegebenes VPC-Netzwerk ist ein VPC-Netzwerk, das in einem Hostprojekt definiert und als zentral freigegebenes Netzwerk für zulässige Ressourcen in Dienstprojekten zur Verfügung gestellt wird. Freigegebene VPC-Netzwerke können im automatischen oder benutzerdefinierten Modus ausgeführt werden, Legacy-Netzwerke werden aber nicht unterstützt.

Wenn ein Hostprojekt aktiviert ist, haben Sie zwei Möglichkeiten zum Freigeben von Netzwerken:

  • Sie können alle Subnetze des Hostprojekts freigeben. Wenn Sie diese Option auswählen, werden auch alle im Hostprojekt erstellten neuen Subnetze freigegeben, einschließlich der Subnetze in neuen Netzwerken.
  • Sie können einzelne Subnetze angeben, die freigegeben werden sollen. Wenn Sie Subnetze einzeln freigeben, werden nur diese Subnetze freigegeben, es sei denn, Sie ändern die Liste manuell.

Host- und Dienstprojekte sind auf Projektebene miteinander verbunden. Dienstprojektadministratoren können auf Subnetze von freigegebenen VPC-Netzwerken im Hostprojekt zugreifen, wie im nächsten Abschnitt Administratoren und IAM beschrieben.

Einschränkungen für Organisationsrichtlinien

Über Organisationsrichtlinien und IAM-Berechtigungen werden verschiedene Ebenen der Zugriffskontrolle bereitgestellt. Mit Organisationsrichtlinien können Sie Kontrollen auf Organisations-, Ordner- oder Projektebene festlegen.

Als Administrator für Organisationsrichtlinien können Sie diese Einschränkungen für die freigegebene VPC in einer Organisationsrichtlinie festlegen:

  • Sie können die Anzahl der Hostprojekte einschränken, an die ein Nicht-Hostprojekt oder Nicht-Hostprojekte in einem Ordner oder einer Organisation angehängt werden können. Die Beschränkung gilt, wenn der Administrator für freigegebene VPC ein Dienst- an ein Hostprojekt anhängt. Sie wirkt sich nicht auf vorhandene Anhänge aus. Die bleiben erhalten, auch wenn eine Richtlinie neue Anhänge ablehnt. Weitere Informationen finden Sie im Abschnitt zur Einschränkung constraints/compute.restrictSharedVpcHostProject.

  • Sie können angeben, auf welche Subnetze von freigegebenen VPCs ein Dienstprojekt auf Projekt-, Ordner- oder Organisationsebene zugreifen kann. Die Einschränkung gilt, wenn Sie neue Ressourcen in den angegebenen Subnetzen erstellen. Sie wirkt sich nicht auf vorhandene Ressourcen aus. Diese funktionieren weiterhin normal in ihren Subnetzen, auch wenn durch eine Richtlinie das Einbinden neuer Ressourcen verhindert wird. Weitere Informationen finden Sie im Abschnitt zur Einschränkung constraints/compute.restrictSharedVpcSubnetworks.

Administratoren und IAM

Freigegebene VPCs nutzen IAM-Rollen (IAM = Identitäts- und Zugriffsverwaltung) für die delegierte Administration. Die folgenden Rollen können IAM-Hauptkonten wie Nutzern, Google-Gruppen, Google-Domains oder Google Cloud-Dienstkonten zugewiesen werden. Wenn Sie Kontakt zu einem Administrator aufnehmen müssen, können Sie ihn in der IAM-Richtlinie Ihrer Organisation oder Ihres Projekts nachschlagen. Wenn Ihnen die erforderlichen Berechtigungen dafür fehlen, dann wenden Sie sich an einen Netzwerk- oder Projektadministrator in Ihrer Organisation.

Erforderliche administrative Rollen

Administrator (IAM-Rolle) Zweck
Organisationsadministrator (resourcemanager.organizationAdmin)
  • IAM-Hauptkonto in der Organisation		 Organisationsadministratoren haben die Rolle resourcemanager.organizationAdmin für die Organisation. Sie benennen Administratoren für freigegebene VPC. Dazu weisen sie ihnen entsprechende Rollen für das Erstellen und Löschen von Projekten und die Rolle Administrator für freigegebene VPC für die Organisation zu. Organisationsadministratoren können Richtlinien auf Organisationsebene definieren, für bestimmte Ordner- und Projektaktionen sind jedoch zusätzliche Ordner- und Projektrollen erforderlich.
Administrator für freigegebene VPC
(compute.xpnAdmin und
resourcemanager.projectIamAdmin)
  • IAM-Hauptkonto in der Organisation oder
  • IAM-Hauptkonto in einem Ordner		 Administratoren für freigegebene VPC haben die Rollen Administrator für freigegebene Compute-VPC (compute.xpnAdmin) und Projekt-IAM-Administrator (resourcemanager.projectIamAdmin) für die Organisation oder einen oder mehrere Ordner. Sie führen verschiedene Aufgaben aus, die zum Einrichten einer freigegebenen VPC nötig sind. Beispielsweise aktivieren sie Hostprojekte, hängen Dienstprojekte an Hostprojekte an und delegieren den Zugriff auf einige oder alle Subnetze in freigegebenen VPC-Netzwerken an Dienstprojektadministratoren. Ein Administrator für freigegebene VPC eines bestimmten Hostprojekts ist normalerweise auch Inhaber des Projekts.
Ein Nutzer, dem die Rolle eines Administrators für freigegebene Compute-VPC für die Organisation zugewiesen wurde, hat diese Rolle für alle Ordner in der Organisation. Ein Nutzer, dem die Rolle für einen Ordner zugewiesen wurde, hat diese Rolle für den angegebenen Ordner und alle darunter verschachtelten Ordner. Ein Administrator für freigegebene VPC kann Projekte in zwei verschiedenen Ordnern nur dann verknüpfen, wenn er diese Rolle für beide Ordner hat.
Dienstprojektadministrator
(compute.networkUser)
  • IAM-Hauptkonto in der Organisation,
  • IAM-Hauptkonto in einem Hostprojekt oder
  • IAM-Hauptkonto in einigen Subnetzen des Hostprojekts		 Ein Administrator für eine freigegebene VPC definiert einen Dienstprojektadministrator. Dazu weist er einem IAM-Hauptkonto die Rolle Netzwerknutzer (compute.networkUser) für das gesamte Hostprojekt oder ausgewählte Subnetze seiner freigegebenen VPC-Netzwerke zu. Dienstprojektadministratoren sind auch zuständig für die Eigentümerschaft und die Steuerung der Ressourcen in den Dienstprojekten, sodass sie die Rolle Instanzadministrator (compute.instanceAdmin) für die entsprechenden Dienstprojekte brauchen. Außerdem können sie in den Dienstprojekten zusätzliche IAM-Rollen haben, z. B. als Projektinhaber.

Dienstprojektadministratoren

Beim Definieren der einzelnen Dienstprojektadministratoren kann ein Administrator für freigegebene VPC ihnen die Berechtigung zur Nutzung des gesamten Hostprojekts oder nur einiger Subnetze erteilen:

  • Berechtigungen auf Projektebene: Ein Dienstprojektadministrator kann die Berechtigung zur Nutzung aller Subnetze im Hostprojekt haben, wenn der Administrator der freigegebenen VPC dem Dienstprojektadministrator die Rolle compute.networkUser für das gesamte Hostprojekt zuweist. Dies hat zur Folge, dass der Dienstprojektadministrator berechtigt ist, alle Subnetze in allen VPC-Netzwerken des Hostprojekts zu verwenden, auch Subnetze und VPC-Netzwerke, die dem Hostprojekt zukünftig hinzugefügt werden.

  • Berechtigungen auf Subnetzebene: Alternativ können einem Dienstprojektadministrator stärker eingeschränkte Berechtigungen zur Nutzung einiger Subnetze gewährt werden, wenn der Administrator der freigegebenen VPC dem Dienstprojektadministrator die Rolle compute.networkUser für diese ausgewählten Subnetze zuweist. Dienstprojektadministratoren, die nur Berechtigungen auf Subnetzebene haben, können auch nur diese Subnetze verwenden. Wenn neue freigegebene VPC-Netzwerke oder neue Subnetze zum Hostprojekt hinzugefügt werden, sollte ein Administrator für freigegebene VPC die Berechtigungsbindungen für die Rolle compute.networkUser prüfen, damit die Berechtigungen auf Subnetzebene für alle Dienstprojektadministratoren mit der beabsichtigten Konfiguration übereinstimmen.

Netzwerk- und Sicherheitsadministratoren

Administratoren für freigegebene VPC haben die vollständige Kontrolle über die Ressourcen im Hostprojekt. Das schließt auch die Administration des freigegebenen VPC-Netzwerks mit ein. Optional können sie bestimmte Verwaltungsaufgaben für das Netzwerk an andere IAM-Hauptkonten delegieren:

Administrator Zweck
Netzwerkadministrator
  • IAM-Hauptkonto im Hostprojekt oder
  • IAM-Hauptkonto in der Organisation		 Ein Administrator für eine freigegebene VPC kann einen Netzwerkadministrator definieren. Dazu weist er einem IAM-Hauptkonto die Rolle Netzwerkadministrator (compute.networkAdmin) für das Hostprojekt zu. Netzwerkadministratoren haben die volle Kontrolle über alle Netzwerkressourcen mit Ausnahme von Firewallregeln und SSL-Zertifikaten.
Sicherheitsadministrator
  • IAM-Hauptkonto im Hostprojekt oder
  • IAM-Hauptkonto in der Organisation		 Ein Administrator für eine freigegebene VPC kann einen Sicherheitsadministrator definieren. Dazu weist er einem IAM-Hauptkonto die Rolle Sicherheitsadministrator (compute.securityAdmin) für das Hostprojekt zu. Sicherheitsadministratoren verwalten Firewallregeln und SSL-Zertifikate.

Spezifikationen

Kontingente und Limits

Hostprojekte freigegebener VPC unterliegen den standardmäßigen VPC-Kontingenten pro Projekt. Freigegebene VPC-Netzwerke unterliegen den Limits pro Netzwerk und den Limits pro Instanz für VPC-Netzwerke. Darüber hinaus unterliegt die Beziehung zwischen Host- und Dienstprojekten den Limits für freigegebene VPCs.

Abrechnung

Die Abrechnung für eine Ressource in einem Netzwerk freigegebener VPC wird dem Dienstprojekt zugeordnet, in dem sich die Ressource befindet. Dies ist auch dann der Fall, wenn die Ressource das Netzwerk freigegebener VPC im Hostprojekt verwendet.

  • Die Preise und Regeln, nach denen Ressourcen in Dienstprojekten berechnet werden, in denen ein freigegebenes VPC-Netzwerk verwendet wird, unterscheiden sich nicht von den Preisen und Regeln, nach denen die Ressourcen im Hostprojekt selbst berechnet werden.
  • Die Abrechnung von ausgehendem Traffic, der von einer Ressource generiert wird, wird dem Projekt zugeordnet, in dem die Ressource definiert ist:
    • Ausgehender Traffic von einer Instanz wird dem Projekt zugeordnet, in dem sich die Instanz befindet. Wenn eine Instanz beispielsweise in einem Dienstprojekt erstellt wird, jedoch ein freigegebenes VPC-Netzwerk verwendet, erfolgt die Abrechnung des in der Instanz generierten ausgehenden Traffics über das entsprechende Dienstprojekt. Auf diese Weise können Sie Ressourcen mithilfe einer freigegebenen VPC in Kostenstellen für die Organisation einteilen.
    • Kosten, die in Verbindung mit einem Load-Balancer entstehen, werden auf das Projekt mit den Load-Balancer-Komponenten angerechnet. Weitere Informationen zum Load-Balancing und freigegebenen VPCs finden Sie im Abschnitt zum Load-Balancing.
    • Ausgehender Traffic zu VPNs wird dem Projekt mit der VPN-Gateway-Ressource zugeordnet. Wenn beispielsweise ein VPN-Gateway im freigegebenen VPC-Netzwerk erstellt wird, ist es im Hostprojekt enthalten. Ausgehender Traffic durch das VPN-Gateway wird – unabhängig von dem Dienstprojekt, das die ausgehende Datenübertragung initiiert – dem Hostprojekt zugeordnet.
    • Die Kosten für Traffic von einer Ressource in einem freigegebenen VPC-Dienstprojekt, der über einen VLAN-Anhang übertragen wird, werden dem Projekt zugeordnet, zu dem der VLAN-Anhang gehört. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.

Ressourcen

Zulässige Ressourcen

Sie können die meisten Google Cloud-Produkte und -Funktionen in den Dienstprojekten einer freigegebenen VPC verwenden.

Die folgenden Einschränkungen gelten für Ressourcen, die als Teil eines Szenarios mit freigegebener VPC zulässig sind:

  • Die Verwendung eines freigegebenen VPC-Netzwerks ist nicht obligatorisch. Beispielsweise können Instanzadministratoren in einem Dienstprojekt Instanzen erstellen, die ein VPC-Netzwerk in dem Projekt verwenden. In Dienstprojekten definierte Netzwerke werden nicht freigegeben.

  • Einige Ressourcen müssen neu erstellt werden, damit ein freigegebenes VPC-Netzwerk verwendet wird. Wenn ein Administrator für freigegebene VPC ein vorhandenes Projekt an ein Hostprojekt anhängt, wird dieses Projekt in ein Dienstprojekt umgewandelt, die vorhandenen Ressourcen verwenden jedoch nicht automatisch freigegebene Netzwerkressourcen. Damit eine zulässige Ressource ein freigegebenes VPC-Netzwerk verwenden kann, muss ein Dienstprojektadministrator die Ressource erstellen und so konfigurieren, dass sie das Subnetz eines freigegebenen VPC-Netzwerks verwendet. Eine vorhandene Instanz in einem Dienstprojekt kann nicht neu konfiguriert werden, um ein freigegebenes VPC-Netzwerk zu verwenden. Es kann jedoch eine neue Instanz erstellt werden, die verfügbare Subnetze in einem freigegebenen VPC-Netzwerk verwendet. Diese Einschränkung gilt für private Zonen.

IP-Adressen

Wenn Sie eine Instanz in einem Dienstprojekt erstellen, können Sie sie je nach Subnetzkonfiguration des Hostprojekts als einzelne Stack-Instanz (nur IPv4) oder Dual-Stack-Instanz (IPv4 und IPv6) konfigurieren. Weitere Informationen finden Sie unter Instanz erstellen.

Wenn sich Instanzen in Dienstprojekten befinden, die an ein Hostprojekt angehängt wurden, das dasselbe freigegebene VPC-Netzwerk verwendet, können die Instanzen über ihre internen IPv4-Adressen oder anhand ihrer internen oder externen IPv6-Adressen intern miteinander kommunizieren, sofern die Firewallregeln das zulassen.

Dienstprojektadministratoren können Ressourcen in einem Dienstprojekt einen der folgenden IP-Adresstypen zuweisen:

  • Sitzungsspezifische IPv4- und IPv6-Adressen: Sitzungsspezifische IP-Adressen können Instanzen in einem Dienstprojekt automatisch zugewiesen werden. Wenn beispielsweise Dienstprojektadministratoren Instanzen erstellen, wählen sie das freigegebene VPC-Netzwerk und ein verfügbares freigegebenes Subnetz aus. Die primäre interne IPv4-Adresse der Instanz stammt aus dem Bereich der verfügbaren IP-Adressen im primären IPv4-Adressbereich des ausgewählten freigegebenen Subnetzes. Wenn sie die Instanz als Dual-Stack-Instanz konfigurieren, stammt die IPv6-Adresse der Instanz aus dem Bereich der verfügbaren IP-Adressen im IPv6-Subnetzbereich des ausgewählten freigegebenen Subnetzes.

    Sitzungsspezifische IPv4-Adressen können auch internen Load-Balancern automatisch zugewiesen werden. Weitere Informationen finden Sie unter Internen Passthrough Network Load Balancer erstellen oder Internen Application Load Balancer erstellen.

  • Statische interne IPv4- und IPv6-Adressen: Eine statische interne IPv4- oder IPv6-Adresse kann in einem Dienstprojekt reserviert werden. Das interne IPv4- oder IPv6-Adressobjekt muss im selben Dienstprojekt erstellt werden wie die Ressource, von der es verwendet wird, auch wenn der Wert der IP-Adresse aus den verfügbaren IP-Adressen des ausgewählten freigegebenen Subnetzes in einem freigegebenen VPC-Netzwerk stammt. Weitere Informationen finden Sie auf der Seite „Freigegebene VPC bereitstellen“ unter Statische interne IPv4- und IPv6-Adressen reservieren.

  • Statische externe IPv4-Adressen: Externe IPv4-Adressobjekte, die im Hostprojekt definiert sind, können von Ressourcen entweder in diesem Hostprojekt oder in einem angehängten Dienstprojekt verwendet werden. Dienstprojekte können auch ihre eigenen externen IPv4-Adressobjekte verwenden. Eine Instanz in einem Dienstprojekt kann beispielsweise eine regionale externe IPv4-Adresse verwenden, die entweder im Dienstprojekt oder im Hostprojekt definiert ist.

  • Statische externe IPv6-Adressen: Ein Dienstprojektadministrator kann auch eine statische externe IPv6-Adresse reservieren. Das externe IPv6-Adressobjekt muss im selben Dienstprojekt erstellt werden wie die Ressource, von der es verwendet wird, auch wenn der Wert der IP-Adresse aus den verfügbaren IPv6-Adressen des ausgewählten freigegebenen Subnetzes in einem freigegebenen VPC-Netzwerk stammt. Weitere Informationen finden Sie auf der Seite Freigegebene VPC bereitstellen unter Statische externe IPv6-Adresse reservieren.

Internes DNS

VMs im selben Dienstprojekt können einander über die internen DNS-Namen erreichen, die von Google Cloud automatisch erstellt werden. Die DNS-Namen verwenden die Projekt-ID des Dienstprojekts, in dem die VMs erstellt werden, obwohl die Namen auf interne IP-Adressen im Hostprojekt verweisen. Eine vollständige Erläuterung finden Sie in der Dokumentation zum internen DNS unter Interne DNS-Namen und freigegebene VPC.

Private Cloud DNS-Zonen

Sie können private Cloud DNS-Zonen in einem freigegebenen VPC-Netzwerk verwenden. Sie können Ihre private Zone im Hostprojekt erstellen und den Zugriff auf die Zone für das freigegebene VPC-Netzwerk gewähren. Außerdem können Sie die Zone in einem Dienstprojekt mit projektübergreifender Bindung einrichten.

Load-Balancing

Eine freigegebene VPC kann mit Cloud Load-Balancing verwendet werden. In den meisten Fällen werden die Backend-Instanzen in einem Dienstprojekt erstellt. In diesem Fall werden auch alle Load-Balancer-Komponenten im betreffenden Projekt erstellt. Obwohl es möglich ist, Backend-Instanzen im Hostprojekt zu erstellen, eignet sich eine solche Einrichtung nicht für typische Bereitstellungen freigegebener VPC, da sie die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung nicht trennt.

Über die Links in der folgenden Tabelle erhalten Sie weitere Informationen zu den unterstützten Architekturen für freigegebene VPCs für jeden Load Balancer-Typ.

Load-Balancer-Typ Links
Externer Application Load Balancer Architektur einer freigegebenen VPC
Interner Application Load Balancer Architektur einer freigegebenen VPC
Externer Proxy Network Load Balancer Architektur einer freigegebenen VPC
Interner Proxy-Network Load Balancer Architektur einer freigegebenen VPC
Interner Passthrough Network Load Balancer Architektur einer freigegebenen VPC
Externer Passthrough Network Load Balancer Architektur einer freigegebenen VPC

Beispiele und Anwendungsfälle

Grundlegende Konzepte

Abbildung 1 zeigt ein einfaches Szenario mit freigegebener VPC:

Abbildung 1. Ein Hostprojekt mit einem freigegebenen VPC-Netzwerk bietet interne Verbindungen für zwei Dienstprojekte, während ein eigenständiges Projekt keine freigegebene VPC verwendet (zum Vergrößern klicken).

  • Ein Administrator für freigegebene VPC der Organisation hat ein Hostprojekt erstellt und zwei Dienstprojekte daran angehängt:

    • In Service project A können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im freigegebenen VPC-Netzwerk konfiguriert werden. Ein Dienstprojektadministrator mit Berechtigungen, die mindestens auf Subnetzebene für 10.0.1.0/24 subnet gelten, hat Instance A in einer Zone der Region us-west1 erstellt. Diese Instanz erhält die interne IP-Adresse 10.0.1.3 aus dem CIDR-Block 10.0.1.0/24.

    • In Service project B können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im freigegebenen VPC-Netzwerk konfiguriert werden. Ein Dienstprojektadministrator mit Berechtigungen, die mindestens auf Subnetzebene für 10.15.2.0/24 subnet gelten, hat Instance B in einer Zone der Region us-east1 erstellt. Diese Instanz erhält die interne IP-Adresse 10.15.2.4 aus dem CIDR-Block 10.15.2.0/24.

  • Das eigenständige Projekt gehört nicht zum freigegebenen VPC-Netzwerk. Es ist weder ein Hostprojekt noch ein Dienstprojekt. Eigenständige Instanzen werden von IAM-Hauptkonten erstellt, die mindestens die Rolle compute.InstanceAdmin für das Projekt haben.

Mehrere Hostprojekte

Abbildung 2 zeigt, wie mit einer freigegebenen VPC separate Test- und Produktionsumgebungen erstellt werden können. In diesem Fall wurde in einer Organisation beschlossen, zwei separate Hostprojekte zu verwenden: eine Testumgebung und eine Produktionsumgebung.

Abbildung 2. Ein Hostprojekt einer Testumgebung und ein Hostprojekt einer Produktionsumgebung verwenden eine freigegebene VPC, um separate Produktions- und Testumgebungen zu erstellen (zum Vergrößern klicken).

  • Ein Administrator für freigegebene VPC der Organisation hat zwei Hostprojekte erstellt und ihnen auf folgende Weise jeweils zwei Dienstprojekte angehängt:

    • Die Dienstprojekte Apps testing und Mobile testing sind an das Hostprojekt Test environment angehängt. In jedem Projekt können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im Testing network konfiguriert werden.

    • Die Dienstprojekte Apps production und Mobile production sind an das Hostprojekt Production environment angehängt. In jedem Projekt können Dienstprojektadministratoren für den Zugriff auf alle oder einige der Subnetze im Production network konfiguriert werden.

  • Beide Hostprojekte haben ein freigegebenes VPC-Netzwerk mit Subnetzen, für die die Verwendung derselben CIDR-Bereiche konfiguriert wurde. Im Testing network und Production network sind die zwei Subnetze:

    • 10.0.1.0/24 subnet in der Region us-west1

    • 10.15.2.0/24 subnet in der Region us-east1

  • Berücksichtigen Sie Instance AT im Dienstprojekt Apps testing und Instance AP im Dienstprojekt Apps production:

    • Dienstprojektadministratoren können Instanzen dieser Art erstellen, wenn sie mindestens Berechtigungen auf Subnetzebene für das 10.0.1.0/24 subnet haben.

    • Von beiden Instanzen wird die IP-Adresse 10.0.1.3 verwendet. Das ist möglich, da sich jede Instanz in einem Dienstprojekt befindet, das an ein eindeutiges Hostprojekt mit einem eigenen freigegebenen VPC-Netzwerk angehängt ist. Die Netzwerke der Test- und Produktionsumgebung wurden gezielt auf die gleiche Weise konfiguriert.

    • Instanzen, die das 10.0.1.0/24 subnet verwenden, müssen sich in einer Zone befinden, die in der gleichen Region wie das Subnetz ist, auch wenn das Subnetz und die Instanzen in verschiedenen Projekten definiert sind. Da sich das 10.0.1.0/24 subnet in der Region us-west1 befindet, müssen Dienstprojektadministratoren, die Instanzen erstellen, die dieses Subnetz nutzen, eine Zone in derselben Region auswählen, z. B. us-west1-a.

Hybrid-Cloud-Szenario

Abbildung 3 zeigt, wie eine freigegebene VPC in einer hybriden Umgebung verwendet werden kann.

Abbildung 3. Ein freigegebenes VPC-Netzwerk ist mit einem lokalen Netzwerk und drei Dienstprojekten verbunden (zum Vergrößern klicken).

In diesem Beispiel wurde in einer Organisation ein Hostprojekt mit einem freigegebenen VPC-Netzwerk erstellt. Das freigegebene VPC-Netzwerk ist über Cloud VPN mit einem lokalen Netzwerk verbunden. Einige Dienste und Anwendungen werden in Google Cloud gehostet, andere werden lokal bereitgestellt:

  • Ein Administrator für freigegebene VPC hat das Hostprojekt aktiviert und drei Dienstprojekte damit verbunden: Service project A, Service project B und Service project C.

    • Die Dienstprojekte können jeweils von separaten Teams verwaltet werden. Die IAM-Berechtigungen wurden so konfiguriert, dass ein Dienstprojektadministrator für ein Projekt keine Berechtigungen für die anderen Dienstprojekte hat.

    • Der Administrator für freigegebene VPC hat den entsprechenden Dienstprojektadministratoren Berechtigungen auf Subnetzebene oder Projektebene erteilt, damit sie Instanzen erstellen können, die das freigegebene VPC-Netzwerk verwenden:

      • Ein Dienstprojektadministrator für Service project A mit Berechtigungen auf Subnetzebene für das 10.0.1.0/24 subnet kann Instance A darin erstellen. Der Dienstprojektadministrator muss eine Zone in der Region us-west1 für die Instanz auswählen, da das die Region ist, in der sich das 10.0.1.0/24 subnet befindet. Instance A erhält die IP-Adresse 10.0.1.3 aus dem Bereich der freien IP-Adressen im 10.0.1.0/24 subnet.

      • Ein Dienstprojektadministrator für Service project B mit Berechtigungen auf Subnetzebene für das 10.15.2.0/24 subnet kann Instance B darin erstellen. Der Dienstprojektadministrator muss eine Zone in der Region us-east1 für die Instanz auswählen, da das die Region ist, in der sich das 10.15.2.0/24 subnet befindet. Instance B erhält die IP-Adresse 10.15.2.4 aus dem Bereich der freien IP-Adressen im 10.15.2.0/24 subnet.

      • Ein Dienstprojektadministrator für Service project C mit Berechtigungen auf Projektebene für das gesamte Hostprojekt kann Instanzen in jedem der Subnetze in jedem VPC-Netzwerk im Hostprojekt erstellen. Beispielsweise kann der Dienstprojektadministrator Instance C im 10.7.1.0/24 subnet erstellen und eine Zone in der Region us-east1 auswählen, die der Region des Subnetzes entspricht. Instance C erhält die IP-Adresse 10.7.1.50 aus dem Bereich der freien IP-Adressen im 10.7.1.0/24 Subnet.

    • Alle Dienstprojekte werden separat abgerechnet.

    • Die Dienstprojektadministratoren in den einzelnen Projekten sind dafür zuständig, Ressourcen zu erstellen und zu verwalten.

  • Ein Administrator für freigegebene VPC hat Netzwerkverwaltungsaufgaben an andere IAM-Hauptkonten delegiert, die Netzwerk- und Sicherheitsadministratoren für das freigegebene VPC-Netzwerk sind.

    • Ein Netzwerkadministrator hat ein Cloud VPN-Gateway erstellt und einen VPN-Tunnel über das Internet zu einem lokalen Gateway konfiguriert. Das Cloud VPN kann Routen von seinem lokalen Gegenstück empfangen und mit ihm austauschen, da ein entsprechender Cloud Router in derselben us-east1-Region konfiguriert wurde.

    • Wenn das dynamische Routing der VPC im globalen Modus erfolgt, wendet der Cloud Router die ermittelten Routen auf das lokale Netzwerk in allen Subnetzen im VPC-Netzwerk an und gibt die Routen für alle VPC-Subnetze für sein lokales Gegenstück frei.

    • Sicherheitsadministratoren erstellen und verwalten Firewallregeln im freigegebenen VPC-Netzwerk, um Traffic zwischen Instanzen in Google Cloud und dem lokalen Netzwerk zu steuern.

    • Abhängig von den geltenden Firewallregeln kann für Instanzen in den Dienstprojekten die Kommunikation mit internen Diensten konfiguriert werden, z. B. mit lokalen Datenbank- oder Verzeichnisservern.

Zweischichtiger Webdienst

Abbildung 4 zeigt, wie eine freigegebene VPC eingesetzt werden kann, um Verwaltungsaufgaben zu delegieren und das Prinzip der geringsten Berechtigung aufrechtzuerhalten. In diesem Fall verfügt eine Organisation über einen Webdienst, der auf zwei Schichten aufgeteilt wurde, und verschiedene Teams zum Verwalten der Schichten. Schicht 1 ist die nach außen ausgerichtete Komponente, die sich hinter einem HTTP(S)-Load-Balancer befindet. Schicht 2 stellt einen internen Dienst dar, auf dem Schicht 1 aufsetzt. Sie wird durch einen internen TCP/UDP-Load-Balancer ausgeglichen.

Abbildung 4. In diesem zweischichtigen Webdienst sind eine nach außen gerichtete Komponente und ein interner Dienst mit einem gemeinsamen freigegebenen VPC-Netzwerk verbunden und werden von verschiedenen Teams verwaltet (zum Vergrößern klicken).

Mit der freigegebenen VPC können Sie jede Schicht des Webdiensts anderen Projekten zuordnen, damit diese von unterschiedlichen Teams verwaltet werden können, wobei ein freigegebenes VPC-Netzwerk gemeinsam genutzt wird:

  • Ressourcen wie Instanzen und Load-Balancer-Komponenten für die einzelnen Schichten werden in einzelnen Dienstprojekten angesiedelt, die von verschiedenen Teams verwaltet werden.

  • Jedes Dienstprojekt in einer Schicht wurde von einem Administrator für freigegebene VPC an das Hostprojekt angehängt. Der Administrator für freigegebene VPC hat auch das Hostprojekt aktiviert.

    • Jede Schicht des Webdiensts kann von separaten Teams verwaltet werden, da diese Dienstprojektadministratoren im entsprechenden Dienstprojekt sind.

    • Alle Dienstprojekte werden separat abgerechnet.

    • Die Dienstprojektadministratoren in den einzelnen Projekten sind dafür zuständig, Ressourcen zu erstellen und zu verwalten.

  • Die Netzwerkzugriffssteuerung sieht folgendermaßen aus:

    • IAM-Hauptkonten, die nur in Schicht 1 arbeiten, sind Dienstprojektadministratoren für das Tier 1 service project und erhalten nur Berechtigungen auf Subnetzebene für das 10.0.1.0/24 subnet. In diesem Beispiel hat einer dieser Dienstprojektadministratoren drei Tier 1 instances in diesem Subnetz erstellt.

    • IAM-Hauptkonten, die nur in Schicht 2 arbeiten, sind Dienstprojektadministratoren für das Tier 2 service project und erhalten nur Berechtigungen auf Subnetzebene für das 10.0.2.0/24 subnet. In diesem Beispiel hat ein Dienstprojektadministrator drei Tier 2 instances in diesem Subnetz sowie einen internen Load-Balancer erstellt, dessen Weiterleitungsregel eine IP-Adresse aus dem verfügbaren Bereich dieses Subnetzes verwendet.

    • IAM-Hauptkonten, die den gesamten Webdienst betreuen, sind Dienstprojektadministratoren in beiden Dienstprojekten und haben Berechtigungen auf Projektebene für das Hostprojekt. Sie können deshalb jedes beliebige Subnetz im Hostprojekt verwenden.

    • Optional kann ein Administrator für freigegebene VPC Netzwerkverwaltungsaufgaben an Netzwerk- und Sicherheitsadministratoren delegieren.

Weitere Informationen