VPC-Netzwerke

Ein Virtual Private Cloud-Netzwerk (VPC) ist eine virtuelle Version eines physischen Netzwerks, z. B. eines Netzwerks in einem Rechenzentrum. Es stellt die Verbindung für Ihre Compute Engine VM-Instanzen, Google Kubernetes Engine-Cluster, Instanzen der flexiblen App Engine-Umgebung und andere Ressourcen in Ihrem Projekt her.

Projekte können mehrere VPC-Netzwerke enthalten. Neue Projekte beginnen mit einem Standardnetzwerk mit einem Subnetzwerk (Subnetz) in jeder Region (ein VPC-Netzwerk im automatischen Modus), es sei denn, Sie haben eine Organisationsrichtlinie erstellt, die dies verhindert.

Spezifikationen

VPC-Netzwerke haben folgende Eigenschaften:

  • VPC-Netzwerke und die damit verknüpften Routen und Firewallregeln sind globale Ressourcen. Sie sind nicht mit einer bestimmten Region oder Zone verknüpft.

  • Subnetze sind regionale Ressourcen. Von jedem Subnetz wird ein Bereich von IP-Adressen definiert.

  • Der Traffic zu und von den Instanzen kann mit Firewallregeln für Netzwerke gesteuert werden.

  • Die Ressourcen in einem VPC-Netzwerk können abhängig von den geltenden Firewallregeln über interne (private) IPv4-Adressen miteinander kommunizieren. Weitere Informationen finden Sie unter Kommunikation im Netzwerk.

  • Instanzen mit internen IP-Adressen können mit APIs und Diensten von Google kommunizieren. Weitere Informationen finden Sie unter Optionen für den privaten Zugriff.

  • Die Netzwerkverwaltung kann über Cloud IAM-Rollen (Cloud Identity and Access Management) abgesichert werden.

  • Eine Organisation kann eine freigegebene VPC verwenden, um ein VPC-Netzwerk als Teil eines gemeinsamen Hostprojekts zu nutzen. Autorisierte Cloud IAM-Mitglieder aus anderen Projekten in derselben Organisation können Ressourcen erstellen, für die Subnetze des freigegebenen VPC-Netzwerks genutzt werden.

  • VPC-Netzwerke können über VPC-Netzwerk-Peering mit anderen VPC-Netzwerken aus anderen Projekten oder Organisationen verbunden werden.

  • VPC-Netzwerke können in Hybridumgebungen über Cloud VPN oder Cloud Interconnect sicher verbunden werden.

  • VPC-Netzwerke unterstützen ausschließlich IPv4-Unicast-Traffic. Sie unterstützen keinen Broadcast-, Multicast- oder IPv6-Traffic innerhalb des Netzwerks: VMs im VPC-Netzwerk können nur an IPv4-Ziele senden und nur Traffic von IPv4-Quellen empfangen. Es ist aber möglich, eine IPv6-Adresse für einen globalen Load-Balancer zu erstellen.

Netzwerk- und Subnetzterminologie

Die Begriffe Subnetzund Subnetzwerk werden synonym verwendet. Sie sind in der Google Cloud Console, in gcloud-Befehlen und in der API-Dokumentation austauschbar.

Ein Subnetz ist nicht dasselbe wie ein (VPC-)Netzwerk. Netzwerke und Subnetze sind unterschiedliche Objekttypen in Google Cloud.

Netzwerke und Subnetze

Jedes VPC-Netzwerk besteht aus mindestens einer verwendbaren IP-Bereichspartition, die als Subnetz bezeichnet wird. Jedes Subnetz ist einer Region zugeordnet. VPC-Netzwerke sind keine IP-Adressbereiche zugeordnet. Für die Subnetze sind IP-Bereiche definiert.

