VPC-Ressourcenkontingente

Kontingente und Limits

In den folgenden Abschnitten werden die Kontingente und Limits für VPC-Netzwerke beschrieben. Wenn Sie ein Kontingent ändern möchten, können Sie über die Cloud Console zusätzliche Kontingente anfordern. Limits können normalerweise nicht erhöht werden, sofern nicht ausdrücklich angegeben.

Pro Projekt

In dieser Tabelle sind wichtige globale Kontingente für VPC-Ressourcen pro Projekt aufgeführt. Weitere Kontingente finden Sie auf der Seite "Kontingente".

Element Kontingent Anmerkungen
Netzwerke Kontingente Umfasst auch das Netzwerk default, das Sie entfernen können.
Subnetze Kontingente Wird auf alle Subnetze in allen Netzwerken im Projekt angewendet.
Vom System generierte und
benutzerdefinierte statische Routen		 Kontingente Dieses Kontingent umfasst keine benutzerdefinierten dynamischen Routen, die von Cloud Router erlernt werden.
Cloud Router Kontingente Dieses Kontingent entspricht der 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 Kontingente Dieses Kontingent gilt für die Anzahl der Firewallregeln, die Sie für alle VPC-Netzwerke in Ihrem Projekt erstellen können.
Weiterleitungsregeln Kontingente Dieses Kontingent umfasst interne und externe Weiterleitungsregeln. Für interne Weiterleitungsregeln gelten andere Limits. Weitere Informationen finden Sie unter Weiterleitungsregeln für die internen Load-Balancer pro Netzwerk und Limits für VPC-Netzwerk-Peering.
Interne IP-Adressen Kontingente Dieses Kontingent entspricht der Anzahl der regionalen statischen internen IP-Adressen, die Sie in Ihrem Projekt in jeder beliebigen Region reservieren können.
Globale interne IP-Adressen Kontingente Dieses Kontingent entspricht der 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 Kontingente Dieses Kontingent entspricht der Anzahl der regionalen statischen externen IP-Adressen, die Sie in Ihrem Projekt in jeder beliebigen Region reservieren können.
Statische IP-Adressen (global) Kontingente Dieses Kontingent entspricht der Anzahl der globalen statischen externen IP-Adressen, die Sie in Ihrem Projekt reservieren können.
Richtlinien für die Paketspiegelung Kontingente Dieses Limit entspricht der Anzahl der Richtlinien für die Paketspiegelung, die Sie in Ihrem Projekt in jedem beliebigen Netzwerk und in jeder beliebigen Region erstellen können. Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.

Limits für freigegebene VPC-Projekte

Die folgenden Limits gelten für Projekte, die Teil einer freigegebenen VPC sind.

Element Limit Anmerkungen
Anzahl der Dienstprojekte, die an ein Hostprojekt angehängt werden können 1.000 Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Anzahl der freigegebenen VPC-Hostprojekte in einer Organisation 100 Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
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 können erhöht werden, sofern nicht anders angegeben. Wenden Sie sich diesbezüglich an Ihr Google Cloud-Vertriebsteam.

Element Limit Anmerkungen
Instanzen
Maximale Anzahl von VM-Instanzen pro Netzwerk 15.000 Dieses Limit kann niedriger sein, wenn Sie das Netzwerk über VPC-Netzwerk-Peering mit anderen verbinden. Weitere Informationen finden Sie unter Limits für VPC-Netzwerk-Peering.
Maximale Anzahl von VM-Instanzen pro Subnetz Keine separate Einschränkung.
Maximale Anzahl von zugewiesenen Alias-IP-Bereichen 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 nicht die Größe der Netzmaske des Bereichs. 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.
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 festlegen. 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 (primären und sekundären) Subnetz-IP-Bereichen 300 Die Gesamtzahl von primären und sekundären Subnetz-IP-Bereichen, die allen Subnetzen eines VPC-Netzwerks zugewiesen sind.
Firewallregeln
Maximale Anzahl von Quelltags pro Firewallregel 30 Dies ist die maximale Anzahl von Netzwerktags, die beim Erstellen einer Firewallregel für eingehenden Traffic als Quelltags angegeben werden können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Zieltags pro Firewallregel 70 Dies ist die maximale Anzahl von Netzwerktags, die beim Erstellen einer Firewallregel für eingehenden oder ausgehenden Traffic als Zieltags angegeben werden können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Quelldienstkonten pro Firewallregel 10 Dies ist die maximale Anzahl von Quelldienstkonten, die beim Erstellen einer Firewallregel für eingehenden Traffic angegeben werden können. Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von Zieldienstkonten pro Firewallregel 10 Dies ist die maximale Anzahl von Zieldienstkonten, die beim Erstellen einer Firewallregel für eingehenden oder ausgehenden Traffic angegeben werden können. Dieses Limit kann nicht erhöht werden.
Internes Load-Balancing
Maximale Anzahl von Weiterleitungsregeln für:
– Internes TCP/UDP-Load-Balancing
– Internes HTTP(S)-Load-Balancing		 75 Steht für die maximale Anzahl von Weiterleitungsregeln für interne Load-Balancer.

