Kontingente und Limits

In diesem Dokument sind die für Compute Engine geltenden Kontingente und Begrenzungen 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.

Bei Compute Engine werden aus verschiedenen Gründen Kontingente für die Ressourcennutzung erzwungen. Diese bieten unter anderem für die gesamte Google Cloud-Community eine Unterstützung für unvorhergesehene Auslastungsspitzen. Google Cloud bietet außerdem kostenlose Testkontingente, die einen eingeschränkten Zugriff für Projekte bieten, die zum Kennenlernen von Google Cloud im Rahmen einer kostenlosen Testversion dienen.

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie Google Cloud im Laufe der Zeit häufiger nutzen, können sich Ihre Kontingente entsprechend erhöhen. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite Kontingente der Google Cloud Console eine Anpassung Ihres Kontingents anfordern.

Informationen zu Kontingenten für die Ratenbegrenzungen für die Compute Engine API finden Sie unter API-Ratenlimits.

Berechtigungen zum Prüfen und Bearbeiten von Kontingenten

Um Ihre Kontingente aufzurufen, benötigen Sie die Berechtigung serviceusage.quotas.get.

Um Ihre Kontingente zu ändern ist die Berechtigung serviceusage.quotas.update erforderlich.

Diese Berechtigungen sind standardmäßig in den einfachen IAM-Rollen "Inhaber" und "Bearbeiter" sowie in der vordefinierten Rolle "Kontingentadministrator" enthalten.

Kontingent prüfen

Regionale Kontingente sind keine Teilmenge der Kontingente von Projekten. VM-Instanzen sind Teil der regionalen Kontingente.

Informationen zu regionalen Kontingenten, z. B. die Anzahl von VMs, die Sie in einer Region erstellen können, finden Sie unter Regionale Kontingente prüfen. Verwenden Sie die Google Cloud Console oder das Google Cloud CLI, um Ihr Projekt-Kontingent zu prüfen.

Informationen zu Kontingentkategorien finden Sie unter Informationen zu Kontingenten.

Regionales Kontingent prüfen

Console

Öffnen Sie in der Google Cloud Console die Seite Kontingente.

Kontingente aufrufen

gcloud

Listen Sie die Kontingente für eine Region auf:

gcloud compute regions describe REGION

Ersetzen Sie dabei REGION durch den Namen der Region, für die Sie eine Liste der Kontingentinformationen aufrufen möchten.

Projektkontingent prüfen

Console

Öffnen Sie in der Google Cloud Console die Seite Kontingente.

Kontingente aufrufen

gcloud

Prüfen Sie die projektweiten Kontingente:

gcloud compute project-info describe --project PROJECT_ID

Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

Höheres Kontingent anfordern

Für die Anforderung einer Kontingenterhöhung fallen keine Kosten an. Ihre Kosten erhöhen sich nur, wenn Sie die zusätzlichen Ressourcen auch nutzen.

Anfragen zum Verringern des Kontingents werden standardmäßig abgelehnt. Sollten Sie Ihr Kontingent verringern wollen, antworten Sie bitte auf die E-Mail des Supports und erklären Sie Ihre Anforderungen. Ein Supportmitarbeiter wird innerhalb von 48 Stunden auf Ihre Anfrage antworten.

Sie sollten zusätzliche Ressourcen mindestens einige Tage im Voraus planen und anfordern, damit genügend Zeit bleibt, die Anfrage zu bearbeiten.

Eine ausführliche Anleitung zur Erhöhung des Kontingents über die Google Cloud Console finden Sie unter Höheres Kontingent anfordern.

Kontingente und Ressourcenverfügbarkeit