Ein Netzwerk kann erst verwendet werden, wenn es mindestens ein Subnetz hat. VPC-Netzwerke im automatischen Modus erstellen automatisch Subnetze in jeder Region. Benutzerdefinierte VPC-Netzwerke enthalten zuerst keine Subnetze, sodass Sie selbst bestimmen können, welche Subnetze erstellt werden sollen. Sie können mehr als ein Subnetz pro Region erstellen. Weitere Informationen zu den Unterschieden zwischen VPC-Netzwerken im automatischen Modus und im benutzerdefinierten Modus finden Sie unter VPC-Netzwerktypen.

Wenn Sie eine Ressource in Google Cloud erstellen, wählen Sie ein Netzwerk und ein Subnetz aus. Für andere Ressourcen als Instanzvorlagen können Sie auch eine Zone oder Region auswählen. Bei der Auswahl einer Zone wird implizit auch die zugehörige übergeordnete Region ausgewählt. Da Subnetze regionale Objekte sind, wird durch die Auswahl der Region für eine Ressource auch festgelegt, für welche Subnetze sie verwendet werden kann:

  • Die Erstellung einer Instanz umfasst die Auswahl einer Zone, eines Netzwerks und eines Subnetzes. Es können nur die in der ausgewählten Region vorhandenen Subnetze ausgewählt werden. Google Cloud weist der Instanz aus dem Bereich der verfügbaren Adressen im Subnetz eine IP-Adresse zu.

  • Die Erstellung einer verwalteten Instanzgruppe umfasst die Auswahl einer Zone oder Region (abhängig vom Gruppentyp) und einer Instanzvorlage. Es können nur Instanzvorlagen ausgewählt werden, in denen Subnetze in der ausgewählten Region für die verwaltete Instanzgruppe definiert wurden.

    • Instanzvorlagen sind globale Ressourcen. Zur Erstellung einer Instanzvorlage gehört die Auswahl eines Netzwerks und eines Subnetzes. Wenn Sie ein VPC-Netzwerk im automatischen Modus auswählen, können Sie automatische Subnetze verwenden. Bei dieser Einstellung wird die Subnetzauswahl auf die verfügbaren Subnetze in der ausgewählten Region aller verwalteten Instanzgruppen ausgedehnt, die die Vorlage verwenden. VPC-Netzwerke im automatischen Modus haben per Definition ein Subnetz in jeder Region.
  • Die Erstellung eines Kubernetes-Containerclusters umfasst die Auswahl einer Zone oder Region (abhängig vom Clustertyp), eines Netzwerks und eines Subnetzes. Es können nur die in der ausgewählten Region vorhandenen Subnetze ausgewählt werden.

Modus für Subnetzerstellung

Google Cloud bietet zwei Arten von VPC-Netzwerken, die durch den Subnetzerstellungsmodus bestimmt werden:

  • Wenn ein VPC-Netzwerk im automatischen Modus erstellt wird, wird automatisch ein Subnetz aus jeder Region darin angelegt. Diese automatisch erstellten Subnetze verwenden eine Reihe vordefinierter IP-Adressbereiche, die sich innerhalb des CIDR-Blocks 10.128.0.0/9 befinden. Wenn neue Google Cloud-Regionen verfügbar sind, werden mit einem IP-Bereich aus diesem Block automatisch neue Subnetze in diesen Regionen zu VPC-Netzwerken im automatischen Modus hinzugefügt. Zusätzlich zu den automatisch erstellten Subnetzen können Sie weitere Subnetze manuell zu VPC-Netzwerken im automatischen Modus in Regionen hinzufügen, die Sie mithilfe von IP-Bereichen außerhalb von 10.128.0.0/9 auswählen.

  • Wenn ein VPC-Netzwerk im benutzerdefinierten Modus erstellt wird, werden keine Subnetze automatisch erstellt. Diese Art von Netzwerk bietet Ihnen vollständige Kontrolle über die zugehörigen Subnetze und IP-Bereiche. Sie entscheiden anhand der von Ihnen festgelegten IP-Bereiche, welche Subnetze in den ausgewählten Regionen erstellt werden sollen.

