Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Lambda-Kontingente
Wichtig
Neu AWS-Konten sind reduzierte Parallelitäts- und Speicherkontingente für Lambda Functions und Lambda MicroVMs sowie reduzierte vCPU- und Anforderungsratenquoten für Lambda Web Functions. AWS erhöht diese Kontingente automatisch auf der Grundlage Ihrer Nutzung.
AWS Lambda ist so konzipiert, dass es schnell skaliert werden kann, um den Bedarf zu decken, sodass Ihre Funktionen skaliert werden können, um den Datenverkehr in Ihrer Anwendung zu bedienen. Lambda ist für kurzlebige Rechenaufgaben konzipiert, die den Status zwischen Aufrufen nicht beibehalten oder nicht darauf angewiesen sind. Code kann in einem einzigen Aufruf bis zu 15 Minuten lang ausgeführt werden (bis zu 90 Minuten für Funktionen von Lambda Managed Instances, die asynchron oder über eine beliebige Ereignisquellenzuordnung mit Ausnahme von Amazon MQ und Amazon DocumentDB aufgerufen werden), und eine einzelne Funktion kann bis zu 10.240 MB Speicher beanspruchen.
Es ist wichtig, dass Sie sich mit den Schutzmaßnahmen vertraut machen, die zum Schutz Ihres Kontos und der Workloads anderer Kunden eingerichtet wurden. Servicekontingenten sind für alle AWS Dienste verfügbar und bestehen aus festen Grenzwerten, die Sie nicht ändern können, und weichen Grenzwerten, für die Sie Erhöhungen beantragen können. Standardmäßig wird allen neuen Konten ein Kontingentprofil zugewiesen, das die Erkundung von AWS Diensten ermöglicht.
Um die Kontingente zu sehen, die für Ihr Konto gelten, navigieren Sie zum Service-Quotas-Dashboard
In folgenden Abschnitten sind Standardkontingente und Grenzwerte in Lambda nach Kategorien aufgeführt.
Themen
Datenverarbeitung und Speicherung
Lambda legt Kontingente für die Menge an Datenverarbeitung und Speicherressourcen, die Sie verwenden können, um Funktionen auszuführen und zu speichern. Kontingente für gleichzeitige Ausführungen und Speicherung gelten pro AWS-Region. Die Elastic-Network-Schnittstelle (ENI)-Kontingente gelten für jede Virtual Private Cloud (VPC), unabhängig von der Region. Die folgenden Kontingente können gegenüber ihren Standardwerten erhöht werden. Weitere Informationen finden Sie unter Beantragen einer Kontingenterhöhung im Service-Quotas-Benutzerhandbuch.
| Ressource | Standardkontingent | Kann erhöht werden bis zu |
|---|---|---|
|
Gleichzeitige Ausführungen |
1.000 |
Zehntausende |
|
Speicher für hochgeladene Funktionen (.zip-Dateiarchive) und Ebenen, die Speicher verwenden Lambda-managed . Jede Funktionsversion und Ebenenversion verbraucht Speicher. Um Speicherbeschränkungen zu vermeiden, können Sie Ihre Funktionen und Ebenen so konfigurieren, dass sie stattdessen den selbstverwalteten S3-Codespeicher verwenden. Bewährte Methoden für die Verwaltung Ihres Codespeichers finden Sie bei Serverless Land unter Monitoring Lambda code storage |
300 GB (entpackt) |
Nicht erhöhbar. Verwenden Sie den selbstverwalteten S3-Codespeicher für Speicher, der über dieses Limit hinausgeht. |
|
Speicher für als Container-Images definierten Funktionen Diese Bilder werden in Amazon ECR gespeichert. |
|
|
|
Elastic Network-Schnittstellen in der Virtual Private Cloud (VPC) AnmerkungDieses Kontingent wird mit anderen Services wie Amazon Elastic File System (Amazon EFS) geteilt. Siehe Amazon-VPC-Kontingente. |
3,000 |
Tausende |
Weitere Details zur Gleichzeitigkeit und zur datenverkehrbasierten Skalierung der Funktionsgleichzeitigkeit von Lambda finden Sie unter Die Skalierung von Lambda-Ereignisfunktionen verstehen.
Funktionskonfiguration, -bereitstellung und -ausführung
Die folgenden Kontingente gelten für die Konfiguration, Bereitstellung und Ausführung von Funktionen. Sofern nicht anders angegeben, können sie nicht geändert werden.
Anmerkung
Die Lambda-Dokumentation, die Protokollmeldungen und die Konsole verwenden die Abkürzung MB (anstelle von MiB), um auf 1 024 KB zu verweisen.
| Ressource | Quota |
|---|---|
|
Funktion Speicherzuweisung |
128 MB bis 10.240 MB (in Schritten von 1 MB). Hinweis: Lambda weist die CPU-Leistung proportional zur Menge des konfigurierten Arbeitsspeichers zu. Sie können den Arbeitsspeicher und die CPU-Leistung, die Ihrer Funktion zugewiesen sind, mit der Einstellung Arbeitsspeicher (MB) erhöhen oder verringern. Bei 1 769 MB hat eine Funktion das Äquivalent von einer vCPU. |
|
Funktion Zeitüberschreitung |
900 Sekunden (15 Minuten). Für Funktionen, die AWS Lambda Managed Instances verwenden, unterstützen asynchrone Aufrufe und Aufrufe zur Zuordnung von Ereignisquellen (außer Amazon MQ und Amazon DocumentDB) einen zulässigen Höchstwert von 5.400 Sekunden (90 Minuten). |
|
Funktion Umgebungsvariablen |
4 KB, für alle Umgebungsvariablen, die mit der Funktion verknüpft sind, im Aggregat |
|
Funktion ressourcenbasierte Richtlinie |
20 KB |
|
Funktionsebenen |
5 Ebenen |
|
Funktion – Limit für Gleichzeitigkeitsskalierung |
Für jede Funktion 1 000 Ausführungsumgebungen alle 10 Sekunden |
|
Aufrufnutzlast (Anfrage und Antwort) |
Jeweils 6 MB für Anfrage und Antwort (synchron) 200 MB für jede gestreamte Antwort (synchron) 1 MB (asynchron) 1 MB für die kombinierte Gesamtgröße von Anforderungszeile und Kopfdaten |
|
Bandbreite für gestreamte Antworten |
Unbegrenzt für die ersten 6 MB der Antwort Ihrer Funktion Für Antworten, die größer als 6 MB sind, 2 Mbit/s für den Rest der Antwort |
|
Netzwerkbandbreite pro Ausführungsumgebung |
625 Mbit/s. Für Funktionen, die nicht mit einer VPC verbunden sind, können Sie über die Service Quotas Quota-Konsole |
|
Größe des Bereitstellungspakets (ZIP-Dateiarchiv) |
50 MB (gezippt, wenn sie über die Lambda-API oder SDKs hochgeladen werden). Laden Sie größere Dateien mit Amazon S3 hoch. 50 MB (beim Hochladen über die Lambda-Konsole) 250 MB Die maximale Größe des Inhalts eines Bereitstellungspakets, einschließlich Ebenen und benutzerdefinierter Laufzeiten. (ungezippt) |
|
Größe der Container-Image-Einstellungen |
16 KB |
|
Codepaketgröße des Container-Images |
10 GB (maximale unkomprimierte Image-Größe, einschließlich aller Ebenen) |
|
Testereignisse (Konsoleneditor) |
10 |
|
|
Zwischen 512 MB und 10 240 MB, in 1-MB-Schritten. |
|
Dateibeschreibungen |
1,024 AnmerkungLambda Managed Instances verwenden ein höheres Dateideskriptorlimit von 4.096. Weitere Informationen finden Sie unter Grundlegendes zur Lambda Managed Instance-Ausführungsumgebung. |
|
Ausführung processes/threads |
1,024 AnmerkungLambda Managed Instances verwenden die standardmäßigen Prozess- und Threadlimits von Bottlerocket |
Lambda-API-Anforderungen
Die folgenden Kontingente sind Lambda-API-Anfragen zugeordnet.
| Ressource | Kontingent |
|---|---|
|
Aufrufanfragen pro Funktion pro Region (synchron) |
Jede Instance Ihrer Ausführungsumgebung kann bis zu 10 Anfragen pro Sekunde bearbeiten. Mit anderen Worten, das Gesamtaufruflimit beträgt das 10-fache Ihres Gleichzeitigkeitslimits. Siehe Die Skalierung von Lambda-Ereignisfunktionen verstehen. |
|
Aufrufanfragen pro Funktion pro Region (asynchron) |
Jede Instance Ihrer Ausführungsumgebung kann eine unbegrenzte Anzahl an Anfragen bearbeiten. Mit anderen Worten, das Gesamtlimit für Aufrufe basiert nur auf der für Ihre Funktion verfügbaren Gleichzeitigkeit. Siehe Die Skalierung von Lambda-Ereignisfunktionen verstehen. |
|
Aufrufanforderungen pro Funktionsversion oder Alias (Anfragen pro Sekunde) |
10 x zugewiesene Provisioned Concurrency AnmerkungDieses Kontingent gilt nur für Funktionen, die Provisioned Concurrency verwenden. |
|
GetFunction-API-Anforderungen |
100 Anforderungen pro Sekunde. Kann nicht erhöht werden. |
|
GetPolicy-API-Anforderungen |
15 Anforderungen pro Sekunde. Kann nicht erhöht werden. |
|
Restliche API-Anfragen der Kontrollebene (ausgenommen Aufrufe und Anfragen) GetFunction GetPolicy |
15 Anforderungen pro Sekunde über alle APIs (nicht 15 Anforderungen pro Sekunde pro API). Kann nicht erhöht werden. |
Dauerhafte Funktionen
Die folgenden Kontingente gelten für dauerhafte Funktionen. Kontingente gelten pro AWS-Region. Höhere Standardwerte gelten in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland), wie in der Tabelle angegeben. Sofern nicht anders angegeben, können diese Kontingente erhöht werden. Weitere Informationen finden Sie unter Beantragen einer Kontingenterhöhung im Service-Quotas-Benutzerhandbuch.
| Ressource | Standardkontingent |
|---|---|
|
Maximale Anzahl laufender, dauerhafter Ausführungen |
5.000.000 pro Region. 10.000.000 in den USA Ost (Nord-Virginia), den USA West (Oregon) und Europa (Irland). Dies ist ein weiches Limit, das erhöht werden kann. |
|
Maximale Anzahl dauerhafter Operationen pro dauerhafter Ausführung |
3,000 Kann nicht erhöht werden. Weitere Informationen finden Sie unter Verfügbare dauerhafte Operationen. |
|
Dauerhafter Ausführungsspeicher, geschrieben in Megabyte |
100 MB Kann nicht erhöht werden. Die kumulative Nutzlastgröße wird von dauerhaften Funktionen pro Ausführung beibehalten. Weitere Informationen finden Sie unter Dauerhafte Daten pro dauerhaftem Vorgang. |
|
Aufrufrate von Funktionen zur Initiierung dauerhafter Ausführungen |
300 Anfragen pro Sekunde. |
|
CheckpointDurableExecution-API-Anforderungen |
10.000 Anfragen pro Sekunde. 20.000 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
|
GetDurableExecution-API-Anforderungen |
30 Anfragen pro Sekunde. |
|
GetDurableExecutionHistory-API-Anforderungen |
15 Anforderungen pro Sekunde. |
|
GetDurableExecutionState-API-Anforderungen |
10.000 Anfragen pro Sekunde. 20.000 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
|
ListDurableExecutionsByFunction-API-Anforderungen |
15 Anforderungen pro Sekunde. |
|
SendDurableExecutionCallbackFailure-API-Anforderungen |
3.000 Anfragen pro Sekunde. 6.000 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
|
SendDurableExecutionCallbackHeartbeat-API-Anforderungen |
3.000 Anfragen pro Sekunde. 6.000 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
|
SendDurableExecutionCallbackSuccess-API-Anforderungen |
3.000 Anfragen pro Sekunde. 6.000 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
|
StopDurableExecution-API-Anforderungen |
300 Anfragen pro Sekunde. 600 Anfragen pro Sekunde in USA Ost (Nord-Virginia), USA West (Oregon) und Europa (Irland). |
Lambda-MicroVMs
Lambda MicroVMS legt Kontingente für Rechen-, Speicher- und API-Anfragen fest. Als anpassbar markierte Kontingente können über die Service Quotas Quotas-Konsole erhöht werden.
Anmerkung
Lambda MicroVMs unterstützen die ARM64-Architektur (AWS Graviton).
Datenverarbeitung und Speicherung
| Ressource | Standardkontingent | Einstellbar |
|---|---|---|
| Allen MicroVMs zugewiesener Speicher (pro Konto, pro Region) |
400 GB (d. h. 200 microVMs mit jeweils 2 GB konfiguriertem Speicher oder 400 microVMs mit jeweils 1 GB konfiguriertem Speicher). 1.024 GB in USA Ost (Nord-Virginia), USA West (Oregon), USA Ost (Ohio) und Asien-Pazifik (Tokio) (d. h. 512 MicroVMs mit jeweils 2 GB konfiguriertem Speicher oder 1.024 MicroVMs mit jeweils 1 GB konfiguriertem Speicher). Burstfähig bis zum Vierfachen dieses Kontingents. |
Ja |
| Maximale Ausführungsdauer pro microVM | 8 Stunden (28.800 Sekunden) | Nein |
Bilder und Versionen
| Ressource | Standardkontingent | Einstellbar |
|---|---|---|
| MicroVM-Images pro Konto pro Region | 100 | Ja |
| Versionen pro MicroVM-Image | 50 | Ja |
| Gleichzeitige Image-Builds (pro Konto, pro Region) |
5 10 in den Regionen USA Ost (Nord-Virginia), USA West (Oregon), USA Ost (Ohio) und Asien-Pazifik (Tokio) |
Ja |
Per-MicroVM Durchsatz
| Ressource | Limit | Einstellbar |
|---|---|---|
| Gleichzeitige Verbindungen pro microVM | 8 (1 vCPU), 16 (2 vCPU), 32 (4 vCPU), 64 (8 vCPU), 128 (16 vCPU) | Nein |
| Anfragen pro Sekunde pro MicroVM | 40 (4 VCPUS/8 GB), 160 (16 VCPUS/32 GB) | Nein |
API-Ratenlimits
| API-Operation | Rate (TPS) | Burst | Einstellbar |
|---|---|---|---|
RunMicrovm |
5 | 5 | Ja |
ResumeMicrovm |
5 | 5 | Ja |
SuspendMicrovm |
2 | 2 | Ja |
TerminateMicrovm |
10 | 10 | Ja |
GetMicrovm |
100 | 100 | Ja |
CreateMicrovmAuthToken |
50 | 50 | Ja |
CreateMicrovmShellAuthToken |
5 | 5 | Ja |
Anmerkung
TPS = Transaktionen pro Sekunde. Diese Ratenlimits gelten pro Konto und Region. Versuchen Sie erneut, gedrosselte Anfragen mithilfe eines exponentiellen Backoffs mit Jitter auszuführen.
Lambda-Webfunktionen
Mit AWS Lambda Web Functions führen Sie Webanwendungen und API-Backends als serverlose HTTP-Server aus. Kontingente sind die Höchstwerte für Ressourcen und Einstellungen von Web Functions. Beispiele hierfür sind die Anzahl der Endpunkte pro Webfunktion, der Arbeitsspeicher einer Ausführungsumgebung und die Anfragen pro Sekunde für Ihr Konto. Wenn Sie sie vor der Bereitstellung kennen, können Sie Ihre Anwendung besser entwerfen und ihre Einstellungen für die Endpunkt-Skalierung entsprechend anpassen. Die meisten Kontingente haben Standardwerte, die für typische Workloads funktionieren und nicht geändert werden können. Sie können Erhöhungen für die anpassbaren Kontokontingente beantragen, die je nach Konto variieren können.
Die Kontingente für Webfunktionen gelten in den folgenden Bereichen:
-
Pro Webfunktion — Endpunkte und Versionen.
-
Pro Endpunkt — Maximale Anzahl an Umgebungen, Ratenlimit und Anzahl der Revisionen, bei denen der Datenverkehr gemeinsam genutzt wird.
-
Pro Revision — Größe des Bereitstellungspakets, Größe der Umgebungsvariablen und Zeitlimit für Anfragen.
-
Pro Ausführungsumgebung — vCPUs, Arbeitsspeicher, gleichzeitige Anfragen,
/tmpVerzeichnisgröße, Dateideskriptoren, Prozesse und Threads sowie Initialisierungs-Timeout. -
Pro Anfrage — Größe des Anforderungsheaders.
-
Pro Konto, in jedem AWS-Region — Anfragen pro Sekunde und Arm64-vCPUs.
Anmerkung
Rufen Sie an, um die Kontingentwerte zu erfahren, die für Ihr Konto in einer Region gelten. GetWebAccountSettings Informationen zur Überwachung der Nutzung anhand dieser Kontingente finden Sie unterRegionale Nutzungs- und Drosselungsmetriken.
Kontingente für Webfunktionen, Revisionen und Ausführungsumgebungen
In der folgenden Tabelle sind die Kontingente für jede Webfunktion, Revision, Ausführungsumgebung und Anforderung aufgeführt.
| Ressource | Standardkontingent | Einstellbar |
|---|---|---|
| Endpunkte pro Webfunktion | 10 | Nein |
| Revisionen pro Webfunktion | 50 (automatisches Bereinigungsziel). Die Anzahl kann vorübergehend 50 überschreiten. Siehe Revisionsgrenzen und automatische Bereinigung. | Nein |
| Größe des Bereitstellungspakets | 512 MB (entpackt) | Nein |
| Größe der Umgebungsvariablen | 32 KB | Nein |
| Header-Größe anfordern | 128 KiB | Nein |
/tmpGröße des Verzeichnisses |
512 MB | Nein |
| vCPUs pro Ausführungsumgebung | 2 | Nein |
| Speicher pro Ausführungsumgebung | 2 GB | Nein |
Gleichzeitige Anfragen pro Umgebung () maxConcurrencyPerEnvironment |
64 (Bereich 1—128). Siehe Dynamisches Parallelitätslimit pro Umgebung. | Nein |
| Anforderungstimeout | 30 Sekunden (Bereich 3—900) | Nein |
| Timeout für die Initialisierung (Zeit, bis Ihr Server mit der Überwachung beginnt) | 10 Sekunden | Nein |
| Dateideskriptoren pro Ausführungsumgebung | 1,024 | Nein |
| Prozesse und Threads pro Ausführungsumgebung | 1,024 | Nein |
Endpunktkontingente
In der folgenden Tabelle sind die Endpunkt-Kontingente aufgeführt.
| Ressource | Standardkontingent | Einstellbar |
|---|---|---|
Maximale Anzahl von Umgebungen pro Endpunkt (scalingConfig.maxEnvironments) |
Optional. Standardmäßig nicht festgelegt. Gültige Werte 2—10.000. In jeder Region durchgesetzt. Das vCPU-Kontingent des Kontos kann den Endpunkt auf weniger Ausführungsumgebungen beschränken. | Nein |
Ratenlimit pro Endpunkt () throttleConfig.rateLimit |
Optional. Standardmäßig nicht festgelegt. Gültige Werte sind 0, 100—1.000 in Schritten von 100 und 2.000—10.000 in Schritten von 1.000 Anfragen pro Sekunde. Lambda setzt dieses Limit in jeder Region separat durch. Ein Wert von 0 blockiert den gesamten Verkehr. Wenn nicht festgelegt, gilt das Kontingent pro Endpunkt von 10.000 Anfragen pro Sekunde. | Nein |
| Maximale Anzahl von Revisionen pro Endpunkt (Revisionsgewichte) | 2 | Nein |
| Gewichtsbereich der Revision | 1-100 | Nein |
Kontingente
In der folgenden Tabelle sind die Kontokontingente aufgeführt, die für jedes Konto gelten AWS-Region.
| Ressource | Standardkontingent | Einstellbar |
|---|---|---|
| Anfragen pro Sekunde pro Konto | 100 000 | Ja |
| Arm64-vCPUs für Ausführungsumgebungen, pro Konto, pro Region | 2.000. Jede Ausführungsumgebung verwendet 2 vCPUs. | Ja |
Netzwerkbeschränkungen
Die folgenden Einschränkungen gelten für Web Function-Netzwerke.
| Item | Einschränkung |
|---|---|
| Netzwerkstecker für ausgehende Verbindungen pro Version | 0 oder 1 |
| Referenz des Steckverbinders | Version-qualified ARN |
| Connector-Konto und Region | Entspricht der Webfunktion |
| Ressourcentyp der Connector-Berechnung | Genau einer; verwenden WebFunction |
| Den Konnektor einer Revision ändern | Eine neue Revision erstellen |
| Änderungen, die über einen Endpunkt weitergeleitet wurden | 1 oder 2 |
| Endpunkttypen, die ausgehende Netzwerkkonnektoren unterstützen | Nur HomeRegion |
| Automatische Bereitstellung | LatestRevisionoder Disabled fürHomeRegion; Disabled nur für MultiRegion und PerRegion |
| Endpunkttyp und Region festgelegt | Bei der Endpunkterstellung behoben |
| Direkter öffentlicher Ausgang | Nur IPv4 |
| Privater Endpunktzugriff mit AWS PrivateLink | Nicht verfügbar |
Sonstige Services
Kontingente für andere Dienste wie AWS Identity and Access Management (IAM), Amazon CloudFront (Lambda @Edge) und Amazon Virtual Private Cloud (Amazon VPC) können sich auf Ihre Lambda-Funktionen auswirken. Weitere Informationen finden Sie unter AWS-Service -Kontingent im Allgemeine Amazon Web Services-Referenz und Lambda mit Ereignissen von anderen aufrufen AWS service.
Viele Anwendungen, die Lambda beinhalten, verwenden mehrere AWS Dienste. Da verschiedene Services unterschiedliche Kontingente für verschiedene Funktionen haben, kann es schwierig sein, diese Kontingente für Ihre gesamte Anwendung zu verwalten. API Gateway hat z. B. eine standardmäßige Drosselungsgrenze von 10.000 Anforderungen pro Sekunde, während Lambda eine standardmäßige Gleichzeitigkeitsbeschränkung von 1.000 Anforderungen pro Sekunde hat. Aufgrund dieser Diskrepanz ist es möglich, dass mehr eingehende Anfragen von API Gateway eingehen, die Lambda verarbeiten kann. Sie können dies beheben, indem Sie eine Erhöhung der Lambda-Gleichzeitigkeitsbeschränkung auf das erwartete Datenverkehrsaufkommen beantragen.
Durch Auslastungstests Ihrer Anwendung können Sie die Leistung Ihrer Anwendung durchgängig überwachen, bevor Sie sie in der Produktion einsetzen. Während eines Lasttests können Sie alle Kontingente ermitteln, die einen begrenzenden Faktor für das erwartete Verkehrsaufkommen darstellen und entsprechende Maßnahmen ergreifen.