Ressourcenkontingente legen die maximale Anzahl der Ressourcen eines bestimmten Typs fest, die Sie erstellen können, sofern diese Ressourcen verfügbar sind. Kontingente garantieren jedoch nicht, dass Ressourcen immer verfügbar sind. Wenn eine Ressource nicht verfügbar ist oder Ihr Kontingent in der Region erschöpft ist, können Sie keine neuen Ressourcen dieses Typs erstellen. Das gilt auch, wenn Ihr Kontingent in der Region oder für das Projekt noch nicht erschöpft ist. Beispiel: Ihr Kontingent zum Erstellen externer IP-Adressen in us-central1 ist noch nicht aufgebraucht, aber in dieser Region sind keine IP-Adressen mehr verfügbar.

Es kann auch sein, dass Sie ein regionales Kontingent haben, eine Ressource aber in einer bestimmten Zone nicht verfügbar ist. Beispiel: Sie haben ein Kontingent zum Erstellen von VM-Instanzen in der Region us-central1, können aber keine VM-Instanzen in der Zone us-central1-a erstellen, wenn das Kontingent der Zone ausgeschöpft ist. Versuchen Sie in solchen Fällen, die jeweilige Ressource in einer anderen Zone zu erstellen, zum Beispiel in us-central1-f. Weitere Informationen zu Ihren Optionen bei erschöpften zonalen Ressourcen finden Sie in der Dokumentation zur Fehlerbehebung bei Ressourcenverfügbarkeit.

Ressourcenkontingente

Bei der Planung der Anforderungen von VM-Instanzen sollten Sie mehrere Kontingente nutzen, die sich darauf auswirken, wie viele VM-Instanzen Sie erstellen können.

Regionale und globale Kontingente

VM-Kontingente werden auf regionaler Ebene verwaltet. VM-Instanzen, Instanzgruppen, Laufwerkskontingente und CPU können von jeder VM in der Region unabhängig von der Zone genutzt werden. Das CPU-Kontingent ist beispielsweise ein regionales Kontingent, deshalb gilt für jede Region ein anderes Limit und eine andere Nutzungsanzahl. Sie benötigen ein Kontingent für mindestens 16 CPUs in us-central1, um eine Instanz vom Typ n2-standard-16 in einer beliebigen Zone der Region us-central1 zu starten.

Netzwerk- und Load-Balancing-Kontingente werden benötigt, um Firewalls, Load-Balancer, Netzwerke und VPNs zu erstellen. Dies sind globale Kontingente, die nicht von einer Region abhängig sind. Ein globales Kontingent kann von jeder Region genutzt werden. Beispielsweise verbrauchen genutzte und statische externe IP-Adressen, die Load-Balancern und HTTP(S)-Proxys zugewiesen sind, globale Kontingente.

VM-Instanzen

Das Kontingent für VM-Instanzen ist ein regionales Kontingent, mit dem die Anzahl der vorhandenen VM-Instanzen in einer bestimmten Region eingeschränkt wird, unabhängig davon, ob die VM ausgeführt wird. Dieses Kontingent wird in der Google Cloud Console auf der Seite Kontingente angezeigt. Das Kontingent wird von Compute Engine automatisch auf das 10-fache Ihres regulären CPU-Kontingents festgelegt. Sie brauchen dieses Kontingent nicht anzufordern. Wenn Sie ein Kontingent für weitere VM-Instanzen benötigen, sollten Sie zusätzliche CPUs anfordern. Mehr CPUs erhöhen auch das Kontingent für VM-Instanzen. Das Kontingent wird auf ausgeführte und auf nicht ausgeführte VMs sowie auf normale Instanzen und auf Instanzen auf Abruf angerechnet.

  1. Öffnen Sie in der Google Cloud Console die Seite Kontingente.

    Kontingente aufrufen

  2. Klicken Sie auf Tabelle filtern und wählen Sie Dienst aus.

  3. Wählen Sie Compute Engine API aus.

  4. Wählen Sie Limitname: VM-Instanzen aus.

  5. Um eine Liste der VM-Instanzkontingente nach Region aufzurufen, klicken Sie auf Alle Kontingente. Ihre Kontingente für die einzelnen Regionen sind absteigend aufgeführt.

  6. Klicken Sie auf das Kästchen der Region, deren Kontingent Sie ändern möchten.

  7. Klicken Sie auf Kontingente bearbeiten.

  8. Füllen Sie es aus.

  9. Klicken Sie auf Antrag einreichen.