Sie können ein VPC-Netzwerk vom automatischen Modus in den benutzerdefinierten Modus konvertieren. Diese Konvertierung ist nur in eine Richtung möglich. VPC-Netzwerke im benutzerdefinierten Modus können nicht in VPC-Netzwerke im automatischen Modus umgewandelt werden. Wenn Sie Hilfe bei der Entscheidung benötigen, welcher Netzwerktyp Ihren Anforderungen entspricht, lesen Sie sich den Abschnitt Überlegungen zu VPC-Netzwerken im automatischen Modus durch.

Standardnetzwerk

Sofern Sie diese Option nicht deaktivieren, beginnt jedes neue Projekt mit einem Standardnetzwerk. Das Standardnetzwerk ist ein VPC-Netzwerk im automatischen Modus mit vorkonfigurierten Firewallregeln.

Sie können die Erstellung von Standardnetzwerken deaktivieren, indem Sie eine Organisationsrichtlinie erstellen, für die die Einschränkung compute.skipDefaultNetworkCreation gilt. Projekte, die diese Richtlinie übernehmen, haben kein Standardnetzwerk.

Überlegungen zu VPC-Netzwerken im automatischen Modus

VPC-Netzwerke im automatischen Modus sind einfach einzurichten, zu verwenden und eignen sich gut für Anwendungsfälle mit diesen Attributen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist sinnvoll.

  • Die vordefinierten IP-Bereiche der Subnetze überschneiden sich nicht mit IP-Bereichen, die Sie für andere Zwecke benötigen (z. B. Cloud VPN-Verbindungen zu lokalen Ressourcen).

Benutzerdefinierte VPC-Netzwerke sind jedoch flexibler und besser für die Produktion geeignet. VPC-Netzwerke im benutzerdefinierten Modus eignen sich gut für Anwendungsfälle mit diesen Anforderungen:

  • Das automatische Erstellen von Subnetzen in jeder Region ist nicht erforderlich.

  • Das automatische Erstellen neuer Subnetze bei Verfügbarkeit neuer Regionen führt zu Überschneidungen mit IP-Adressen, die von manuell erstellten Subnetzen oder statischen Routen verwendet werden. Dieser Vorgang kann auch die gesamte Netzwerkplanung beeinträchtigen.

  • Sie benötigen vollständige Kontrolle über die in Ihrem VPC-Netzwerk erstellten Subnetze, einschließlich der verwendeten Regionen und IP-Adressbereiche.

  • Sie planen, VPC-Netzwerke über VPC-Netzwerk-Peering oder Cloud VPN zu verbinden. Da die Subnetze jedes Netzwerks im automatischen Modus denselben vordefinierten Bereich von IP-Adressen verwenden, können Sie Netzwerke im automatischen Modus nicht miteinander verbinden.

Subnetze und IP-Bereiche

Beim Erstellen eines Subnetzes müssen Sie einen primären IP-Adressbereich definieren. Sie können optional sekundäre IP-Adressbereiche definieren:

  • Primärer IP-Adressbereich: Sie können einen beliebigen privaten CIDR-Block gemäß RFC 1918 für den primären IP-Adressbereich des Subnetzes auswählen. Diese IP-Adressen können für primäre interne IP-Adressen der VM, Alias-IP-Adressen der VM und die IP-Adressen interner Load-Balancer verwendet werden.

  • Sekundäre IP-Adressbereiche: Sie können einen oder mehrere sekundäre IP-Adressbereiche definieren. Hierbei handelt es sich um separate CIDR-Blöcke gemäß RFC 1918. Diese IP-Adressbereiche werden nur für Alias-IP-Adressen verwendet. Die Beschränkungen pro Netzwerk beschreiben die maximale Anzahl sekundärer Bereiche, die Sie für jedes Subnetz definieren können.

Ihre Subnetze müssen keinen vordefinierten zusammenhängenden CIDR-Block bilden, bei Bedarf können Sie dies aber festlegen. In Netzwerken im automatischen Modus werden z. B. Subnetze erstellt, die sich in einen für den automatischen Modus vordefinierten IP-Bereich einfügen lassen.

Weitere Informationen finden Sie unter Mit Subnetzen arbeiten.

