Kontingente und Limits

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Dokument sind die Kontingente und Limits für Cloud Load Balancing aufgeführt.

Informationen zum Ändern eines Kontingents finden Sie unter Weitere Kontingente anfordern.

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 Cloud Load Balancing-Ressourcen gibt es außerdem Limits. Diese Limits stehen nicht im Zusammenhang mit dem Kontingentsystem. Limits können nur geändert werden, wenn dies angegeben ist.

Weiterleitungsregeln

Posten Kontingente und Limits Hinweise
Weiterleitungsregeln Kontingent

Dieses Kontingent gilt für Weiterleitungsregeln für die globalen externen HTTP(S)-Load-Balancer (klassisch), externen SSL-Proxy-Load-Balancer, externen TCP-Proxy-Load-Balancer 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 Kontingent

Die maximale Anzahl an globalen externen HTTP(S)-Load-Balancer-Weiterleitungsregeln, die Sie in Ihrem Projekt erstellen können.

Kontingentname: GLOBAL_EXTERNAL_MANAGED_FORWARDING_RULES

Regionale externe HTTP(S)-Load-Balancer-Weiterleitungsregeln Kontingent

Die maximale Anzahl von regionalen externen HTTP(S)-Load-Balancer-Weiterleitungsregeln, die Sie in jeder Region in Ihrem Projekt erstellen können.

Kontingentname: EXTERNAL_MANAGED_FORWARDING_RULES

Weiterleitungsregeln für externes TCP/UDP-Netzwerk-Load-Balancing Kontingent Weiterleitungsregeln für die Verwendung durch externe TCP/UDP-Netzwerk-Load-Balancer (sowohl Back-End-Dienst als auch Zielpoolarchitektur)
Weiterleitungsregeln für externe Protokolle Kontingent Weiterleitungsregeln für die externe Protokollweiterleitung an Zielinstanzen
Traffic Director-Weiterleitungsregeln Kontingent Weiterleitungsregeln für Traffic Director
Weiterleitungsregeln für internes TCP/UDP-Load-Balancing pro VPC-Netzwerk Kontingent

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.

Kontingentname:
INTERNAL_FORWARDING_RULES_PER_NETWORK

Weitere Informationen finden Sie unter Kontingente für VPC pro Netzwerk.

Weiterleitungsregeln für die interne Protokollweiterleitung Kontingent

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.

Kontingentname:
INTERNAL_FORWARDING_RULES_WITH_TARGET_INSTANCE_PER_NETWORK

Weitere Informationen finden Sie unter Kontingente für VPC pro Netzwerk.

Weiterleitungsregeln pro VPC-Netzwerk für interne HTTP(S)-Load-Balancer und interne regionale TCP-Proxy-Load-Balancer Kontingent

Die maximale Anzahl von Weiterleitungsregeln für interne HTTP(S)-Load-Balancer und interne regionale TCP-Proxy-Load-Balancer.

Dieses Kontingent gilt für die Gesamtzahl der Weiterleitungsregeln für interne HTTP(S)-Load-Balancer und interne regionale TCP-Proxy-Load-Balancer. Sie gilt nicht für jede Region einzeln.

Kontingentname:
INTERNAL_MANAGED_FORWARDING_RULES_PER_NETWORK

Weitere Informationen finden Sie unter Kontingente für VPC pro Netzwerk.

Maximale Anzahl von internen Weiterleitungsregeln, die eine interne IP-Adresse gemeinsam nutzen können 10 Dieses Limit gilt nur für interne TCP/UDP-Load-Balancer. Dieses Limit kann nicht erhöht werden.
Anzahl der separaten Ports pro Weiterleitungsregel für interne TCP/UDP-Load-Balancer und Back-End-Dienst-basierte Netzwerk-Load-Balancer 5

Dieses Limit kann nicht erhöht werden. Es sind jedoch alternative Optionen für die Portspezifikation möglich:

  • Sie können eine einzelne Reihe von zusammenhängenden Ports in Weiterleitungsregeln für Back-End-Dienst-basierte und Load-Balancer-Netzwerk-Load-Balancer angeben. Der Bereich kann mehr als fünf Ports umfassen.
  • Sie können alle Ports in Weiterleitungsregeln für Back-End-Dienst-basierte Netzwerk-Load-Balancer und interne TCP/UDP-Load-Balancer angeben.