Instanzgruppen

Zum Verwenden von Instanzgruppen benötigen Sie ein verfügbares Kontingent für alle Ressourcen, die die Gruppe nutzt (beispielsweise ein CPU-Kontingent), sowie ein verfügbares Kontingent für die Gruppenressource selbst. Je nach Gruppentyp gelten folgende Kontingente für die Gruppenressourcen:

Diensttyp Dienstkontingent
Regional (mehrere Zonen) verwaltete Instanzgruppe Regional instance group managers
Zonal (einzelne Zone) verwaltete Instanzgruppe Beide:
  • Instance group managers
  • Instance groups
Nicht verwaltete (einzelne Zone) Instanzgruppe Instance groups
Regionales (mehrere Zonen) Autoscaling Regional autoscalers
Zonales (einzelne Zone) Autoscaling Autoscalers

Laufwerkskontingente

Die folgenden Kontingente für nichtflüchtigen Speicher und lokale SSDs gelten je Region:

  • Local SSD (GB): Dieses Kontingent ist die kombinierte Gesamtgröße der lokalen SSD-Laufwerkspartitionen, die in einer Region an VMs angehängt werden können. Eine lokale SSD ist ein schnelles, flüchtiges Laufwerk, das für Scratch-Jobs, den lokalen Cache oder Verarbeitungsjobs mit einer hohen Fehlertoleranz genutzt werden kann, da der Inhalt dieses Laufwerks nach dem Neustart einer VM-Instanz nicht mehr verfügbar ist. Lokale SSD-Partitionen werden in Schritten von 375 GB verkauft. Es können bis zu 24 lokale SSD-Partitionen an eine VM angehängt werden. In der gcloud CLI und der API wird dieses Kontingent LOCAL_SSD_TOTAL_GB genannt.
  • Persistent disk standard (GB): Dieses Kontingent ist die Gesamtgröße der nichtflüchtigen Standardspeicher, die in einer Region erstellt werden können. Wie unter Leistung von nichtflüchtigen Speichern und lokalen SSDs optimieren gezeigt, bieten nichtflüchtige Standardspeicher weniger IOPS und Durchsatz als nichtflüchtige SSD-Speicher oder lokale SSDs. Sie können jedoch kostengünstig als große langlebige Laufwerke für Speicher, als Bootlaufwerke sowie für serielle Schreibvorgänge wie Logs eingesetzt werden. Nichtflüchtige Standardspeicher sind langlebig und können in unbegrenzter Zahl an eine VM in einer Zone angehängt werden. In der gcloud CLI und der API wird dieses Kontingent DISKS_TOTAL_GB genannt. Dieses Kontingent gilt auch für regionale nichtflüchtige Standardspeicher. Regionale Laufwerke verbrauchen jedoch pro GB doppelt so viel vom Kontingent, weil sie innerhalb einer Region in zwei Zonen repliziert werden.
  • Persistent disk SSD (GB): Dieses Kontingent ist die kombinierte Gesamtgröße der Partitionen SSD-gestützter nichtflüchtiger Speicher, die in einer Region erstellt werden können. SSD-gestützte nichtflüchtige Speicher umfassen mehrere Replikate und bieten mehr IOPS sowie einen höheren Durchsatz als nichtflüchtige Standardspeicher, wie unter Blockspeicherleistung erläutert. SSD-gestützte nichtflüchtige Speicher stehen in unbegrenzter Zahl zum Anhängen an eine VM innerhalb einer Zone zur Verfügung. In der gcloud CLI und der API wird dieses Kontingent SSD_TOTAL_GB genannt. Dieses Kontingent ist vom lokalen SSD-Kontingent getrennt. Dieses Kontingent gilt für die unten aufgeführten Speichertypen. Regionale nichtflüchtige Speicher verbrauchen pro GB doppelt so viel vom Kontingent, weil sie innerhalb einer Region in zwei Zonen repliziert werden:
    • Zonaler und regionaler nichtflüchtiger SSD-Speicher
    • Abgestimmter zonaler und regionaler nichtflüchtiger Speicher

