Kontingente und Limits

In den folgenden Abschnitten werden die Kontingente und Limits für VPC-Netzwerke (Virtual Private Cloud) beschrieben.

Kontingente

Verwenden Sie die Google Cloud Console, um zusätzliche Kontingente anzufragen.

Pro Projekt

In dieser Tabelle sind wichtige globale Kontingente für VPC-Ressourcen pro Projekt aufgeführt. Informationen zu anderen Kontingenten finden Sie in der Cloud Console auf der Seite Kontingente.

Richten Sie das Monitoring für den Messwert serviceruntime.googleapis.com/quota/allocation/usage für den Ressourcentyp Consumer Quota ein, um Kontingente pro Projekt mit Cloud Monitoring zu überwachen. Legen Sie weitere Labelfilter (service, quota_metric) fest, um den Kontingenttyp abzurufen. Weitere Informationen zum Monitoring von Kontingentmesswerten finden Sie unter Kontingentmesswerte verwenden.

Kontingent	Beschreibung
Bandbreite für ausgehenden Internettraffic	Bandbreite für ausgehenden Internettraffic pro Region von Google Cloud-VMs in allen VPC-Netzwerken des Projekts.
Netzwerke	Umfasst das Netzwerk default, das Sie entfernen können.
Subnetze	Wird auf alle Subnetze in allen Netzwerken im Projekt angewendet.
Routen	Zählt benutzerdefinierte statische Routen, die in allen VPC-Netzwerken im Projekt definiert sind. Folgende Routentypen werden dabei nicht berücksichtigt: Subnetzrouten in VPC-Netzwerken im Projekt Benutzerdefinierte dynamische Routen, die von Cloud Routern im Projekt erlernt werden Peering-Subnetzrouten, die in VPC-Netzwerke im Projekt importiert wurden Benutzerdefinierte Peering-Routen, die in VPC-Netzwerke im Projekt importiert wurden
Cloud Router	Die Anzahl der Cloud Router, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. Netzwerke haben auch ein Limit bezüglich der Anzahl von Cloud Routern in einer bestimmten Region. Weitere Informationen finden Sie unter Kontingente und Limits für Cloud Router.
Firewallregeln	Die Anzahl der Firewallregeln, die Sie für alle VPC-Netzwerke in Ihrem Projekt erstellen können.
Weiterleitungsregeln	Dieses Kontingent gilt nur für Weiterleitungsregeln für externes HTTP(S)-Load-Balancing, SSL-Proxy-Load-Balancing, TCP-Proxy-Load-Balancing und klassische VPN-Gateways. Weitere Beispiele für Weiterleitungsregeln finden Sie in den folgenden Zeilen.
Weiterleitungsregeln für externes TCP/UDP-Netzwerk-Load-Balancing	Weiterleitungsregeln für die Verwendung durch externe TCP/UDP-Netzwerk-Load-Balancer (sowohl Back-End-Dienst als auch Zielpoolarchitektur)
Weiterleitungsregeln für externe Protokolle	Weiterleitungsregeln für die externe Protokollweiterleitung an Zielinstanzen
Weiterleitungsregeln für Traffic Director	Weiterleitungsregeln für Traffic Director
Interne Weiterleitungsregeln	Unter Netzwerkkontingente finden Sie alle Arten von internen Weiterleitungsregeln, die vom internen HTTP(S)-Load-Balancing, internen TCP/UDP-Load-Balancing und der internen Protokollweiterleitung verwendet werden.
Interne IP-Adressen	Die Anzahl der regionalen statischen internen IP-Adressen, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können.
Globale interne IP-Adressen	Die Anzahl der zugewiesenen Bereiche, die Sie für den Zugriff auf private Dienste reservieren können. Jeder Bereich ist ein zusammenhängender interner IP-Adressbereich.
Statische IP-Adressen	Die Anzahl der regionalen statischen externen IP-Adressen, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können.
Statische IP-Adressen (global)	Die Anzahl der globalen statischen externen IP-Adressen, die Sie in Ihrem Projekt reservieren können.
Richtlinien für die Paketspiegelung	Die Anzahl der Paketspiegelungsrichtlinien, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. Wenn Sie dieses Kontingent erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.