Reservierte IP-Adressen

Für jedes Subnetz sind vier IP-Adressen im primären IP-Bereich reserviert. In den sekundären IP-Bereichen gibt es keine reservierten IP-Adressen.

Reservierte IP-Adresse Beschreibung Beispiel
Netz Erste Adresse im primären IP-Bereich für das Subnetz 10.1.2.0 in 10.1.2.0/24
Standardgateway Zweite Adresse im primären IP-Bereich für das Subnetz 10.1.2.1 in 10.1.2.0/24
Vorletzte Adresse Vorletzte Adresse im primären IP-Bereich für das Subnetz, das von Google Cloud für eine mögliche zukünftige Verwendung reserviert ist 10.1.2.254 in 10.1.2.0/24
Broadcast Letzte Adresse im primären IP-Bereich für das Subnetz 10.1.2.255 in 10.1.2.0/24

IP-Bereiche im automatischen Modus

Diese Tabelle enthält die IP-Bereiche für die automatisch erstellten Subnetze in einem VPC-Netzwerk im automatischen Modus. IP-Bereiche für diese Subnetze befinden sich innerhalb des CIDR-Blocks 10.128.0.0/9. Netzwerke im automatischen Modus werden mit einem Subnetz pro Region erstellt, in neuen Regionen werden ihnen automatisch neue Subnetze hinzugefügt. Nicht verwendete Teile von 10.128.0.0/9 sind für zukünftige Nutzung durch Google Cloud reserviert.

Region IP-Bereich (CIDR) Standardgateway Verwendbare Adressen (von/bis einschließlich)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 bis 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 bis 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 bis 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 bis 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 bis 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 bis 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 bis 10.148.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 bis 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 bis 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 bis 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 bis 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 bis 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 bis 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 bis 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 bis 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 bis 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 bis 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 bis 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 bis 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 bis 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 bis 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 bis 10.180.15.253

Routen und Firewallregeln

Routen

Routen definieren Pfade für Pakete, die Instanzen verlassen (ausgehender Traffic). Routen in Google Cloud werden in zwei Kategorien unterteilt: systemgeneriert und benutzerdefiniert.

Jedes neue Netzwerk beginnt mit zwei Arten von systemgenerierten Routen:

  • Die Standardroute definiert einen Pfad für den Traffic zum Verlassen des VPC-Netzwerks. Sie ermöglicht allgemeinen Internetzugang zu VMs, die den Anforderungen für den Internetzugriff entsprechen. Außerdem gibt sie den typischen Pfad für privaten Google-Zugriff an.

  • Eine Subnetzroute wird für jeden der IP-Bereiche erstellt, die mit einem Subnetz verbunden sind. Jedes Subnetz hat mindestens eine Subnetzroute für seinen primären IP-Bereich. Zusätzliche Subnetzrouten werden für ein Subnetz erstellt, wenn Sie ihm sekundäre IP-Bereiche hinzufügen. Subnetzrouten definieren Pfade für den Traffic, damit VMs erreicht werden, die die Subnetze verwenden. Sie können Subnetzrouten nicht manuell entfernen.

Benutzerdefinierte Routen sind entweder statische Routen, die Sie manuell erstellen, oder dynamische Routen, die automatisch von einem oder mehreren Cloud Routern verwaltet werden. Weitere Informationen finden Sie unter Benutzerdefinierte Routen.

Ausführliche Informationen zum Routing in Google Cloud erhalten Sie in der Routenübersicht.

Modus für dynamisches Routing