CPU-Kontingent

Das CPU-Kontingent bezieht sich auf die Gesamtzahl der virtuellen CPUs in Ihren VM-Instanzen in einer Region. CPU-Kontingente gelten für ausgeführte VMs und VM-Reservierungen. Sowohl vordefinierte VMs als auch VMs auf Abruf nutzen dieses Kontingent.

Zum Schutz der Compute Engine-Systeme und anderer Nutzer haben einige neue Konten und Projekte auch ein globales CPUs (All Regions)-Kontingent. Dieses gilt regionenübergreifend und wird als Gesamtzahl Ihrer vCPUs in allen Regionen berechnet.

Wenn Sie beispielsweise in einer Region (z. B. us-central1) noch 48 vCPUs, aber für das Kontingent CPUs (All Regions) nur 32 vCPUs haben, können Sie in der Region us-central1 trotz des verbleibenden Kontingents nur 32 vCPUs starten. Das liegt daran, dass das Kontingent CPU (All Regions) ausgeschöpft wurde. Sie müssen vorhandene Instanzen löschen, um neue Instanzen starten zu können.

E2- und N1-Maschinentypen nutzen gemeinsam einen CPU-Kontingentpool. N2-, N2D-, M1-, M2- und C2-Maschinentypen haben eigene, separate CPU-Kontingentpools.

Wenn Sie Rabatte für zugesicherte Nutzung für Ihre VMs verwenden, müssen Sie ein Rabattkontingent für zugesicherte Nutzung haben, bevor Sie einen Rabatt für zugesicherte Nutzung erwerben.

Maschinentyp Kontingentpool Name des CPU-Kontingents Name des zugesicherten CPU-Kontingents
E2, N1 Gemeinsam genutzter Pool CPUS Committed_CPUS
N2 Separater Pool N2_CPUS Committed_N2_CPUS
N2D Separater Pool N2D_CPUS Committed_N2D_CPUS
T2D Separater Pool T2D_CPUS Committed_T2D_CPUS
T2A Separater Pool T2A_CPUS Nicht verfügbar (N/V) für Committed_T2A_CPUS
M1 Separater Pool M1_CPUS Committed_MEMORY-OPTIMIZED_CPUS
M2 Separater Pool M2_CPUS Committed_MEMORY-OPTIMIZED_CPUS
C2 Separater Pool C2_CPUS Committed_C2_CPUS
C2D Separater Pool C2D_CPUS Committed_C2D_CPUS
A2 Separater Pool A2_CPUS Committed_A2_CPUS
VMs auf Abruf Gemeinsam genutzter Pool PREEMPTIBLE_CPUS Nicht verfügbar (N/V) für VMs auf Abruf

GPU-Kontingent

Wie das CPU-Kontingent bezieht sich auch das GPU-Kontingent auf die Gesamtzahl der virtuellen GPUs in allen VM-Instanzen in einer Region. GPU-Kontingente gelten für ausgeführte VMs und VM-Reservierungen. Sowohl vordefinierte VMs als auch VMs auf Abruf nutzen dieses Kontingent.

Prüfen Sie auf der Seite Kontingente, ob in Ihrem Projekt ausreichend GPUs zur Verfügung stehen, und fordern Sie gegebenenfalls ein höheres Kontingent an. Neue Konten und Projekte haben außerdem ein globales GPU-Kontingent, das für alle Regionen gilt.

Wenn Sie ein GPU-Kontingent anfordern, müssen Sie ein Kontingent für die GPU-Modelle, die Sie in den einzelnen Regionen erstellen möchten, sowie ein zusätzliches globales Kontingent für die Gesamtzahl der GPUs aller Typen in allen Zonen anfordern. Fordern Sie für die Verwendung dieser Ressourcen ein GPU-Kontingent auf Abruf an.