Pro Netzwerk

In dieser Tabelle sind wichtige Netzwerkkontingente aufgeführt. Informationen zu anderen Kontingenten finden Sie in der Cloud Console auf der Seite Kontingente.

Informationen zum Monitoring der verfügbaren Messwerte mit Cloud Monitoring finden Sie unter Kontingentmesswerte verwenden.

Hinweis: Die Kontingente in dieser Tabelle können derzeit nicht über die Cloud Console bearbeitet werden. Wenn ein Kontingent geändert werden soll, wenden Sie sich an Ihr Vertriebsteam oder eröffnen Sie ein Support-Ticket.

Kontingent	Beschreibung
VM-Instanzen pro Netzwerk	Dieses Limit kann niedriger sein, wenn Sie mithilfe von VPC-Netzwerk-Peering das Netzwerk mit anderen Netzwerken verbinden. Weitere Informationen finden Sie unter Limits für VPC-Netzwerk-Peering. Kontingentname: INSTANCES_PER_NETWORK_GLOBAL Verfügbare Messwerte: compute.googleapis.com/quota/instances_per_vpc_network/limit compute.googleapis.com/quota/instances_per_vpc_network/usage compute.googleapis.com/quota/instances_per_vpc_network/exceeded
Maximale Anzahl von VM-Instanzen pro Subnetz	Keine separate Einschränkung.
Zugewiesene Alias-IP-Bereiche pro Netzwerk	Ein Alias-IP-Bereich ist entweder eine einzelne IP-Adresse (/32) oder ein CIDR-Block (z. B. /24 oder /16) mit Zuweisung zur Netzwerkschnittstelle einer VM. Alias-IP-Adressen können aus den primären oder den sekundären IP-Bereichen eines Subnetzes stammen. Für dieses Kontingent berücksichtigt Google Cloud die Größe der Netzmaske des Bereichs nicht. Es wird nur die Anzahl der Alias-IP-Bereiche gezählt, die allen VMs im Netzwerk zugewiesen sind. Zusätzlich zu diesem Kontingent gibt es für die Anzahl der Alias-IP-Bereiche je Netzwerkschnittstelle ein Limit pro VM. Kontingentname: ALIASES_PER_NETWORK_GLOBAL Verfügbare Messwerte: compute.googleapis.com/quota/ip_aliases_per_vpc_network/limit compute.googleapis.com/quota/ip_aliases_per_vpc_network/usage compute.googleapis.com/quota/ip_aliases_per_vpc_network/exceeded
Subnetz-IP-Bereiche (primär und sekundär) pro VPC-Netzwerk	Die Gesamtzahl von primären und sekundären Subnetz-IP-Bereichen, die allen Subnetzen eines VPC-Netzwerks zugewiesen sind. Kontingentname: SUBNET_RANGES_PER_NETWORK Verfügbare Messwerte: compute.googleapis.com/quota/subnet_ranges_per_vpc_network/limit compute.googleapis.com/quota/subnet_ranges_per_vpc_network/usage compute.googleapis.com/quota/subnet_ranges_per_vpc_network/exceeded
Weiterleitungsregeln für interne Load-Balancer pro VPC-Netzwerk	Die maximale Anzahl von Weiterleitungsregeln für interne Load-Balancer. Internes TCP/UDP-Load-Balancing Internes HTTP(S)-Load-Balancing Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln für internes Load-Balancing. Es gilt nicht pro Region. Falls Ihr Netzwerk über VPC-Netzwerk-Peering mit anderen Netzwerken verbunden ist, finden Sie weitere Informationen unter Limits für VPC-Netzwerk-Peering. Kontingentname: INTERNAL_FORWARDING_RULES_PER_NETWORK Verfügbare Messwerte: compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/limit compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/usage compute.googleapis.com/quota/internal_lb_forwarding_rules_per_vpc_network/exceeded
Weiterleitungsregeln für die interne Protokollweiterleitung	Die maximale Anzahl von Weiterleitungsregeln für die interne Protokollweiterleitung. Dieses Limit gilt für die Gesamtzahl der Weiterleitungsregeln für die interne Protokollweiterleitung. Es gilt nicht pro Region. Falls Ihr Netzwerk über VPC-Netzwerk-Peering mit anderen Netzwerken verbunden ist, finden Sie weitere Informationen unter Limits für VPC-Netzwerk-Peering. Kontingentname: INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_PER_NETWORK Verfügbare Messwerte: compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/limit compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/usage compute.googleapis.com/quota/internal_protocol_forwarding_rules_per_vpc_network/exceeded
Weiterleitungsregeln für Private Service Connect für Google APIs	Die maximale Anzahl von Weiterleitungsregeln für Private Service Connect. Dieses Limit gilt für die Gesamtzahl der Weiterleitungsregeln für Private Service Connect in allen Regionen. Dieses Limit kann nicht erhöht werden. Hier erhalten Sie weitere Informationen darüber, wie viele globale Internetadressen Sie erstellen können. Kontingentname: PSC_GOOGLE_APIS_FORWARDING_RULES_PER_NETWORK Verfügbare Messwerte: compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/limit compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/usage compute.googleapis.com/quota/psc_google_apis_forwarding_rules_per_vpc_network/exceeded

