Kontingente und Limits
In diesem Dokument sind die Kontingente und Limits für VPC-Netzwerke (Virtual Private Cloud) aufgeführt.
Ein Kontingent schränkt ein, wie viel von einer bestimmten gemeinsam genutzten Google Cloud-Ressource Ihr Cloud-Projekt nutzen kann, einschließlich Hardware, Software und Netzwerkkomponenten.
Kontingente sind Teil eines Systems, das Folgendes tut:
- Ihre Nutzung oder Ihren Verbrauch von Google Cloud-Produkten und -Diensten überwachen.
- Ihren Verbrauch dieser Ressourcen einschränken, um u. a. für Fairness zu sorgen und Nutzungsspitzen zu reduzieren.
- Konfigurationen verwalten, die automatisch vorgeschriebene Einschränkungen erzwingen.
- Eine Möglichkeit bietet, das Kontingent zu ändern oder anzufordern.
Wenn ein Kontingent überschritten wird, blockiert das System in den meisten Fällen den Zugriff auf die entsprechende Google-Ressource und die Aufgabe, die Sie ausführen möchten, schlägt fehl. In den meisten Fällen gelten Kontingente für jedes Cloud-Projekt und werden von allen Anwendungen und IP-Adressen geteilt, die dieses Cloud-Projekt verwenden.
Für VPC-Ressourcen gelten außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn etwas anderes angegeben ist.
Kontingente
Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern.
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 Google 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 |
---|---|
Netzwerkbandbreite | |
Bandbreite für ausgehenden Internettraffic | Bandbreite für ausgehenden Internettraffic pro Region von Google Cloud-VMs in allen VPC-Netzwerken des Projekts. |
Shared VPC | |
Projektübergreifende Netzwerkdienste für Projekte | Anzahl der Dienstprojekte einer freigegebenen VPC, die an ein freigegebenes VPC-Hostprojekt angehängt werden können. Zusätzlich zu diesem Kontingent finden Sie weitere Informationen unter Limits für freigegebene VPC-Projekte. |
Allgemein | |
Netzwerke | Umfasst das Netzwerk default , das Sie entfernen können. |
Routen | Zählt benutzerdefinierte statische Routen, die in allen VPC-Netzwerken im Projekt definiert sind. Folgende Routentypen werden dabei nicht berücksichtigt:
|
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. |
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. |
Firewalls | |
Firewallregeln | Die Anzahl der Firewallregeln, die Sie für alle VPC-Netzwerke in Ihrem Projekt erstellen können. |
Anzahl der Regelattribute pro Firewallrichtlinie | Die maximale Anzahl von Firewallregeln, die Sie einer Firewallrichtlinie zuweisen können. Wenn sich in demselben Projekt mehrere VPC-Netzwerke befinden, wird die aggregierte Regel für jede Richtlinie für alle Netzwerke berücksichtigt, die dasselbe Projekt nutzen. |
Globale Adressgruppen pro Projekt | Die maximale Anzahl globaler Adressgruppen, die Sie in einem Projekt definieren können. |
Regionale Adressgruppen pro Projekt und Region | Die maximale Anzahl regionaler Adressgruppen, die Sie für ein Projekt in einer Region definieren können. |
Adressgruppen pro Projekt | Die maximale Anzahl von Adressgruppen, die Sie in einem Projekt unabhängig vom Standort definieren können (global oder regional). |
Netzwerk-Firewallrichtlinien | Die maximale Anzahl von Netzwerk-Firewallrichtlinien, die mindestens einem VPC-Netzwerk in einem Projekt zugewiesen sind. |
Regionale Netzwerk-Firewallrichtlinien | Die maximale Anzahl von regionalen Netzwerk-Firewallrichtlinien, die der entsprechenden Region von mindestens einem VPC-Netzwerk zugewiesen sind. |
Weiterleitungsregeln | |
Weiterleitungsregeln | Dieses Kontingent gilt nur für Weiterleitungsregeln für die globalen externen HTTP(S)-Load-Balancer (klassisch), externes SSL-Proxy-Load-Balancing, externes TCP-Proxy-Load-Balancing und klassische VPN-Gateways. Weitere Beispiele für Weiterleitungsregeln finden Sie in den folgenden Zeilen. |
Globale externe Weiterleitungsregeln für den HTTP(S)-Load-Balancer | Die maximale Anzahl an globalen externen HTTP(S)-Load-Balancer-Weiterleitungsregeln, die Sie in Ihrem Projekt erstellen können. |
Regionale externe HTTP(S)-Load-Balancer-Weiterleitungsregeln | Die maximale Anzahl von regionalen externen HTTP(S)-Load-Balancer-Weiterleitungsregeln, die Sie in jeder Region in Ihrem Projekt erstellen können. |
Weiterleitungsregeln für externen TCP/UDP-Netzwerk-Load-Balancer | 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 |
Traffic Director-Weiterleitungsregeln | 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. |
IP-Adressen und BYOIP | |
Interne IP-Adressen | Die Anzahl der regionalen statischen internen IP-Adressen, die Sie in den einzelnen Regionen für Ihr Projekt reservieren können. Dieses Kontingent gilt für die Gesamtheit interner IPv4- und IPv6-Adressen. |
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. |
Verwendete IP-Adressen | Die Anzahl der statischen und sitzungsspezifischen regionalen externen IP-Adressen, die Sie in Ihrem Projekt gleichzeitig verwenden können. |
global verwendete IP-Adressen | Die Anzahl der statischen und sitzungsspezifischen globalen externen IP-Adressen, die Sie gleichzeitig in Ihrem Projekt verwenden können. |
Statische BYOIP-IP-Adressen | Die Anzahl der regionalen externen IP-Adressen , die Sie in jeder Region in Ihrem Projekt reservieren können. |
Statische BYOIP-IP-Adressen (global) | Die Anzahl der eigenen globalen externen IP-Adressen , die Sie in Ihrem Projekt reservieren können. |
Öffentliche Beworbene Präfixe | Die Anzahl der öffentlich beworbenen Präfixe (PAPs), die Sie in Ihrem Projekt erstellen können. |
Regionale öffentlich delegierte Präfixe | Die Anzahl der regionalen öffentlich delegierten Präfixe (PDPs), die Sie in jeder Region in Ihrem Projekt reservieren können. |
Globale öffentliche delegierte Präfixe | Die Anzahl der globalen öffentlich delegierten Präfixe (PDPs), die Sie in Ihrem Projekt reservieren können. |
Private Service Connect | |
Interne LB-Weiterleitungsregeln von Private Service Connect PSC | Die maximale Anzahl von Private Service Connect-Weiterleitungsregeln (Endpunkten), die ein Dienstnutzer erstellen kann, um eine Verbindung zu Erstellerdiensten herzustellen. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Dienstanhänge | Die maximale Anzahl von Private Service Connect-Dienstanhängen, die ein Dienstersteller erstellen kann. Dieses Kontingent gilt pro Region und Projekt. Kontingentname: |
Pro Netzwerk
In dieser Tabelle sind wichtige Netzwerkkontingente aufgeführt. Informationen zu anderen Kontingenten finden Sie in der Google Cloud Console auf der Seite Kontingente.
Informationen zum Monitoring der verfügbaren Messwerte mit Cloud Monitoring finden Sie unter Kontingentmesswerte verwenden.
Kontingent | Beschreibung |
---|---|
Instanzen | |
VM-Instanzen pro Netzwerk | Dieses Kontingent 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: Verfügbare Messwerte:
|
Maximale Anzahl von VM-Instanzen pro Subnetz | Keine separate Einschränkung. |
IP-Aliasse pro VPC-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: Verfügbare Messwerte:
|
Subnetz-IP-Bereiche | |
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: Verfügbare Messwerte:
|
Weiterleitungsregeln | |
Weiterleitungsregeln für internes TCP/UDP-Load-Balancing pro VPC-Netzwerk | Die maximale Anzahl von Weiterleitungsregeln für internes TCP-/UDP-Load-Balancing. Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln für internes TCP/UDP-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: Verfügbare Messwerte:
|
Interne Protokollweiterleitungsregeln pro VPC-Netzwerk | Die maximale Anzahl von Weiterleitungsregeln für die interne Protokollweiterleitung. Dieses Kontingent 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: Verfügbare Messwerte:
|
Interne HTTP(S)-Load-Balancing-Weiterleitungsregeln pro VPC-Netzwerk | Die maximale Anzahl an Weiterleitungsregeln für internes HTTP(S)-Load-Balancing. Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln für internes HTTP(S)-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: Verfügbare Messwerte:
|
Private Service Connect | |
Private Service Connect-Weiterleitungsregeln für Google APIs | Die maximale Anzahl von Private Service Connect-Weiterleitungsregeln (Endpunkten), die für den Zugriff auf Google APIs verwendet werden können. Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln, die in allen Regionen für den Zugriff auf Google APIs verwendet werden. Dieses Kontingent kann nicht erhöht werden. Hier erhalten Sie weitere Informationen darüber, wie viele globale Internetadressen Sie erstellen können. Kontingentname: Verfügbare Messwerte:
|
Private Service Connect-Weiterleitungsregeln für Nutzer pro VPC-Netzwerk des Diensterstellers | Die maximale Anzahl von Private Service Connect-Weiterleitungsregeln (Endpunkten), die für den Zugriff auf einen Dienst im VPC-Netzwerk eines Diensterstellers verwendet werden können. Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln, die von allen Nutzern erstellt wurden, die auf Dienste in allen Regionen des Dienstersteller-VPC-Netzwerks zugreifen. Dieses Kontingent kann nicht erhöht werden. Kontingentname: Verfügbare Messwerte:
|
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. Um eine Aktualisierung dieses Limits anzufordern, reichen Sie eine Supportanfrage ein. |
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:
Hier erfahren Sie, wie Sie die Attributanzahl Ihrer Richtlinie abrufen können. Um eine Aktualisierung dieses Limits anzufordern, reichen Sie eine Supportanfrage ein. |
Globale Adressgruppen pro Organisation | 30 | Die maximale Anzahl globaler Adressgruppen, die Sie pro Organisation erstellen können. |
Regionale Adressgruppen pro Organisation und Region | 30 | Die maximale Anzahl regionaler Adressgruppen, die Sie pro Organisation in einer Region erstellen können. |
Organisationsadressgruppen | 30 | Die maximale Anzahl von Adressgruppen, die Sie pro Organisation in einer Region unabhängig vom Standort erstellen können (global oder regional). |
Limits für freigegebene VPC-Projekte
Die Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können, ist ein konfigurierbares Projektkontingent. Zusätzlich gelten die folgenden Limits für freigegebene VPCs.
Posten | Limit | Hinweise |
---|---|---|
Anzahl der freigegebenen VPC-Hostprojekte in einer Organisation | 100 | Um eine Aktualisierung dieses Limits anzufordern, reichen Sie eine Supportanfrage ein. |
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. |
Routen | ||
Maximale Anzahl Netzwerk-Tags pro Route | 256 | Die maximale Anzahl an Netzwerktags, die Sie mit einer statischen Route verknüpfen können. Dieses Limit kann nicht erhöht werden. |
Firewallregeln | ||
Maximale Anzahl von Quelltags pro Firewallregel | 256 | 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 | 256 | 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 | 5.000 | Die maximale Anzahl von Quell-IP-Bereichen, die Sie beim Erstellen einer Firewallregel angeben können. Dieses Limit kann nicht erhöht werden. |
Maximale Anzahl von Zielbereichen pro Firewallregel | 5.000 | Die maximale Anzahl von Ziel-IP-Bereichen, die Sie beim Erstellen einer Firewallregel angeben können. Dieses Limit kann nicht erhöht werden. |
Maximale Anzahl von Quelldomainnamen pro Firewallregel | 100 | Die maximale Anzahl von Quelldomainnamen, die Sie beim Erstellen einer Firewallregel für eingehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden. |
Maximale Anzahl von Zieldomainnamen pro Firewallregel | 100 | Die maximale Anzahl von Zieldomainnamen, die Sie beim Erstellen einer Firewallregel für ausgehenden Traffic angeben können. Dieses Limit kann nicht erhöht werden. |
Maximale Anzahl von Quelladressgruppen pro Firewallregel | 10 | Die maximale Anzahl von Quelladressgruppen, die Sie beim Erstellen einer Firewallregel angeben können. Dieses Limit kann nicht erhöht werden. |
Maximale Anzahl von Zieladressgruppen pro Firewallregel | 10 | Die maximale Anzahl von Zieladressgruppen, die Sie beim Erstellen einer Firewallregel 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. Weitere Informationen zum Erhöhen dieser Limits finden Sie unter Supportfall einreichen.
Posten | Limit für Peering-Gruppe | 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. Dieses Limit gilt für die Zusammenfassung der dynamischen Routen von IPv4 und IPv6. Wenn dieses Limit überschritten wird, passt Google Cloud den Import dynamischer Routen für ein bestimmtes Netzwerk an:
|
Instanzen | ||
Maximale Anzahl von VM-Instanzen in einer Peering-Gruppe | 15.500 | Mit Google Cloud können Sie eine neue Instanz in einem bestimmten VPC-Netzwerk erstellen, solange beide der folgenden Bedingungen erfüllt sind:
Fehlercode für Limitüberschreitung: |
Maximale Anzahl zugewiesener Alias-IP-Bereiche in einer Peering-Gruppe | 15.500 | 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: |
Subnetz-IP-Bereiche | ||
Maximale Anzahl von (primären und sekundären) Subnetz-IP-Adressbereichen in einer Peering-Gruppe | 400 | Mit Google Cloud können Sie einen neuen Subnetzbereich in einem bestimmten VPC-Netzwerk erstellen, solange beide der folgenden Bedingungen erfüllt sind:
Fehlercode für Limitüberschreitung: |
Internes Load-Balancing | ||
Maximale Anzahl von Weiterleitungsregeln für internes TCP-/UDP-Load-Balancing pro Peering-Gruppe |
500 | Sie können neue regionale interne Weiterleitungsregeln für das interne TCP/UDP-Load-Balancing erstellen, wenn die beiden folgenden Bedingungen erfüllt sind:
Fehlercode für Limitüberschreitung: |
Maximale Anzahl von Weiterleitungsregeln für internes HTTP(S)-Load-Balancing pro Peering-Gruppe |
175 | Sie können neue regionale, intern verwaltete Weiterleitungsregeln für das interne HTTP(S)-Load-Balancing erstellen, wenn die beiden folgenden Bedingungen erfüllt sind:
Fehlercode für Limitüberschreitung: |
Protokollweiterleitung | ||
Maximale Anzahl von Weiterleitungsregeln für die interne Protokollweiterleitung pro Peering-Gruppe | 2.000 | Sie können neue regionale interne Weiterleitungsregeln für die Protokollweiterleitung erstellen, sofern die beiden folgenden Bedingungen erfüllt sind:
Fehlercode für Limitüberschreitung: |
Effektive Limits für VPC-Netzwerk-Peering
Die meisten Kontingente pro Netzwerk haben ein entsprechendes Limit pro Peering-Gruppe. In diesen Fällen wird das effektive Limit pro Peering-Gruppe aus dem Limit des Kontingents pro Netzwerk und dem Limit der Peering-Gruppe berechnet. In diesem Abschnitt wird diese Methode über folgende Elemente beschrieben:
- Kontingent für interne Weiterleitungsregeln pro Netzwerk
- Limit für interne Weiterleitungsregeln pro Peering-Gruppe
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 Werte ermittelt:
- Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer des jeweiligen Netzwerks
- Maximale 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 Werte ermittelt:
- Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer im Peer-Netzwerk
- Maximale 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 mitnetwork-b
verbunden undnetwork-b
mitnetwork-a
.network-a
ist mitnetwork-c
verbunden undnetwork-c
mitnetwork-a
.network-c
ist mitnetwork-d
verbunden undnetwork-d
mitnetwork-c
.
Für jedes Netzwerk gelten die folgenden Limits:
Netzwerk | Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer im jeweiligen Netzwerk | Maximale Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe |
---|---|---|
network-a |
600 | 500 |
network-b |
300 | 350 |
network-c |
300 | 300 |
network-d |
300 | 400 |
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-Gruppenetwork-a
,network-b
undnetwork-c
. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:- In
network-a
:max(600,500) = 600
- In den restlichen Peer-Netzwerken:
network-b
:max(300,350) = 350
network-c
:max(300,300) = 300
min(350,300) = 300
max(600,300) = 600
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
network-a
:600
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
- In
Aus Sicht von
network-b
umfasst die Peering-Gruppenetwork-b
undnetwork-a
. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:- In
network-b
:max(300,350) = 350
- In den restlichen Peer-Netzwerken:
network-a
:max(600,500) = 600
min(600) = 600
max(350,600) = 600
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
network-b
:600
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
- In
Aus Sicht von
network-c
umfasst die Peering-Gruppenetwork-c
,network-a
undnetwork-d
. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:- In
network-c
:max(300,300) = 300
- In den restlichen Peer-Netzwerken:
network-a
:max(600,500) = 600
network-d
:max(300,400) = 400
min(600,400) = 400
max(300,400) = 400
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
network-c
:400
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
- In
Aus Sicht von
network-d
umfasst die Peering-Gruppenetwork-d
undnetwork-c
. Die tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer in der Peering-Gruppe wird so berechnet:- In
network-d
:max(300,400) = 400
- In den restlichen Peer-Netzwerken:
network-c
:max(300,300) = 300
min(300) = 300
max(400,300) = 400
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
network-d
:400
- Tatsächliche Anzahl von Weiterleitungsregeln für die internen Load-Balancer pro Peering-Gruppe aus Sicht von
- In
Limits für IP-Adressen
Posten | Limit | Hinweise |
---|---|---|
Öffentlich delegierte Präfixe pro öffentlich beworbenem Präfix | 10 | Die Anzahl der öffentlich delegierten Präfixe (PDPs), die Sie mit einem öffentlich beworbenen Präfix (PAP) erstellen können. |
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) | Von 1.460 (Standard) oder 1.500 (Standard-Ethernet) oder bis zu 8.896 Byte (Jumbo Frames), je nach VPC-Netzwerkkonfiguration. | Bei Instanzen, deren MTU-Größe größer ist als das VPC-Netzwerk, können verworfene Pakete auftreten. Weitere Informationen finden Sie unter Maximale Übertragungseinheit. |
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 | 100 | 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 |
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) oder 25 Gbit/s mit VM-1-Netzwerkleistung 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.
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
Mit Virtual Private Cloud werden Kontingente für die Ressourcennutzung aus verschiedenen Gründen festgelegt. Kontingente schützen unter anderem die gesamte Google Cloud-Community vor unerwarteten Nutzungsspitzen. 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-Hauptkonten (Identity and Access Management) eine der folgenden Rollen:
Aufgabe | Erforderliche Rolle |
---|---|
Kontingente für ein Projekt prüfen | Beispiele:
|
Kontingente ändern, zusätzliche Kontingente anfordern | Beispiele:
|
Kontingent prüfen
Console
- Öffnen Sie in der Google Cloud Console die Seite Kontingente.
- 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 der Google Cloud CLI 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
Verwenden Sie bei den meisten Kontingenten die Google Cloud Console, um sie zu erhöhen oder zu verringern. Weitere Informationen finden Sie unter Höheres Kontingent anfordern.
Console
- Öffnen Sie in der Google Cloud Console die Seite Kontingente.
- Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
- Klicken Sie oben auf der Seite auf Kontingente bearbeiten.
- Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
- Geben Sie Ihre Kontingentanforderung ein und klicken Sie auf Fertig.
- Senden Sie die Anfrage. Die Bearbeitung von Kontingentanforderungen dauert 24 bis 48 Stunden.
Ressourcenverfügbarkeit
Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, sofern der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Selbst wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn keine verfügbar ist.
Beispiel: Sie haben noch ein ausreichendes Kontingent zum Erstellen einer neuen regionalen, externen IP-Adresse in der Region us-central1
. Dies 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 kompletten Region nicht verfügbar sind. Ressourcen innerhalb einer Zone können aber manchmal vorübergehend ausgeschöpft sein, ohne dass sich das auf das Service Level Agreement (SLA) für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden SLA für die Ressource.