Logo: NVIDIA Name des GPU-Kontingents Name des zugesicherten GPU-Kontingents Virtuelle Workstation GPUs auf Abruf GPU auf Abruf für Workstations
A100 40GB NVIDIA_A100_GPUS COMMITTED_NVIDIA_A100_GPUS – PREEMPTIBLE_NVIDIA_A100_GPUS –
A100 80GB (Vorschau) NVIDIA_A100_80GB_GPUS COMMITTED_NVIDIA_A100_80GB_GPUS – PREEMPTIBLE_NVIDIA_A100_80GB_GPUS –
T4 NVIDIA_T4_GPUS COMMITTED_NVIDIA_T4_GPUS NVIDIA_T4_VWS_GPUS PREEMPTIBLE_NVIDIA_T4_GPUS PREEMPTIBLE_NVIDIA_T4_VWS_GPUS
V100 NVIDIA_V100_GPUS COMMITTED_NVIDIA_V100_GPUS – PREEMPTIBLE_NVIDIA_V100_GPUS –
P100 NVIDIA_P100_GPUS COMMITTED_NVIDIA_P100_GPUS NVIDIA_P100_VWS_GPUS PREEMPTIBLE_NVIDIA_P100_GPUS PREEMPTIBLE_NVIDIA_P100_VWS_GPUS
P4 NVIDIA_P4_GPUS COMMITTED_NVIDIA_P4_GPUS NVIDIA_P4_VWS_GPUS PREEMPTIBLE_NVIDIA_P4_GPUS PREEMPTIBLE_NVIDIA_P4_VWS_GPUS
K80 NVIDIA_K80_GPUS COMMITTED_NVIDIA_K80_GPUS – PREEMPTIBLE_NVIDIA_K80_GPUS –

Kontingente für Ressourcen auf Abruf

Sie müssen in Ihrem Projekt für die jeweiligen Ressourcen ein Kontingent haben, um CPUs auf Abruf oder an VM-Instanzen auf Abruf angehängte GPUs bzw. lokale SSDs zu verwenden.

Sie können für Preemptible CPUs, Preemptible GPUs oder Preemptible Local SSDs (GB) spezielle Kontingente auf Abruf anfordern. Wenn Ihr Projekt jedoch kein Kontingent auf Abruf hat und Sie kein Kontingent auf Abruf angefordert haben, können Sie das Standardkontingent zum Starten von Ressourcen auf Abruf verwenden.

Nachdem Ihnen von Compute Engine ein Kontingent auf Abruf in einer Region zugeteilt wurde, werden alle Instanzen auf Abruf automatisch auf das Auf-Abruf-Kontingent angerechnet. Da dieses Kontingent ausgeschöpft ist, müssen Sie für diese Ressourcen ein Kontingent auf Abruf anfordern.

Externe IP-Adressen

Sie benötigen eine ausreichende Anzahl an externen IP-Adressen für jede VM, die über das öffentliche Internet erreichbar sein muss. Das regionale IP-Kontingent gilt für die Zuweisung von IPv4-Adressen zu VMs in dieser Region. Das globale IP-Kontingent gilt für die Zuweisung von IPv4-Adressen an globale Netzwerkressourcen wie Load-Balancer. Google Cloud bietet passend zu Ihren Anforderungen verschiedene Arten von IP-Adressen an. Weitere Informationen zu Preisen finden Sie unter Preise für externe IP-Adressen. Ausführliche Informationen zu Kontingenten finden Sie unter Kontingente und Limits.

  • Verwendete externe IP-Adressen: Diese umfassen sitzungsspezifische und statische IP-Adressen, die aktuell von einer Ressource genutzt werden.

  • Statische externe IP-Adressen: Externe IP-Adressen, die für Ihre Ressourcen reserviert wurden und auch nach dem Neustart einer Maschine beibehalten werden. Sie können diese Adressen bei DNS- und Domainanbietern registrieren, um eine nutzerfreundliche Adresse zu erhalten, beispielsweise www.example-site.com.

  • Statische interne IP-Adressen: Mit statischen internen IP-Adressen können Sie interne IP-Adressen aus dem im Subnetz konfigurierten internen IP-Bereich reservieren. Diesen reservierten internen Adressen können Sie nach Bedarf Ressourcen zuordnen.