Dieses Limit 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 unter Limits für VPC-Netzwerk-Peering weitere wichtige Informationen.
Protokollweiterleitung
Maximale Anzahl von Weiterleitungsregeln für die interne Protokollweiterleitung 50 Steht für 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 unter Limits für VPC-Netzwerk-Peering weitere wichtige Informationen.

Limits für VPC-Netzwerk-Peering

Die folgenden Limits betreffen VPC-Netzwerke, die über VPC-Netzwerk-Peering verbunden sind. Jedes Limit gilt 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 dieser Limits haben.

Element Limit Anmerkungen
Peering-Gruppe
Maximale Anzahl von Verbindungen zu einem einzelnen VPC-Netzwerk 25 Dieses Limit stellt die maximale Anzahl von Netzwerken dar, 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 Per VPC-Netzwerk-Peering verbundene Netzwerke tauschen immer Subnetzrouten aus.
Maximale Anzahl der statischen Routen in einer Peering-Gruppe 300 Dieses Limit stellt die maximale Anzahl von statischen Routen dar, die beim Importieren und Exportieren von benutzerdefinierten Routen unter 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

Dieses Limit stellte die maximale Anzahl von dynamischen Routen dar, 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. Es ist nicht vorhersehbar, welche importierten dynamischen Routen gelöscht werden. Daher 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		 Sie können über Google Cloud eine neue Instanz in einem 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.
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.
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:
  • Die Gesamtzahl der Weiterleitungsregeln (nicht nur interne Weiterleitungsregeln) im Projekt des Netzwerks liegt unter dem Kontingent für Weiterleitungsregeln pro Projekt.
  • Sie haben die von diesem Limit 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.
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:
  • Die Gesamtzahl der Weiterleitungsregeln (nicht nur interne Weiterleitungsregeln) im Projekt des Netzwerks liegt unter dem Kontingent für Weiterleitungsregeln pro Projekt.
  • Sie haben die von diesem Limit 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.

VPC-Netzwerk-Peering und maximale VM-Anzahl

Die Netzwerke in einer Peering-Gruppe können bis zu 15.500 VM-Instanzen haben. Nehmen Sie zur Veranschaulichung an, dass Netzwerk network-b durch Peering mit zwei anderen Netzwerken verbunden ist, 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 zwei folgenden 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:

Netz 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
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 wie folgt 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 wie folgt 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 wie folgt 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 wie folgt 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 in Bezug auf VMs finden Sie unter Compute Engine-Kontingente.

Element Limit Anmerkungen
Maximale Übertragungseinheit (MTU) 1.460 Byte 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 an 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 Sie das Kontingent für die Gesamtzahl der zugewiesenen Alias-IP-Bereiche im VPC-Netzwerk nicht überschreiten.