Limits

Sofern nicht ausdrücklich angegeben können Limits normalerweise nicht erhöht werden.

Pro Organisation

Für Organisationen gelten die folgenden Limits.

Posten	Limit	Hinweise
Nicht zugeordnete hierarchische Firewallrichtlinien pro Organisation	50	Eine nicht zugeordnete Richtlinie ist eine Richtlinie, die in Ihrer Google Cloud-Organisation existiert, aber keinem Knoten zugeordnet ist. Es gibt keine Beschränkung für die Anzahl von Richtlinien in Ihrer Organisation, die mit Knoten verknüpft sind. Jedem Knoten kann jedoch nur eine Richtlinie zugeordnet werden. Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.
Regelattribute in einer hierarchischen Firewallrichtlinie	2000	Die Anzahl der Regelattribute in allen Regeln in einer hierarchischen Firewallrichtlinie. Die Anzahl der Regeln spielt dabei keine Rolle. Es zählt nur die Gesamtzahl der Attribute in allen Regeln einer Richtlinie. Ein Attribut einer Regel ist ein IP-Bereich, ein Protokoll, ein Port oder ein Portbereich, ein Zieldienstkonto oder eine Zielressource. Beispiele: Bei einer Regel, die einen Quell-IP-Bereich für 10.100.0.1/32 und Zielports von tcp:5000-6000 festlegt, zählen drei Attribute: ein Attribut für den IP-Bereich, eines für das Protokoll und eines für den Portbereich. Eine Regel, die Quellbereiche von 10.100.0.1/32 und 10.100.1.1/32 sowie Zielprotokolle und Ports von tcp:80, tcp:443, udp:4000-5000 und icmp angibt, zählt als neun: jeweils einen für die beiden IP-Bereiche und je einen für die vier Protokolle und jeweils einen für die drei Ports oder Portbereiche. Hier erfahren Sie, wie Sie die Attributanzahl Ihrer Richtlinie abrufen können. Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.

Limits für freigegebene VPC-Projekte

Die folgenden Limits gelten für freigegebene VPC-Projekte.

Posten	Limit	Hinweise
Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können	1.000	Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.
Anzahl der freigegebenen VPC-Hostprojekte in einer Organisation	100	Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.
Anzahl der Hostprojekte, an die ein Dienstprojekt angehängt werden kann	1	Dieses Limit kann nicht erhöht werden.

Pro Netzwerk

Die folgenden Limits gelten für VPC-Netzwerke. Diese Limits werden intern mithilfe von Kontingenten durchgesetzt. Wenn Limits pro Netzwerk überschritten werden, werden Fehler vom Typ QUOTA_EXCEEDED mit internen Kontingentnamen angezeigt.