Anzahl der Weiterleitungsregeln, die für einen Pass-Through-Load-Balancer auf denselben Back-End-Dienst verweisen können Kein separates Limit Vorbehaltlich anderer Kontingente und Limits können mehrere Weiterleitungsregeln auf denselben Back-End-Dienst für einen Pass-Through-Load-Balancer verweisen.
Anzahl der Back-End-Dienste des Pass-Through-Load-Balancers, auf die von einer einzelnen Weiterleitungsregel verwiesen werden kann 1 Weiterleitungsregeln für Pass-Through-Load-Balancer müssen genau auf einen Back-End-Dienst verweisen.

Zielpools und Ziel-Proxys

Posten Kontingente und Limits Hinweise
Zielpools Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-HTTP-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-HTTPS-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-SSL-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
Ziel-TCP-Proxys Kontingent Dieses Kontingent gilt pro Projekt.
SSL-Richtlinien pro HTTPS- oder SSL-Ziel-Proxy 1 Dieses Limit kann nicht erhöht werden.
SSL-Zertifikate pro HTTPS- oder SSL-Ziel-Proxy 15 Dieses Limit kann nicht erhöht werden.

Systemdiagnosen

Posten Kontingente und Limits Hinweise
Systemdiagnosen Kontingent Dies ist ein projektbezogenes Kontingent, das alle Systemdiagnosetypen (global, regional und Legacy) abdeckt.

SSL-Zertifikate

Posten Kontingente und Limits Hinweise
SSL-Zertifikate Kontingent Dieses Kontingent gilt pro Projekt.
Unterstützte Schlüssellängen für private Schlüssel 2.048 Bit RSA (RSA-2048)
256 Bit ECDSA (ECDSA P-256)
Diese Limits können nicht erhöht werden.
Mehrere Domains pro von Google verwaltetem SSL-Zertifikat 100 Dieses Limit kann nicht erhöht werden.
Länge der Domainnamen für von Google verwaltete Zertifikate 64 Byte Dieses Limit kann nicht erhöht werden.

Diese Längenbeschränkung gilt nur für von Google verwaltete SSL-Zertifikate. Das Limit von 64 Byte in diesen Zertifikaten gilt nur für die erste Domain im Zertifikat. Die Längenbeschränkung für die anderen Domains im Zertifikat beträgt 253 Byte. Diese gilt für alle Domainnamen im Internet, nicht nur für von Google verwaltete Zertifikate.

URL-Zuordnungen

Die hier dokumentierten Limits können nicht erhöht werden.

Posten Externes HTTP(S)-Load-Balancing Internes HTTP(S)-Load-Balancing
URL-Zuordnungen Kontingent

Dieses Kontingent gilt pro Projekt.

Kontingent

Dieses Kontingent gilt pro Projekt.

Hostregeln, Pfad-Matcher pro URL-Zuordnung Limit: 1000 Limit: 2000
Pfadregeln oder Routingregeln pro Pfad-Matcher Limit: 1000 Limit: 200
Hosts pro Hostregel Limit: 1000 Limit: 1000
Prädikate pro Pfad-Matcher Limit: 1000 Limit: 1000
Anzahl der verschiedenen Back-End-Dienste oder Back-End-Buckets, auf die von einer URL-Zuordnung verwiesen werden kann Limit: 2500 Limit: 2500

Andere Limits, die für die projektübergreifende Dienstreferenz relevant sind:

  • Eine URL-Zuordnung kann auf Back-End-Dienste in maximal 100 verschiedenen Projekten verweisen.
  • URL-Zuordnungen von maximal 10 verschiedenen Projekten können auf einen bestimmten Back-End-Dienst verweisen.
Größe der URL-Zuordnungen Limit: 64 KB Limit: 128 KB
Anzahl der URL-Zuordnungstests Limit: 10000

Das interne HTTP(S)-Load-Balancing unterstützt keine URL-Zuordnungstests.