Für dieses Limit berücksichtigt Google Cloud nicht die Größe der Netzmaske des Alias-IP-Bereichs. Beispiel: Ein individueller /24-Bereich ist ein einzelner Alias-IP-Bereich und ein individueller /23-Bereich ist ebenfalls ein einzelner Alias-IP-Bereich.

Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
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 Instanzen inaktiv werden. Weitere Informationen finden Sie auf der Seite Tipps und Fehlerbehebung für Compute Engine.
Maximale Rate für eingehenden Traffic zu einer internen IP-Adresse Kein künstliches Limit Eingehender Traffic von VM-Instanzen wird in Google Cloud nicht künstlich begrenzt, es sei denn der Traffic wird an eine verbundene externe IP-Adresse gesendet.

Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Bandbreite für eingehenden Traffic zu einer internen IP-Adresse.
Maximale Rate für eingehenden Traffic zu einer externen IP-Adresse maximal 20 Gbit/s
maximal 1.800.000 Pakete pro Sekunde		 Traffic, der an eine mit einer VM verbundene externe IP-Adresse gesendet wird, darf 20 Gbit/s bzw. 1.800.000 Pakete pro Sekunde nicht überschreiten, je nachdem, welches Limit zuerst erreicht wird. Diese Limits sind jedoch nicht garantiert. Die Rate für eingehenden Traffic wird auch durch andere Faktoren wie den Maschinentyp begrenzt.

Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Bandbreite für eingehenden Traffic zu einer externen IP-Adresse.
Maximale Rate ausgehender Daten Dieser Wert ist vom Maschinentyp der VM abhängig. Weitere Informationen finden Sie in den Angaben zur Netzwerkbandbreite für die einzelnen Maschinentypen. Der ausgehende Traffic ist die gesamte ausgehende Bandbreite aller Netzwerkschnittstellen einer VM. Dazu zählt auch die Datenübertragung zu nichtflüchtigem Speicher, der an die VM angeschlossen ist.

Die tatsächlichen Raten ausgehenden Traffics hängen von weiteren Faktoren ab. Der ausgehende Internet-Traffic wird in der nächsten Zeile beschrieben.
Maximale Rate für ausgehenden Traffic zu einer externen IP-Adresse Alle Datenflüsse: ca. 7 Gbit/s (kontinuierlich)
einzelner Datenfluss: 3 Gbit/s (kontinuierlich) 		Ein einzelner Datenfluss ist definiert als eindeutiges 5-Tupel aus Quell-IP-Adresse, Quellport, Ziel-IP-Adresse, Zielport und Protokoll.

Diese Rate für ausgehenden Traffic gilt für Verbindungen zu einer externen IP-Adresse, die von einer Google Cloud-Ressource verwendet wird, oder für das Senden von Traffic an das Internet.

Hybridkonnektivität

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

Überblick

Auf Virtual Private Cloud werden aus verschiedenen Gründen Kontingente für die Ressourcennutzung festgelegt. Diese schützen unter anderem die gesamte Google Cloud-Community vor unerwarteten Auslastungsspitzen. Außerdem helfen Kontingente Nutzern, die Google Cloud mit der kostenlosen Stufe testen, die Testnutzung nicht zu überschreiten.

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

Berechtigungen

Um Kontingente anzuzeigen oder Kontingenterhöhungen anzufordern, benötigen IAM-Mitglieder eine der folgenden Rollen.

Aufgabe Erforderliche Rolle
Kontingente für ein Projekt überprüfen Projektinhaber oder -bearbeiter oder Kontingentbetrachter
Kontingente ändern, zusätzliche Kontingente anfordern Projektinhaber oder -bearbeiter, Kontingentadministrator oder benutzerdefinierte Rolle mit der Berechtigung serviceusage.quotas.update

Kontingent prüfen

Wechseln Sie in der Cloud Console zur Seite Kontingente.

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 mit einem gcloud-Befehl ein Kontingent überschreiten, gibt gcloud eine quota exceeded-Fehlermeldung aus und liefert den Exit-Code 1.

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

Weitere Kontingente anfordern

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

  1. Rufen Sie die Seite Kontingente auf.

    Zur Seite "Kontingente"

  2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten.
  3. Klicken Sie oben auf der Seite auf die Schaltfläche 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 Weiter.
  6. Senden Sie die Anfrage.

Ressourcenverfügbarkeit

Jedes Kontingent stellt die maximale Anzahl an Ressourcen eines bestimmten Typs dar, die Sie erstellen können, wenn der Ressourcentyp verfügbar ist. Beachten Sie, dass Kontingente die Verfügbarkeit von Ressourcen nicht garantieren. Auch wenn Sie ein verfügbares Kontingent haben, können Sie keine neue Ressource erstellen, wenn diese nicht verfügbar ist. Beispiel: Sie haben noch ein Kontingent zum Erstellen neuer externer IP-Adressen in us-central1, es sind jedoch keine IP-Adressen mehr verfügbar. 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 in einer Zone können jedoch vorübergehend erschöpft sein, was sich normalerweise nicht auf das SLA für den Ressourcentyp auswirkt. Weitere Informationen finden Sie im entsprechenden Service Level Agreement (SLA) für die jeweilige Ressource.