Posten	Limit	Hinweise
Subnetz-IP-Bereiche
Primäre IP-Bereiche pro Subnetz	1	Jedes Subnetz muss genau einen primären IP-Bereich (CIDR-Block) haben. Dieser Bereich wird für primäre interne IP-Adressen der VM, Alias-IP-Bereiche der VM und die IP-Adressen interner Load-Balancer verwendet. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von sekundären IP-Bereichen pro Subnetz	30	Sie können optional bis zu 30 sekundäre CIDR-Blocks pro Subnetz definieren. Diese sekundären IP-Bereiche können nur für Alias-IP-Bereiche verwendet werden. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Quelltags pro Firewallregel	30	Die maximale Anzahl von Netzwerktags, die Sie beim Erstellen einer Firewallregel für eingehenden Traffic als Quelltags festlegen können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Zieltags pro Firewallregel	70	Die maximale Anzahl von Netzwerktags, die Sie beim Erstellen einer Firewallregel für eingehenden Traffic als Zieltags angeben können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Quelldienstkonten pro Firewallregel	10	Die maximale Anzahl von Quelldienstkonten, die Sie beim Erstellen einer Firewallregel für eingehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Zieldienstkonten pro Firewallregel	10	Die maximale Anzahl von Zieldienstkonten, die Sie beim Erstellen einer Firewallregel für eingehenden oder ausgehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Quellbereichen pro Firewallregel	256	Die maximale Anzahl von Quell-IP-Bereichen, die Sie beim Erstellen einer Firewallregel für eingehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Zielbereichen pro Firewallregel	256	Die maximale Anzahl von Ziel-IP-Bereichen, die Sie beim Erstellen einer Firewallregel für ausgehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden.

Limits für VPC-Netzwerk-Peering

Die folgenden Limits betreffen VPC-Netzwerke, die über VPC-Netzwerk-Peering verbunden sind. Die Limits gelten für eine Peering-Gruppe, die aus einer Reihe von VPC-Netzwerken besteht, die direkt miteinander verbunden sind. Aus der Sicht eines VPC-Netzwerks gehören dieses und alle seine Peer-Netzwerke einer Peering-Gruppe an. Die Peers von Peer-Netzwerken gehören nicht dazu.

Die Limits können in bestimmten Fällen erhöht werden. Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie Fragen zur Erhöhung haben.