Dies ist ein Limit für die Anzahl der Übereinstimmungsbedingungen in allen Regeln im Pfad-Matcher. Bei Pfad-Matchern mit Pfadregeln ist dies die Gesamtzahl der Pfade in allen Pfadregeln. Bei Pfad-Matchern mit Routingregeln wird die Präfixanzahl berechnet. Dazu wird Folgendes hinzugefügt:

  • 1 für die Bedingung der Pfadübereinstimmung (eine von prefixMatch oder fullPathMatch)
  • die Summe der Header-Übereinstimmungen in allen Routingregeln des Pfad-Matchers
  • die Summe der Abfrageparameterübereinstimmungen in allen Routingregeln des Pfad-Matchers

Zum Beispiel für einen Pfad-Matcher mit den folgenden Routingregeln:

  • Routingregel A mit einer prefixMatch- und drei Headerübereinstimmungen
  • Routingregel B mit einer fullPathMatch- und zwei Abfrageparameterübereinstimmungen

Die Gesamtzahl der Prädikate für den Pfad-Matcher beträgt 7. Sie wird so berechnet: 1 (für den prefixMatch) + 3 (für die Anzahl der Headerübereinstimmungen) + 1 (für den fullPathMatch) + 2 (für die Anzahl der Abfrageparameterübereinstimmungen).

Back-End-Buckets

Posten Kontingente und Limits Hinweise
Back-End-Buckets Kontingent Dieses Kontingent gilt pro Projekt.

Back-End-Dienste

Posten Kontingente und Limits Hinweise
Back-End-Dienste Kontingent Dieses Kontingent umfasst alle Back-End-Dienste (INTERNAL, INTERNAL_MANAGED, INTERNAL_SELF_MANAGED, EXTERNAL, and EXTERNAL_MANAGED) in Ihrem Projekt.
Back-End-Dienste pro externem TCP-Proxy-Load-Balancer, externem SSL-Proxy-Load-Balancer, internem TCP/UDP-Load-Balancer und Back-End-Dienst-basiertem Netzwerk-Load-Balancer. 1 Dieses Limit kann nicht erhöht werden.
Maximale Anzahl von VM-Instanzen für den Back-End-Dienst eines internen TCP/UDP-Load-Balancers

Diese Beschränkung gilt für die Gesamtzahl der Instanzen im aktiven Pool, falls Sie Failover konfiguriert haben.

Ohne Back-End-Teilmengeneinstellung: 250

Mit aktivierter Back-End-Teilmengeneinstellung: 2.000

Diese Limits können nicht erhöht werden.
Sie gelten unabhängig davon, wie die Instanzen in Instanzgruppen oder GCE_VM_IP-NEGs gruppiert sind. Wenn Sie beispielsweise fünf Instanzgruppen mit jeweils 60 VM-Instanzen demselben internen TCP/UDP-Load-Balancer-Back-End-Dienst hinzufügen, verteilt der Load-Balancer nur Pakete an 250 der 300 Instanzen (5 × 60), wenn die Back-End-Teilmengeneinstellung deaktiviert ist.

Benannte Ports pro Back-End-Dienst eines Proxy-Load-Balancers 1 Dieses Limit kann nicht erhöht werden.
Benannte Ports pro Back-End-Dienst eines Pass-Through-Load-Balancers 0 Dieses Limit kann nicht erhöht werden. Das Feld portName im Back-End-Dienst wird für Pass-Through-Load-Balancer ignoriert.
Maximale Anzahl unterschiedlicher Projekte, die URL-Zuordnungen enthalten, die auf einen bestimmten Back-End-Dienst verweisen können (Limit für projektübergreifende Dienstreferenzen) 10 URL-Zuordnungen von maximal 10 verschiedenen Projekten können auf einen bestimmten Back-End-Dienst verweisen. Dieses Limit kann nicht erhöht werden. Dieses Limit gilt unabhängig für jeden Back-End-Dienst.

Back-Ends

Posten Kontingente und Limits Hinweise
Instanzgruppen Kontingent Dieses Kontingent gilt pro Projekt.
NEGs pro Projekt Kontingent Dieses Kontingent gilt pro Projekt.
Maximale Anzahl an Instanzgruppen-Back-Ends, GCE_VM_IP_PORT NEG-Back-Ends oder GCE_VM_IP NEG-Back-Ends pro Back-End-Dienst 50