API-Ratenbegrenzungen

API-Ratenbegrenzungen (auch API-Kontingente genannt) definieren die Anzahl der Anfragen, die an die Compute Engine API gesendet werden können. These Ratenbegrenzungen gelten pro Projekt. Jede Ratenbegrenzung entspricht allen Anfragen für eine Gruppe von einer oder mehreren Compute Engine API-Methoden. Wenn Sie gcloud compute oder die Google Cloud Console verwenden, stellen Sie auch Anfragen an die API. Diese Anfragen werden auf die Ratenbegrenzungen angerechnet. Dasselbe gilt für Zugriffe auf die API über Dienstkonten.

API-Ratenbegrenzungen werden erzwungen und automatisch in 60-Sekunden-Intervallen (1 Minute) neu aufgefüllt. Wenn Ihr Projekt also innerhalb von 60 Sekunden das Maximum einer Ratenbegrenzung erreicht, müssen Sie warten, bis dieses Kontingent aufgebraucht ist, bevor Sie in dieser Gruppe weitere Anfragen stellen. Wenn Ihr Projekt eine Ratenbegrenzung überschreitet, erhalten Sie einen 403-Fehler mit dem Grund rateLimitExceeded. Um diesen Fehler zu beheben, warten Sie eine Minute und wiederholen Sie dann die Anfrage. Das Kontingent sollte zu Beginn des nächsten Intervalls neu aufgefüllt werden.

Derzeit sind Anfragen mithilfe der folgenden Gruppen begrenzt. Jede Gruppe wird separat gezählt, sodass Sie das Höchstlimit in jeder Gruppe gleichzeitig erreichen können.

Die folgenden Ratenbegrenzungsgruppen gelten für alle Ressourcen, sofern nicht anders angegeben:

Begrenzungsgruppe Beschreibung Standardbegrenzung
Abfragen
  • Standardbegrenzung für Mutationsmethoden.
  • Messwert: compute.googleapis.com/default
Begrenzung pro Projekt (defaultPerMinutePerProject): 1.500 Anfragen/Minute
Leseanfragen
  • Begrenzung für *.get-Methoden.
  • Messwert: compute.googleapis.com/read_requests
Begrenzung pro Projekt (ReadRequestsPerMinutePerProject): 1.500 Anfragen/Minute
Anfragen vom Typ „Auflisten“
  • Begrenzung für *.list-Methoden.
  • Messwert: compute.googleapis.com/list_requests
Begrenzung pro Projekt (ListRequestsPerMinutePerProject): 1.500 Anfragen/Minute
Leseanfragen für Vorgänge
  • Begrenzung für globalOperations.get, regionOperations.get und zoneOperations.get methods.
  • Metric: compute.googleapis.com/operation_read_requests
Begrenzung pro Projekt (OperationReadRequestsPerMinutePerProject): 1.500 Anfragen/Minute
Globale Anfragen zum Ändern von Ressourcen
  • Begrenzung für Methoden disks.createSnapshot, images.delete, images.deprecate, images.insert, images.setLabels, snapshots.delete, snapshots.insert, snapshots.setLabels, machineImages.insert und machineImages.delete.
  • Messwert: compute.googleapis.com/global_resource_write_requests
Begrenzung pro Projekt (GlobalResourceWriteRequestsPerMinutePerProject): 375 Anfragen/Minute
Komplexe Mutationsanfragen
  • Begrenzung für die Methoden patch, delete und insert für die Ressourcen interconnects und interconnectAttachments.
  • Messwert: compute.googleapis.com/heavy_weight_write_requests