Posten	Limit	Hinweise
Peering-Gruppe
Maximale Anzahl von Verbindungen zu einem VPC-Netzwerk	25	Die maximale Anzahl von Netzwerken, die sich per VPC-Netzwerk-Peering mit einem bestimmten VPC-Netzwerk verbinden können.
Maximale Anzahl von Subnetzrouten in einer Peering-Gruppe	Keine separate Beschränkung	Die Anzahl der Subnetzrouten, die ausgetauscht werden können, ist durch die Maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen pro Peering-Gruppe beschränkt, die weiter unten in diesem Dokument beschrieben werden.
Maximale Anzahl der statischen Routen in einer Peering-Gruppe	300	Die maximale Anzahl statischer Routen, die beim Importieren und Exportieren von benutzerdefinierten Routen zwischen Netzwerken in einer Peering-Gruppe ausgetauscht werden können. Google Cloud verhindert, dass Sie eine Peering-Verbindung zu einem Netzwerk herstellen, wenn dies dazu führen würde, dass dieses Limit von der Peering-Gruppe überschritten wird.
Maximale Anzahl der dynamischen Routen in einer Peering-Gruppe	300	Die maximale Anzahl von dynamischen Routen, die Cloud Router beim Importieren und Exportieren von benutzerdefinierten Routen auf alle Netzwerke einer Peering-Gruppe anwenden können. Wenn dieses Limit überschritten wird, passt Google Cloud den Import dynamischer Routen für ein bestimmtes Netzwerk an: Importierte dynamische Routen werden von Google Cloud aus Peering-Netzwerken entfernt. Google Cloud verwendet einen internen Algorithmus zum Löschen dynamischer Routen. Das bedeutet, dass nicht nur die kürzlich hinzugefügten Routen von Google Cloud gelöscht werden, sondern möglicherweise auch ältere Routen. Eine Vorhersage, welche importierten dynamischen Routen gelöscht werden, ist nicht möglich. Stattdessen sollten Sie die Anzahl der dynamischen Routen in der Peering-Gruppe reduzieren. Da sie Cloud Router-Limits unterliegen, werden dynamische Routen, die von Cloud Routern im lokalen Netzwerk erlernt werden, von Google Cloud niemals gelöscht. Wenn eine Peering-Verbindung zur Überschreitung dieses Limits führt, erhalten Sie von Google Cloud keine Warnmeldung und werden nicht daran gehindert, die Peering-Verbindung zu erstellen.
Instanzen
Maximale Anzahl von VM-Instanzen	15.000 pro Netzwerk 15.500 pro Peering-Gruppe	Mit Google Cloud können Sie eine neue Instanz in einem bestimmten VPC-Netzwerk erstellen, wenn Folgendes zutrifft: Sie haben die von diesem Limit festgelegte Anzahl pro Netzwerk nicht überschritten. Sie haben die von diesem Limit festgelegte Anzahl pro Peering-Gruppe nicht überschritten. Beispiele finden Sie unter VPC-Netzwerk-Peering und maximale VM-Anzahl. Fehlercode für Limitüberschreitung: INSTANCES_PER_NETWORK_WITH_PEERING_LIMITS_EXCEEDED
Subnetz-IP-Bereiche
Maximale Anzahl von (primären und sekundären) Subnetz-IP-Bereichen	400	Die maximale Anzahl von primären und sekundären Subnetz-IP-Bereichen, die Subnetzen in allen Netzwerken einer Peering-Gruppe zugewiesen werden können. Fehlercode für Limitüberschreitung: SUBNET_RANGES_PER_NETWORK_LIMITS_EXCEEDED_PEERING
Internes Load-Balancing
Maximale Anzahl von Weiterleitungsregeln für: Internes TCP/UDP-Load-Balancing Internes HTTP(S)-Load-Balancing	75 pro Netzwerk 175 pro Peering-Gruppe	Sie können neue regionale interne Weiterleitungsregeln für das interne Load-Balancing erstellen, wenn die folgenden Bedingungen erfüllt sind: Sie haben die von diesem Kontigent festgelegte Anzahl pro Netzwerk nicht überschritten. Beim internen Load-Balancing liegt die Anzahl der internen Weiterleitungsregeln unter der tatsächlichen Anzahl der Weiterleitungsregeln in der Peering-Gruppe. Die Berechnung der tatsächlichen Anzahl wird unter VPC-Netzwerk-Peering und interne Weiterleitungsregeln beschrieben. Fehlercode für Limitüberschreitung: INTERNAL_FORWARDING_RULES_WITH_PEERING_LIMITS_EXCEEDED
Protokollweiterleitung
Maximale Anzahl von Weiterleitungsregeln für die interne Protokollweiterleitung	50 pro Netzwerk 100 pro Peering-Gruppe	Sie können neue regionale interne Weiterleitungsregeln für die Protokollweiterleitung erstellen, wenn die folgenden Bedingungen erfüllt sind: Sie haben die von diesem Kontigent festgelegte Anzahl pro Netzwerk nicht überschritten. Die Anzahl der internen Weiterleitungsregeln für die Protokollweiterleitung in der Peering-Gruppe liegt unter der tatsächlichen Anzahl der Weiterleitungsregeln in der Peering-Gruppe. Die Berechnung der tatsächlichen Anzahl wird unter VPC-Netzwerk-Peering und interne Weiterleitungsregeln beschrieben. Fehlercode für Limitüberschreitung: INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_LIMITS_EXCEEDED_PEERING
Maximale Anzahl zugewiesener Alias-IP-Bereiche in einer Peering-Gruppe	15.000	Ein Alias-IP-Bereich ist entweder eine einzelne IP-Adresse (/32) oder ein CIDR-Block (z. B. /24 oder /16) mit Zuweisung zur Netzwerkschnittstelle einer VM. Alias-IP-Adressen können aus den primären oder den sekundären IP-Bereichen eines Subnetzes stammen. Für dieses Limit berücksichtigt Google Cloud die Größe der Netzmaske des Bereichs nicht. Es wird nur die Anzahl der Alias-IP-Bereiche gezählt, die allen VMs im Netzwerk zugewiesen sind. Zusätzlich zu diesem Kontingent gibt es für die Anzahl der Alias-IP-Bereiche je Netzwerkschnittstelle ein Limit pro VM. Fehlercode für Limitüberschreitung: ALIASES_PER_NETWORK_PEERING_LIMITS_EXCEEDED