Jedem VPC-Netzwerk ist ein Modus für dynamisches Routing zugeordnet, der das Verhalten aller Cloud Router im Netzwerk steuert. Cloud Router teilen Ihrem VPC-Netzwerk Routen zu und ermitteln benutzerdefinierte dynamische Routen von verbundenen Netzwerken, wenn Sie Ihr VPC-Netzwerk über einen Cloud VPN-Tunnel mithilfe von dynamischem Routing, über Dedicated Interconnect oder über Partner Interconnect mit einem anderen Netzwerk verbinden.

  • Regionales dynamisches Routing ist die Standardeinstellung. In diesem Modus gelten Routen zu lokalen Ressourcen, die von einem bestimmten Cloud Router im VPC-Netzwerk ermittelt wurden, nur für die Subnetze, die sich in derselben Region wie der Cloud Router befinden. Cloud Router geben nur die Routen zu Subnetzen in der zugehörigen Region für ihre lokalen Gegenstücke frei, wenn dies nicht durch benutzerdefinierte Advertisements geändert wurde.

  • Durch globales dynamisches Routing wird das Verhalten aller Cloud Router im Netzwerk so verändert, dass die Routen zu lokalen Ressourcen, die sie ermitteln, unabhängig von der Region von allen Subnetzen im VPC-Netzwerk verwendet werden können. Cloud Router geben Routen zu allen Subnetzen im VPC-Netzwerk mit ihren lokalen Gegenstücken frei, wenn dies nicht durch benutzerdefinierte Advertisements geändert wurde.

Informationen darüber, wie die von einem Cloud Router freigegebenen Routen angepasst werden können, finden Sie unter benutzerdefinierte Advertisements.

Der Modus für dynamisches Routing kann beim Erstellen oder Ändern eines VPC-Netzwerks festgelegt werden. Sie können ohne Einschränkung zwischen dem regionalen und globalen Modus für dynamisches Routing wechseln. Eine Anleitung finden Sie unter Modus für dynamisches Routing ändern.

Firewallregeln

Firewallregeln gelten sowohl für ausgehenden als auch für eingehenden Traffic im Netzwerk. Firewallregeln steuern den Traffic auch dann, wenn er vollständig innerhalb des Netzwerks liegt, einschließlich der Kommunikation zwischen VM-Instanzen.

Jedes VPC-Netzwerk hat zwei implizierte Firewallregeln. Eine implizierte Regel lässt den meisten ausgehenden Traffic zu, während die andere den gesamten eingehenden Traffic ablehnt. Sie können die implizierten Regeln nicht löschen, aber Sie können sie mit Ihren eigenen überschreiben. Google Cloud blockiert immer etwas Traffic, unabhängig von den Firewallregeln. Weitere Informationen finden Sie unter Blockierter Traffic.

Wenn Sie überwachen möchten, welche Firewallregel eine bestimmte Verbindung erlaubt oder abgelehnt hat, finden Sie weitere Informationen unter Logging von Firewallregeln.

Kommunikation und Zugriff

Kommunikation im Netzwerk

Die systemgenerierten Subnetzrouten definieren die Pfade zum Senden von Traffic zwischen Instanzen im Netzwerk über interne (private) IP-Adressen. Damit eine Instanz mit einer anderen Instanz kommunizieren kann, müssen auch entsprechende Firewallregeln konfiguriert werden, da jedes Netzwerk über eine implizierte Firewallregel zur Ablehnung von eingehendem Traffic verfügt.

Außer im Standardnetzwerk müssen Sie explizit Firewallregeln für eingehenden Traffic mit einer höheren Priorität erstellen, damit Instanzen miteinander kommunizieren können. Das Standardnetzwerk umfasst verschiedene Firewallregeln zusätzlich zu den implizierten Regeln, z. B. die Regel default-allow-internal, die die Kommunikation zwischen den Instanzen im Netzwerk zulässt. Das Standardnetzwerk enthält auch Eingangsregeln, die Protokolle wie RDP und SSH zulassen.

Regeln, die im Standardnetzwerk enthalten sind, können auch auf neue VPC-Netzwerke im automatischen Modus angewendet werden, die Sie über die Cloud Console erstellen.

Anforderungen für den Internetzugriff

