Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Kontingente
In diesem Dokument werden die Kontingentlimits für Cloud Run Functions beschrieben.
Kontingente für Cloud Run-Funktionen umfassen vier Bereiche:
Ressourcenlimits
Diese beeinflussen die Gesamtmenge der Ressourcen, die Ihre Funktionen verbrauchen können.
Zeitlimits
Diese beeinflussen die maximale Ausführungsdauer der einzelnen Funktionen.
Ratenlimits
Diese beeinflussen die Rate, mit der Sie die Cloud Run Functions API aufrufen können, um Ihre Funktionen zu verwalten.
Netzwerklimits
Sie wirken sich auf die Limits für ausgehende Verbindungen und Instanzen aus.
Die verschiedenen Arten von Limits werden im Folgenden näher beschrieben.
Die Unterschiede zwischen den Limits für Cloud Run-Funktionen (1. Generation) und Cloud Run-Funktionen (2. Generation) werden gegebenenfalls aufgeführt.
Ressourcenlimits
Ressourcenlimits beeinflussen die Gesamtmenge der Ressourcen, die Ihre Funktionen verbrauchen können.
Der regionale Bereich gilt pro Projekt und jedes Projekt hat seine eigenen Limits.
Kontingent
Beschreibung
Limit (1. Generation)
Limit (2. Generation)
Kann erhöht werden
Umfang
Anzahl der Funktionen
Die Gesamtzahl der Funktionen, die pro Region bereitgestellt werden können
1.000
1.000 minus die Anzahl der bereitgestellten Cloud Run-Dienste
Nein
pro Region
Max. Bereitstellungsgröße
Die maximale Größe einer einzelnen Funktionsbereitstellung
100 MB (komprimiert) für Quellen
500 MB (unkomprimiert) für Quellen und Module
–
Nein
pro Funktion
Max. unkomprimierte Größe einer HTTP-Anfrage
Daten, die an HTTP-Funktionen in einer HTTP-Anfrage gesendet werden
10 MB
32 MB
Nein
pro Aufruf
Max. unkomprimierte Größe einer HTTP-Antwort
Daten, die von HTTP-Funktionen in einer HTTP-Antwort gesendet werden
10 MB
10 MB für Streamingantworten.
32 MB für Antworten ohne Streaming.
Nein
pro Aufruf
Max. Ereignisgröße für ereignisgesteuerte Funktionen
Daten, die in Ereignissen an Hintergrundfunktionen gesendet werden
10 MB
512 KB für Eventarc-Ereignisse
10 MB für Legacy-Ereignisse.
Nein
pro Ereignis
Max. Funktionsspeicher
Größe des Arbeitsspeichers, den jede Funktionsinstanz verwenden kann
8 GiB
32 GiB
Nein
pro Funktion
Max. Projektspeicher
Speicherplatz in By, den ein Projekt nutzen kann. Er wird anhand der Gesamtsumme des vom Nutzer angeforderten Arbeitsspeichers über alle Funktionsinstanzen hinweg in einem Zeitraum von einer Minute gemessen.
Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.
–
Ja
pro Projekt und Region
Max. CPU-Auslastung des Projekts
Die CPU-Kapazität in Milli-vCPUs, die ein Projekt nutzen kann. Er wird anhand der Summe der vom Nutzer angeforderten CPU-Zeit über alle Funktionsinstanzen hinweg in einem Zeitraum von einer Minute gemessen.
Hängt von der ausgewählten Region ab. Dieses Limit kann in Regionen mit hoher Kapazität höher oder in kürzlich geöffneten Regionen niedriger sein.
–
Ja
pro Projekt und Region
Zeitlimits
Kontingent
Beschreibung
Limit (1. Generation)
Limit (2. Generation)
Kann erhöht werden
Umfang
Max. Funktionsdauer
Der maximale Zeitraum, über den eine Funktion ausgeführt werden kann, bevor sie zwangsweise beendet wird.
540 Sekunden
60 Minuten für HTTP-Funktionen.
9 minutes for event-driven functions.
Nein
pro Aufruf
Ratenlimits
Kontingent
Beschreibung
Limit (1. Generation)
Limit (2. Generation)
Kann erhöht werden
Umfang
API-Aufrufe (READ)
Aufrufe zum Beschreiben oder Auflisten von Funktionen über die Cloud Run Functions API.
5.000 pro 100 Sekunden
1.200 pro 60 Sekunden
Nur für die 1. Generation
pro Projekt (1. Generation)
pro Region (2. Generation)
API-Aufrufe (WRITE)
Aufrufe zum Bereitstellen oder Löschen von Funktionen über die Cloud Run Functions API.
Informationen zu den Limits für Netzwerkanfragen und Bandbreiten von Cloud Run-Funktionen (2. Generation) finden Sie unter Netzwerklimits.
Für Cloud Run Functions (1. Generation) gelten die folgenden Netzwerklimits:
Ausgehende Verbindungen pro Sekunde und Instanz: 500 (kann nicht erhöht werden)
Ausgehende DNS-Auflösungen pro Sekunde und Instanz: 100 (kann nicht erhöht werden)
Maximale Pakete pro Sekunde und Instanz: 80.000
Maximale Bits pro Sekunde und Instanz: 100.000.000
Skalierbarkeit
Funktionen von Cloud Run Functions, die über HTTP aufgerufen werden, lassen sich schnell für die Verarbeitung von eingehendem Traffic skalieren, während Hintergrundfunktionen mehr schrittweise skaliert werden. Die Fähigkeit einer Funktion zum Hochskalieren wird von einigen Faktoren bestimmt, darunter:
Die Ausführungsdauer einer Funktion (Funktionen mit kurzer Ausführungsdauer lassen sich im Allgemeinen für die Verarbeitung einer größeren Anzahl gleichzeitiger Anfragen hochskalieren).
Die Zeit, die eine Funktion nach einem Kaltstart zur Initialisierung benötigt.
Die Fehlerrate Ihrer Funktion.
Vorübergehende Faktoren, wie z. B. die regionale Last oder die Rechenzentrumskapazität.
Für Hintergrundfunktionen gelten die unten näher erläuterten zusätzlichen Limits. HTTP-Funktionen der 1. Generation sind davon nicht betroffen. Das standardmäßige Limit für die maximale Anzahl an Instanzen für HTTP-Funktionen der 2. Generation beträgt 100 und kann auf 1.000 erhöht werden. Für HTTP-Funktionen der 1. Generation gibt es kein Standardlimit für die maximale Anzahl von Instanzen.
Zur Vermeidung unbegrenzter Skalierungsereignisse mit HTTP-Funktionen der 1. Generation empfehlen wir die Festlegung eines Limits, z. B. 3.000.
Zusätzliche Kontingente für Hintergrundfunktionen
Kontingent
Beschreibung
Limit
Kann erhöht werden
Umfang
Produktversion
Maximale Anzahl gleichzeitiger Aufrufe
Die maximale Anzahl gleichzeitiger Aufrufe einer einzelnen Funktion Beispiel: Wenn die Verarbeitung jedes Ereignisses 100 Sekunden dauert, ist die Aufrufrate im Durchschnitt auf 30 pro Sekunde begrenzt.
3.000
Ja
pro Funktion
Nur 1. Generation
Maximale Aufrufrate
Die maximale Rate von Ereignissen, die von einer einzelnen Funktion verarbeitet werden. Beispiel: Wenn die Verarbeitung jedes Ereignisses 100 ms dauert, ist die Aufrufrate auf 1.000 Aufrufe pro Sekunde begrenzt, auch wenn durchschnittlich nur 100 Anfragen gleichzeitig verarbeitet werden.
1.000 pro Sekunde
Nein
pro Funktion
Nur 1. Generation
Maximale Datengröße gleichzeitiger Ereignisse
Die maximale Gesamtgröße eingehender Ereignisse für gleichzeitige Aufrufe einer einzelnen Funktion. Beispiel: Wenn Ereignisse eine Größe von 1 MB haben und ihre Verarbeitung 10 Sekunden dauert, liegt die Durchschnittsrate bei 1 Ereignis pro Sekunde, weil das 11. Ereignis nicht verarbeitet wird, bis die Verarbeitung von einem der ersten 10 Ereignisse abgeschlossen ist.
10 MB
Nein
pro Funktion
1. Generation und 2. Generation
Maximaler Durchsatz eingehender Ereignisse
Der maximale Durchsatz eingehender Ereignisse für eine einzelne Funktion. Beispiel: Wenn Ereignisse eine Größe von 1 MB haben, kann die Aufrufrate maximal 10 pro Sekunde betragen, selbst wenn die Funktionen innerhalb von 100 ms abgeschlossen werden.
10 MB pro Sekunde
Nein
pro Funktion
1. Generation und 2. Generation
Wenn Sie ein Kontingentlimit erreichen
Wenn eine Funktion eine zugeordnete Ressource vollständig verbraucht hat, ist sie erst nach einer Erneuerung bzw. Erweiterung des Kontingents wieder verfügbar. Dies kann bedeuten, dass diese sowie alle anderen Funktionen im selben Projekt bis dahin nicht funktionieren.
Eine Funktion gibt den HTTP-Fehlercode 500 zurück, wenn eine der Ressourcen über dem Kontingent liegt und die Funktion daher nicht ausgeführt werden kann.
Auf der
Seite „Kontingente“ in Cloud Run Functions können Sie Kontingente über die hier aufgeführten Standardwerte hinaus erhöhen. Wählen Sie dazu die Kontingente aus, die Sie ändern möchten, klicken Sie auf Kontingente bearbeiten, geben Sie Ihre Nutzerdaten an, wenn Sie dazu aufgefordert werden, und legen Sie die neuen Limits für die ausgewählten Kontingente fest.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-19 (UTC)."],[[["\u003cp\u003eCloud Run functions have various quota limits spanning resource, time, rate, and networking categories, which define the operational boundaries for these functions.\u003c/p\u003e\n"],["\u003cp\u003eResource limits, such as the number of functions, deployment size, memory, and CPU, constrain the total resources a project's functions can use, with some differences between 1st and 2nd generation functions.\u003c/p\u003e\n"],["\u003cp\u003eTime limits, such as the maximum function duration, dictate how long a function can run before being forcibly terminated, with different limits for HTTP and event-driven functions in 2nd generation.\u003c/p\u003e\n"],["\u003cp\u003eRate limits regulate the frequency of API calls for managing Cloud Run functions, with different limits for read, write, and call operations, and while write and call API quotas cannot be increased, it is possible for 1st gen to increase the READ quota.\u003c/p\u003e\n"],["\u003cp\u003eNetworking limits, including outbound connections, DNS resolutions, and data transfer rates, set the parameters for how Cloud Run functions can interact with external networks, and they vary between 1st and 2nd generation functions.\u003c/p\u003e\n"]]],[],null,["# Quotas\n======\n\nThis document describes the quota limits for Cloud Run functions.\n| To increase quotas above the defaults listed here, go to the [Cloud Run functions Quotas Page](https://console.cloud.google.com/iam-admin/quotas?service=cloudfunctions.googleapis.com&usage=ALL&project=_), select the quotas you want to modify, click **Edit quotas**, supply your user information if prompted, and enter the new quota limit for each quota you selected.\n\nQuotas for Cloud Run functions encompass 4 areas:\n\n- Resource Limits\n\n These affect the total amount of resources your functions can consume.\n- Time Limits\n\n These affect how long things can run.\n- Rate Limits\n\n These affect the rate at which you can call the Cloud Run functions API\n to manage your functions.\n- Networking Limits\n\n These affect outbound connection and instance limits.\n\nThe different types of limits are described in more detail below.\nDifferences between limits for Cloud Run functions (1st gen) and\nCloud Run functions (2nd gen) are noted where applicable.\n\nResource Limits\n---------------\n\nResource limits affect the total amount of resources your functions can consume.\nThe regional scope is per project, and each project maintains its own limits.\n\n| **Note:** If you are triggering a function using Pub/Sub, either via [event-driven functions](/functions/docs/writing#event-driven_functions) or as the [HTTP target](/functions/docs/writing#http_functions) of a push subscription, be aware that Pub/Sub messages are base64-encoded. A 10 MB Pub/Sub message - the [maximum size](/pubsub/quotas) supported - is larger than 10 MB once it is encoded, and can thus exceed the Cloud Run functions max size limit.\n\nTime Limits\n-----------\n\nRate Limits\n-----------\n\n| ^1^ You cannot increase the WRITE quota. Insufficient quota generally occurs due to one of the following:\n|\n| - Use of a CI/CD system that deploys many functions concurrently or sequentially at a high rate.\n| - Use of the Firebase CLI to deploy multiple functions simultaneously.\n|\n| In each case, you can avoid hitting this quota by changing the rate of\n| deployments. For example, if you are deploying using the Firebase CLI,\n| [use\n| the `--only` flag to deploy individual functions](https://firebase.google.com/docs/cli/#deploy_specific_functions).\n| ^2^ The CALL API only applies to Cloud Run functions (1st gen). You cannot increase the CALL quota. Insufficient quota generally occurs if you mistakenly use this API to invoke your functions in production. Please keep in mind that this API is meant for testing with the Google Cloud console or [`gcloud functions call`](//cloud.google.com/sdk/gcloud/reference/functions/call) CLI, and it cannot handle heavy traffic.\n\nNetworking limits\n-----------------\n\nFor information about Cloud Run functions (2nd gen) networking request and\nbandwidth limits, see [Networking limits](https://cloud.google.com/run/quotas#networking_limits).\n\nThe following networking limits apply to Cloud Run functions (1st gen):\n\n- Outbound connections per second per instance: 500 (cannot be increased)\n- Outbound DNS resolutions per second per instance: 100 (cannot be increased)\n- Maximum packets per second per instance: 80,000\n- Maximum bits per second per instance: 100,000,000\n\nScalability\n-----------\n\nCloud Run functions invoked by HTTP scale up quickly to handle incoming traffic,\nwhile background functions scale more gradually. A function's ability to scale\nup is dictated by a few factors, including:\n\n- The amount of time it takes for a function's execution to complete (short-running functions can generally scale up to handle more concurrent requests).\n- The amount of time it takes for a function to initialize on [cold start](/functions/docs/bestpractices/tips#use_dependencies_wisely).\n- Your function's error rate.\n- Transient factors, such as regional load and data center capacity.\n\n- Your configuration as defined by\n [minimum instances](/functions/docs/configuring/min-instances),\n [maximum instances](/functions/docs/configuring/max-instances), and\n [concurrency](/functions/docs/configuring/concurrency) (concurrency is 2nd gen\n only).\n\n[Background functions](/functions/docs/writing/background) have additional limits, as explained below. These limits do not apply to 1st gen [HTTP\nfunctions](/functions/docs/writing/http). The default [maximum instances limit](/functions/docs/configuring/max-instances) for 2nd gen HTTP functions is 100 and can be increased to 1,000. There is no default maximum instances limit for 1st gen HTTP functions. To avoid unbounded scaling events with 1st gen HTTP functions, we recommend [setting a limit](/functions/docs/configuring/max-instances#setting_maximum_instances_limits), for example, 3000.\n\n\u003cbr /\u003e\n\n### Additional quotas for background functions\n\nWhen you reach a quota limit\n----------------------------\n\nWhen a function consumes all of an allocated resource, the resource becomes\nunavailable until the quota is refreshed or increased. This may mean that your\nfunction and all other functions in the same project will not work until then.\nA function returns an HTTP 500 error code when one of the resources is\nover quota and the function cannot execute.\n\nTo increase quotas above the defaults listed here, go to the\n[Cloud Run functions Quotas page](https://console.cloud.google.com/iam-admin/quotas?service=cloudfunctions.googleapis.com&usage=ALL&project=_), select the quotas you want to modify, click\n**Edit quotas**, supply your user information if prompted, and enter the new\nquota limit for each quota you selected."]]