VPC-Netzwerk-Peering und maximale VM-Anzahl

Die Netzwerke in einer Peering-Gruppe können bis zu 15.500 VM-Instanzen haben. Nehmen wir beispielsweise an, das Netzwerk network-b ist durch Peering mit zwei anderen Netzwerken verbunden, network-a und network-c:

• Wenn network-b 5.000 VMs hat, können Sie in network-a und network-c zusammen höchstens 10.500 VMs erstellen.
• Wenn network-b 500 VMs hat, können Sie in network-a und network-c zusammen höchstens 15.000 VMs erstellen.

VPC-Netzwerk-Peering und interne Weiterleitungsregeln

Aus Sicht eines bestimmten VPC-Netzwerks berechnet Google Cloud die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe anhand der folgenden Methode:

• Schritt 1: Für das Netzwerk wird das höhere der zwei folgenden Limits ermittelt:

  • Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer des jeweiligen Netzwerks
  • Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe

• Schritt 2: Für die restlichen Netzwerke in der Peering-Gruppe wird das höhere der folgenden beiden Limits ermittelt:

  • Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer im Peer-Netzwerk
  • Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe

• Schritt 3: Aus der in Schritt 2 erstellten Liste wird der niedrigste Wert ermittelt.

• Schritt 4: Von den in Schritt 1 und Schritt 3 ermittelten Zahlen wird die größere genommen. Diese Anzahl ist die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer, die aus Sicht des jeweiligen Netzwerks in der Peering-Gruppe erstellt werden können.

Angenommen, Sie haben die vier VPC-Netzwerke network-a, network-b, network-c und network-d:

• network-a ist mit network-b verbunden und network-b mit network-a.
• network-a ist mit network-c verbunden und network-c mit network-a.
• network-c ist mit network-d verbunden und network-d mit network-c.

Für jedes Netzwerk gelten die folgenden Limits:

Netzwerk	Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer im jeweiligen Netzwerk	Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe
network-a	160	150
network-b	75	80
network-c	75	75
network-d	75	95

Aus Sicht der einzelnen VPC-Netzwerke berechnet Google Cloud die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in dieser Peering-Gruppe:

• Aus Sicht von network-a umfasst die Peering-Gruppe network-a, network-b und network-c. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:

  1. In network-a: max(160,150) = 160
  2. In den restlichen Peer-Netzwerken:
     • network-b: max(75,80) = 80
     • network-c: max(75,75) = 75
  3. min(80,75) = 75
  4. max(160,75) = 160
     • Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von network-a: 160

• Aus Sicht von network-b umfasst die Peering-Gruppe network-b und network-a. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:

  1. In network-b: max(75,80) = 80
  2. In den restlichen Peer-Netzwerken:
     • network-a: max(160,150) = 160
  3. min(160) = 160
  4. max(80,160) = 160
     • Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von network-b: 160

• Aus Sicht von network-c umfasst die Peering-Gruppe network-c, network-a und network-d. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:

  1. In network-c: max(75,75) = 75
  2. In den restlichen Peer-Netzwerken:
     • network-a: max(160,150) = 160
     • network-d: max(75,95) = 95
  3. min(160,95) = 95
  4. max(75,95) = 95
     • Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von network-c: 95

• Aus Sicht von network-d umfasst die Peering-Gruppe network-d und network-c. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:

  1. In network-d: max(75,95) = 95
  2. In den restlichen Peer-Netzwerken:
     • network-c: max(75,75) = 75
  3. min(75) = 75
  4. max(95,75) = 95
     • Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von network-d: 95

Pro Instanz

Die folgenden Limits gelten für VM-Instanzen. Wenn nichts anderes angegeben ist, können diese Limits nicht erhöht werden. Informationen zu Kontingenten für VMs finden Sie unter Ressourcenkontingente.