Dieses Limit ist nicht konfigurierbar.

Die Unterstützung für NEG-Back-Ends von GCE_VM_IP_PORT und GCE_VM_IP variiert je nach Load-Balancing-Produkt.

Wenn Sie ein Failover für Back-End-Dienst-basierte Netzwerk-Load-Balancer oder ein Failover für interne TCP/UDP-Load-Balancer konfiguriert haben, gilt Folgendes: Pro Back-End-Dienst können bis zu 50 primäre und 50 Sicherungsinstanzgruppen oder GCE_VM_IP-NEGs konfiguriert werden.

Interne TCP/UDP-Load-Balancer haben außerdem ein Limit für die Anzahl einzelner VM-Instanzen oder Endpunkte, auf die ein Back-End-Dienst Pakete verteilen kann. Weitere Informationen finden Sie unter Kontingente für Back-End-Dienste.

Endpunkte pro NEG

Posten Kontingente und Limits Hinweise
Endpunkte pro zonaler GCE_VM_IP_PORT-NEG 10.000 Dieses Limit kann nicht erhöht werden.
Endpunkte pro zonaler GCE_VM_IP-NEG 10.000 Dieses Limit kann nicht erhöht werden.
Endpunkte pro Internet-NEG 1 Dieses Limit kann nicht erhöht werden.
Endpunkte pro serverloser NEG 1 Dieses Limit kann nicht erhöht werden.
Endpunkte pro Hybridkonnektivitäts-NEG 10.000 Dieses Limit kann nicht erhöht werden.

VMs pro Instanzgruppe

Die Anzahl der Back-End-VMs, die von einem einzelnen Load-Balancer bedient werden können, ist möglicherweise geringer als die Anzahl der VMs, die eine Instanzgruppe unterstützen kann. Die maximale Anzahl von VMs mit Load-Balancing pro Instanzgruppe hängt von der Anzahl der Ports ab, die in jedem benannten Port angegeben sind, den die Instanzgruppe exportiert.

Die Obergrenze der Load-Balancer-VMs pro Instanzgruppe darf 2.000 für regional verwaltete Instanzgruppen und 1.000 für zonal verwaltete oder zonal nicht verwaltete Instanzgruppen nicht überschreiten.

Posten Kontingente und Limits Hinweise
Maximale Anzahl von VMs pro regional verwalteter Instanzgruppe, die mit dem Back-End-Dienst eines Pass-Through-Load-Balancers verbunden ist 2.000 Interne TCP/UDP-Load-Balancer haben außerdem ein Limit für die Anzahl einzelner VM-Instanzen oder Endpunkte, auf die ein Back-End-Dienst Pakete verteilen kann. Weitere Informationen finden Sie unter Kontingente für Back-End-Dienste.
Maximale Anzahl von VMs pro zonal verwalteter Instanzgruppe oder pro zonal nicht verwalteter Instanzgruppe, die mit dem Back-End-Dienst eines Pass-Through-Load-Balancers verbunden ist 1.000 Interne TCP/UDP-Load-Balancer haben außerdem ein Limit für die Anzahl einzelner VM-Instanzen oder Endpunkte, auf die ein Back-End-Dienst Pakete verteilen kann. Weitere Informationen finden Sie unter Kontingente für Back-End-Dienste.
Maximale Anzahl von VMs pro regional verwalteter Instanzgruppe, die mit dem Back-End-Dienst eines Proxy-Load-Balancers verbunden ist Hängt von der Anzahl der Ports ab, die im benannten Port für die Instanzgruppe angegeben sind. Der kleinere der beiden Werte:
A: 2.000
B: 10.000 / (Anzahl der Ports im benannten Port, der die meisten Portnummern enthält)
Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.
Maximale Anzahl von VMs pro zonal verwalteter Instanzgruppe oder pro nicht verwalteter Instanzgruppe, die mit dem Back-End-Dienst eines Proxy-Load-Balancers verbunden ist Hängt von der Anzahl der Ports ab, die im benannten Port für die Instanzgruppe angegeben sind. Der kleinere der beiden Werte:
A: 1.000
B: 10.000 / (Anzahl der Ports im benannten Port, der die meisten Portnummern enthält)
Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.