Begrenzung pro Projekt (HeavyWeightWriteRequestsPerMinutePerProject): 750 Anfragen/Minute
Komplexe Leseanfragen
  • Begrenzung für Methoden wie Operations.wait, *.getEffectiveFirewalls und *.aggregatedList.
  • Messwert: compute.googleapis.com/heavy_weight_read_requests
Begrenzung pro Projekt (HeavyWeightReadRequestsPerMinutePerProject): 750 Anfragen/Minute

Die folgenden Ratenbegrenzungsgruppen gelten für APIs mit Methodenbegrenzungen:

Begrenzungsgruppe Beschreibung Standardbegrenzung
Anfragen für simulierte Wartungsereignisse für Instanzen
  • Begrenzung für Methode instances.simulateMaintenanceEvent.
  • Messwert: compute.googleapis.com/simulate_maintenance_event_requests
Begrenzung pro Projekt (SimulateMaintenanceEventRequestsPerDayPerProject): 150 Anfragen/Minute
Anfragen an die Liste der Verweis-URLs für Instanz
  • Begrenzung für Methode instances.listReferrers.
  • Messwert: compute.googleapis.com/instance_list_referrers_requests
Begrenzung pro Projekt (InstanceListReferrersRequestsPerMinutePerProject): 3.000 Anfragen/Minute
Anfragen zum Abrufen von serieller Portausgabe für Instanz
  • Begrenzung für Methode instances.getSerialPortOutput.
  • Messwert: compute.googleapis.com/get_serial_port_output_requests
Begrenzung pro Projekt (GetSerialPortOutputRequestsPerMinutePerProject): maximal 1.500 Anfragen/Minute
Anfragen zur Lizenzeinfügung
  • Begrenzungen für die Methode licenses.insert.
  • Messwert: compute.googleapis.com/license_insert_requests
  • Rate pro Projekt (LicenseInsertRequestsPerMinutePerProject): 2,5 Anfragen/Sekunde (150 Anfragen/Minute)
  • Rate pro Tag und Projekt (LicenseInsertRequestsPerDayPerProject): 30 Anfragen/Tag
Anfragen zum Festlegen häufiger Instanzmetadaten für Projekt
  • Begrenzung für Methode projects.setCommonInstanceMetadata.
  • Messwert: compute.googleapis.com/project_set_common_instance_metadata_requests
Begrenzung pro Projekt (ProjectSetCommonInstanceMetadataRequestsPerMinutePerProject): 36 Anfragen/Minute
Anfragen zur Standortempfehlung
  • Begrenzung für Methode regionInstances.recommendLocations.
  • Messwert: compute.googleapis.com/recommend_locations_requests
Begrenzung pro Projekt (RecommendLocationsRequestsPerMinutePerProject): 20 Anfragen/Minute
Schreibanfragen für Netzwerkendpunkte
  • Begrenzung für die Methoden *.AttachNetworkEndpoints und *.DetachNetworkEndpoints.
  • Messwert: compute.googleapis.com/network_endpoint_write_requests
Begrenzung pro Projekt (NetworkEndpointWriteRequestsPerMinutePerProject): 1.500 Anfragen/Minute
Anfragen zur Netzwerkendpunktliste
  • Begrenzung für Methode networkEndpointGroups.listNetworkEndpoints.
  • Messwert: compute.googleapis.com/network_endpoint_list_requests
Begrenzung pro Projekt (NetworkEndpointListRequestsPerMinutePerProject): 1.500 Anfragen/Minute

Halten Sie sich an die Best Practices für das Beibehalten von API-Ratenbegrenzungen der Compute Engine API, um die Auswirkungen von API-Ratenbegrenzungen zu reduzieren.

Wenn Sie eine höhere Ratenbegrenzung für API-Anfragen benötigen, können Sie die aktuelle Verwendung prüfen und eine Erhöhung des API-Kontingents anfordern. Eine ausführliche Anleitung zur Erhöhung des Kontingents über die Google Cloud Console finden Sie unter Höheres Kontingent anfordern.

Limits für gleichzeitige Vorgänge