Posten	Limit	Hinweise
Maximale Übertragungseinheit (MTU)	1.460 oder 1.500 Byte, je nach VPC-Konfiguration	Bei Instanzen mit größeren MTUs können bei der Übertragung Pakete verloren gehen. Sie können diesen MTU-Wert nicht erhöhen.
Maximale Anzahl von Netzwerkschnittstellen	8	Netzwerkschnittstellen werden bei der Instanzerstellung definiert und können später nicht durch Bearbeitung der Instanz geändert werden.
Maximale Anzahl von Alias-IP-Bereichen pro Netzwerkschnittstelle	10	Die Anzahl der Alias-IP-Bereiche, die Sie einer Netzwerkschnittstelle zuweisen können, solange das Kontingent für die Gesamtzahl von zugewiesenen Alias-IP-Bereichen im VPC-Netzwerk nicht überschritten wird. Google Cloud berücksichtigt die Größe der Netzmaske des Alias-IP-Bereichs nicht. Beispiel: Ein individueller /24-Bereich ist ein einzelner Alias-IP-Bereich und ein individueller /23-Bereich ist ebenfalls ein einzelner Alias-IP-Bereich. Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an Ihr Google Cloud-Vertriebsteam.
Netzwerkschnittstellen pro VPC-Netzwerk	1	Jede Netzwerkschnittstelle muss mit einem eindeutigen VPC-Netzwerk verbunden sein. Eine Instanz kann nur eine Netzwerkschnittstelle in einem bestimmten VPC-Netzwerk haben.
Maximale Dauer inaktiver TCP-Verbindungen	10 Minuten	Inaktive TCP-Verbindungen in VPC-Netzwerken werden nach zehn Minuten automatisch beendet. Dieses Limit kann nicht geändert werden. Mithilfe von TCP-Keepalives können Sie jedoch verhindern, dass Verbindungen zu Instanzen inaktiv werden. Weitere Informationen finden Sie unter Tipps und Fehlerbehebung für Compute Engine.
Maximale Rate für ausgehenden Traffic zu einem internen IP-Adressziel	Dieser Wert ist vom Maschinentyp der VM abhängig.	Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Ausgehender Traffic zu internen IP-Adresszielen sowie unter Maschinentypen.
Maximale Rate für ausgehenden Traffic zu einem externen IP-Adressziel	Alle Datenflüsse: ca. 7 Gbit/s (Gigabit pro Sekunde) (kontinuierlich) Einzelner Datenfluss: 3 Gbit/s (kontinuierlich)	Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Ausgehender Traffic zu externen IP-Adresszielen.
Maximale Rate für eingehenden Traffic zu einem internen IP-Adressziel	Kein künstliches Limit	Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Eingehender Traffic zu internen IP-Adresszielen.
Maximale Rate für eingehenden Traffic zu einem externen IP-Adressziel	Maximal 20 Gbit/s Maximal 1.800.000 Pakete pro Sekunde	Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Eingehender Traffic zu externen IP-Adresszielen.

Beschränkungen beim Logging von Verbindungen

Die maximale Anzahl von Verbindungen, die pro VM-Instanz protokolliert werden können, hängt vom Maschinentyp ab. Die Beschränkungen beim Logging von Verbindungen werden als die maximale Anzahl von Verbindungen angegeben, die in einem Intervall von fünf Sekunden erfasst werden kann.

Wichtig: Logeinträge für Firewalls erfolgen auf Best-Effort-Basis gemäß der folgenden Tabelle. In Phasen mit viel Traffic kann es vorkommen, dass Einträge nicht im Log erfasst werden, auch wenn die maximale Anzahl der erfassten Verbindungen für einen Maschinentyp noch nicht erreicht ist.

Maschinentyp der Instanz	Maximale Anzahl der in einem 5-Sekunden-Intervall protokollierten Verbindungen
f1-micro	100 Verbindungen
g1-small	250 Verbindungen
Maschinentypen mit 1–8 vCPUs	500 Verbindungen pro vCPU
Maschinentypen mit mehr als 8 vCPUs	4.000 (500×8) Verbindungen

Hybridkonnektivität

Über die folgenden Links finden Sie Kontingente und Limits für Cloud VPN, Cloud Interconnect und Cloud Router.

• Kontingente und Limits für Cloud VPN
• Kontingente und Limits für Cloud Interconnect
• Kontingente und Limits für Cloud Router