So berechnen Sie die maximale Anzahl von VMs mit Load-Balancing in einem Instanzgruppen-Back-End:

  1. Maximale Anzahl von Ports pro benanntem Port festlegen.

    Beispiel: Eine Instanzgruppe hat die folgenden benannten Ports: http:80, api-gateway:8080 und api-gateway:8090. Für den http-Namen gibt es eine Portnummer und zwei Portnummern für den api-gateway-Namen. Daher ist in diesem Beispiel die maximale Anzahl von Ports pro benanntem Port zwei.

  2. Teilen Sie 10.000 durch die maximale Anzahl der Ports pro benanntem Port und verwerfen Sie den Rest. z. B. 10,000 / 2 = 5,000.

  3. Vergleichen Sie die im vorherigen Schritt berechnete Anzahl mit der Obergrenze der VMs mit Load-Balancing pro Instanzgruppe: 2.000 für regionale Gruppen, 1.000 für zonale Gruppen.

    Wenn die im vorherigen Schritt berechnete Anzahl kleiner oder gleich dem oberen Limit ist, ist die maximale Anzahl von VMs mit Load-Balancing pro Instanzgruppe die Anzahl, die Sie im vorherigen Schritt berechnet haben. Andernfalls ist die maximale Anzahl von VMs mit Load-Balancing pro Instanzgruppe die Obergrenze (2.000 für regionale Gruppen oder 1.000 für zonale Gruppen).

Abfragen pro Sekunde für HTTP(S)-Load-Balancing

Posten Kontingente und Limits Hinweise
Abfragen pro Sekunde pro Back-End-Instanzgruppe oder NEG für externes HTTP(S)-Load-Balancing Konfigurierbar bei Verwendung von RATE als Load-Balancing-Modus. Durch Ihre Back-Ends begrenzt.
Abfragen pro Sekunde pro Region und Netzwerk für internes HTTP(S)-Load-Balancing Beim internen HTTP(S)-Load-Balancing hängt die maximale Anzahl von Abfragen pro Sekunde von der Größe der Abfragen und der Komplexität der Konfiguration ab. Wenn die Last die Kapazität überschreitet, nimmt die Latenz zu und Anfragen werden unter Umständen abgebrochen. Wenden Sie sich an Ihr Google Cloud-Vertriebsteam, wenn Sie dieses Limit erhöhen möchten.

Header-Größe für HTTP(S)-Load-Balancing

Posten Kontingente und Limits Hinweise
Maximale Größe des Client-Anfrageheaders für externes HTTP(S)-Load-Balancing 64 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Die Gesamtgröße von Anfrage-URL Anfrageheader darf 64 KB nicht übersteigen.
Maximale Größe des Back-End-Antwortheaders für externes HTTP(S)-Load-Balancing Ca. 128 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Maximale Größe des Back-End-Anfrageheaders für internes HTTP(S)-Load-Balancing 60 KB (Kilobyte) Dieses Limit kann nicht erhöht werden.
Umwandlung von HTTP-Anfrage- und -Antwortheadern in Kleinbuchstaben Immer, mit Ausnahme des globalen externen HTTP(S)-Load-Balancers (klassisch) bei Verwendung von HTTP/1.1 Beispiel: Host wird zu host und Keep-ALIVE zu keep-alive.
Maximale Anzahl konfigurierter benutzerdefinierter Anfrageheader für jeden Back-End-Dienst 16 Dieses Limit kann nicht erhöht werden.
Maximale Anzahl konfigurierter benutzerdefinierter Antwortheader für jeden Back-End-Dienst 16 Dieses Limit kann nicht erhöht werden.
Gesamtgröße aller benutzerdefinierten Anfrageheader pro Back-End-Dienst (Headername und -wert, vor der Variablenerweiterung) 8 KB Dieses Limit kann nicht erhöht werden.
Gesamtgröße aller benutzerdefinierten Antwortheader pro Back-End-Dienst (Headername und -wert, vor der Variablenerweiterung) 8 KB Dieses Limit kann nicht erhöht werden.

Verwalten von Kontingenten

Mit Cloud Load Balancing 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

  1. Öffnen Sie in der Google Cloud Console die 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 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

  1. Öffnen Sie in der Google Cloud Console die 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. 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.