Limits für gleichzeitige Vorgänge definieren die Anzahl der laufenden oder gleichzeitigen Vorgänge zu einem beliebigen Zeitpunkt. Jede API-Anfrage, die eine Compute Engine-Ressource erstellt, ändert oder löscht, unterliegt einer Beschränkung des gleichzeitigen Vorgangs, um zu prüfen, ob zu diesem Zeitpunkt ein neuer Vorgang erstellt werden kann.

Wenn Ihr Projekt das Limit für gleichzeitige Vorgänge für einen laufenden Vorgang überschreitet, wird der Fehler 403 mit dem Grund rateLimitExceeded angezeigt.

Vorgangsgruppen und Limits

In diesem Abschnitt werden die Limits für verschiedene laufende oder gleichzeitige Compute Engine-Vorgänge beschrieben.

Globale Vorgänge und Limits

Gleichzeitige globale Vorgänge verbrauchen ein globales Limit, das für ein Projekt angegeben ist. In der folgenden Tabelle sind die globalen Limits für laufende Vorgänge aufgeführt:

Vorgang Beschreibung Limit
Alle globalen Methoden Beschränkt die Gesamtzahl der gleichzeitigen globalen Vorgänge für ein Projekt. 8.000 Vorgänge im laufenden Betrieb pro Projekt
routes.insert Beschränkt die Anzahl gleichzeitiger Routenerstellungen in einem Projekt. 200 Routenerstellungen im laufenden Betrieb pro Projekt
routes.delete Beschränkt die Anzahl gleichzeitiger Routenlöschvorgänge in einem Projekt. 400 Löschvorgang im laufenden Betrieb für Routenvorgänge pro Projekt
firewalls.insert Beschränkt die Anzahl gleichzeitiger Firewallerstellungen in einem Projekt. 400 Firewall-Vorgänge im laufenden Betrieb pro Projekt
firewalls.delete Beschränkt die Anzahl gleichzeitiger Firewall-Löschvorgänge in einem Projekt. 400 Firewall-Vorgänge im laufenden Betrieb pro Projekt
snapshots.insert Beschränkt die Anzahl gleichzeitiger Snapshot-Erstellungen in einem Projekt. 8.000 Snapshot-Vorgänge im laufenden Betrieb pro Projekt
snapshots.delete Beschränkt die Anzahl gleichzeitiger Snapshot-Löschungen in einem Projekt. 4.000 Snapshot-Vorgänge während der Übertragung pro Projekt

Limits für regionale und zonale Vorgänge

Die folgenden Limits gelten für die angegebenen Vorgänge für ein Projekt in einer Region und deren Zonen:

Vorgang Beschreibung Limit
Alle regionalen Methoden Begrenzt die Gesamtzahl gleichzeitiger Vorgänge für ein Projekt in einer Region und ihren Zonen. 8.000 Vorgänge im laufenden Betrieb pro Projekt und Region.
instances.insert Beschränkt die Anzahl gleichzeitiger Instanzerstellungsvorgänge für ein Projekt in einer Region. 1.200 Einfügungsvorgänge für Instanzen im laufenden Betrieb pro Projekt und Region
instances.delete Beschränkt die Anzahl gleichzeitiger Instanzlöschvorgänge für ein Projekt in einer Region. 1.200 Instanzlöschvorgänge im laufenden Betrieb pro Projekt und Region
instances.bulkInsert Beschränkt die Anzahl gleichzeitiger Bulk-Erstellungen von Instanzen für ein Projekt in einer Region. 20 Vorgangsvorgänge für Bulk-Instanzen im laufenden Betrieb pro Projekt und Region
disks.insert Beschränkt die Anzahl gleichzeitiger Laufwerkserstellungen für ein Projekt in einer Region. 1.500 Erstellungsvorgänge von Laufwerken im laufenden Betrieb pro Projekt und Region

Best Practices

In der folgenden Checkliste sind die Best Practices zur Reduzierung von Fehlern bei unzureichenden Limits für gleichzeitige Vorgänge zusammengefasst:

Nächste Schritte