Verwalten von Kontingenten

Virtual Private Cloud legt aus verschiedenen Gründen Kontingente für die Ressourcennutzung fest. Diese schützen unter anderem die gesamte Google Cloud-Community vor unerwarteten Auslastungsspitzen. Außerdem unterstützen Kontingente Nutzer, die Google Cloud mit der kostenlosen Stufe prüfen, dabei, im Rahmen der Testversion zu verbleiben.

Alle Projekte beginnen mit den gleichen Kontingenten, die Sie ändern können, indem Sie zusätzliche Kontingente anfordern. Einige Kontingente können entsprechend Ihrer Nutzung eines Produkts automatisch erhöht werden.

Berechtigungen

Zur Anzeige von Kontingenten oder zur Anforderung von Kontingenterhöhungen benötigen IAM-Mitglieder (Identity Access Management, Identitäts- und Zugriffsverwaltung) eine der folgenden Rollen:

Aufgabe	Erforderliche Rolle
Kontingente für ein Projekt prüfen	Beispiele: Rolle „Projektinhaber” (roles/owner) Rolle „Projektbearbeiter” (roles/editor) Rolle „Kontingentbetrachter” (roles/servicemanagement.quotaViewer)
Kontingente ändern, zusätzliche Kontingente anfordern	Beispiele: Rolle „Projektinhaber” (roles/owner) Rolle „Projektbearbeiter” (roles/editor) Rolle „Kontingentadministrator” (roles/servicemanagement.quotaAdmin) Eine benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Console

1. Wechseln Sie in der Cloud Console zur Seite Kontingente.

   Kontingente aufrufen

2. Mit dem Feld Tabelle filtern können Sie nach den zu aktualisierenden Kontingenten suchen. Wenn Sie den Namen des Kontingents nicht kennen, verwenden Sie stattdessen die Links auf dieser Seite.

gcloud

Führen Sie mit dem gcloud-Befehlszeilentool den folgenden Befehl aus, um Ihre Kontingente zu prüfen. Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID:

      gcloud compute project-info describe --project PROJECT_ID
    

Mit dem folgenden Befehl prüfen Sie das genutzte Kontingent in einer Region:

      gcloud compute regions describe example-region
    

Fehler beim Überschreiten Ihres Kontingents

Wenn Sie ein Kontingent mit einem gcloud-Befehl überschreiten, gibt gcloud eine quota exceeded-Fehlermeldung aus und liefert den Exit-Code 1.

Wenn Sie ein Kontingent mit einer API-Anfrage überschreiten, liefert Google Cloud folgenden HTTP-Statuscode: HTTP 413 Request Entity Too Large.

Weitere Kontingente anfordern

Auf der Seite Kontingente der Cloud Console können Sie weitere Kontingente anfordern. Die Bearbeitung von Kontingentanforderungen dauert 24 bis 48 Stunden.

Console

1. Wechseln Sie in der Cloud Console zur Seite Kontingente.

   Kontingente aufrufen

2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
3. Klicken Sie oben auf der Seite auf Kontingente bearbeiten.
4. Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
5. Geben Sie Ihre Kontingentanforderung ein und klicken Sie auf Fertig.
6. Senden Sie die Anfrage.

Ressourcenverfügbarkeit

Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, vorausgesetzt, der Ressourcentyp ist verfügbar. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Auch wenn Sie ein Kontingent haben, können Sie keine neue Ressource erstellen, wenn sie nicht verfügbar ist.

Beispiel: Ihr Kontingent zum Erstellen einer neuen regionalen, externen IP-Adresse in der Region us-central1 ist ausreichend. Das ist jedoch nicht möglich, wenn in dieser Region keine externen IP-Adressen verfügbar sind. Die Verfügbarkeit von zonalen Ressourcen kann sich auch auf Ihre Fähigkeit auswirken, eine neue Ressource zu erstellen.

Es kommt nur selten vor, dass Ressourcen in einer gesamten Region nicht verfügbar sind. Ressourcen innerhalb einer Zone können jedoch vorübergehend aufgebraucht sein, was sich normalerweise nicht auf das Service Level Agreement (SLA) für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden SLA für die Ressource.