Damit für eine Instanz ausgehende Internetverbindungen möglich sind, müssen folgende Kriterien erfüllt sein:

  • Das Netzwerk benötigt eine gültige Route für das Standard-Internetgateway oder eine benutzerdefinierte Route mit ganz allgemeinem IP-Zielbereich (0.0.0.0/0). Mit dieser Route wird der Pfad zum Internet definiert. Weitere Informationen finden Sie unter Routen.

  • Firewallregeln müssen ausgehenden Traffic von der Instanz zulassen. Die implizierte Regel zum Zulassen von ausgehendem Traffic gilt für alle Instanzen im Netzwerk, wenn sie nicht von einer Regel mit einer höheren Priorität überschrieben wird.

  • Eine der folgenden Bedingungen muss zutreffen:

    • Die Instanz muss eine externe IP-Adresse haben. Eine externe IP-Adresse kann einer Instanz bei der Erstellung oder nach der Erstellung zugewiesen werden.

    • Die Instanz muss in der Lage sein, Cloud NAT oder einen instanzbasierten Proxy zu verwenden, der das Ziel für eine statische 0.0.0.0/0-Route ist.

Kommunikation und Zugriff für App Engine

VPC-Firewallregeln gelten für Ressourcen, die im VPC-Netzwerk ausgeführt werden, z. B. Compute Engine-VMs. Für App Engine-Instanzen funktionieren Firewallregeln so:

  • App Engine-Standardumgebung: Für eingehenden Traffic gelten nur App Engine-Firewallregeln. Da App Engine-Instanzen der Standardumgebung nicht innerhalb Ihres VPC-Netzwerks ausgeführt werden, gelten VPC-Firewallregeln nicht für sie.

  • Flexible App Engine-Umgebung: Für eingehenden Traffic gelten sowohl App Engine- als auch VPC-Firewallregeln. Eingehender Traffic ist nur zulässig, wenn er von beiden Arten von Firewallregeln erlaubt wird. Für ausgehenden Traffic gelten VPC-Firewallregeln.

Weitere Informationen zur Steuerung des Zugriffs auf App Engine-Instanzen finden Sie unter Anwendungssicherheit.

Traceroute zu internetbasierten Zielen

Aus internen Gründen erhöht Google Cloud den TTL-Zähler von Paketen, die Compute Engine-Instanzen ins Internet schicken. Tools wie traceroute liefern möglicherweise unvollständige Ergebnisse, da der TTL-Zeitraum bei einigen der Hops nicht abläuft. Hops innerhalb und außerhalb des Google-Netzwerks sind möglicherweise ausgeblendet.

Die Anzahl der ausgeblendeten Hops variiert je nach den Netzwerkdienststufen der Instanz, der Region und anderen Faktoren. Wenn es nur wenige Hops gibt, ist es möglich, dass alle ausgeblendet sind. Wenn Hops in einem traceroute-Ergebnis fehlen, bedeutet dies nicht, dass der ausgehende Traffic unterbrochen ist.

Es gibt für dieses Verhalten keine Problemumgehung.

Beispiel für ein VPC-Netzwerk

Das folgende Beispiel zeigt ein VPC-Netzwerk im benutzerdefinierten Modus mit drei Subnetzen in zwei Regionen:

Beispiel für ein VPC-Netzwerk (zum Vergrößern klicken)
Beispiel für ein VPC-Netzwerk (zum Vergrößern klicken)
  • Subnet1 ist als 10.240.0.0/24 in der Region us-west1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-west1-a. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet1.
  • Subnet2 ist als 192.168.1.0/24 in der Region us-east1 definiert.
    • In diesem Subnetz befinden sich zwei VM-Instanzen in der Zone us-east1-a. Die zugehörigen IP-Adressen stammen beide aus dem verfügbaren Adressbereich in subnet2.
  • Subnet3 ist als 10.2.0.0/16 in der Region us-east1 definiert.
    • Eine VM-Instanz in der us-east1-a-Zone und eine zweite Instanz in der us-east1-b-Zone befinden sich in Subnetz3 und erhalten jeweils eine IP-Adresse aus dem verfügbaren Bereich. Da es sich bei Subnetzen um regionale Ressourcen handelt, können die Netzwerkschnittstellen von Instanzen mit einem beliebigen Subnetz in der Region mit ihren Zonen verknüpft werden.

Weitere Informationen