View a markdown version of this page

Lambda-Kontingente - AWS Lambda

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

Neue AWS-Konten haben die Parallelität und die Speicherkontingente für Lambda Functions und Lambda MicroVMs reduziert. 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 und eine einzelne Funktion kann bis zu 10 240 MB Speicher beanspruchen.

Es ist wichtig, die Schutzmaßnahmen zu verstehen, 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. Hier können Sie Service Quotas anzeigen, eine Erhöhung des Service-Kontingents anfordern und die aktuelle Auslastung anzeigen. Von hier aus können Sie zu einem bestimmten AWS Dienst wie Lambda aufschlüsseln:

Anwendungsdesign, Abbildung 1

In folgenden Abschnitten sind Standardkontingente und Grenzwerte in Lambda nach Kategorien aufgeführt.

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.

Siehe Amazon-ECR-Servicekontingente.

Elastic Network-Schnittstellen in der Virtual Private Cloud (VPC)

Anmerkung

Dieses Kontingent wird mit anderen Services wie Amazon Elastic File System (Amazon EFS) geteilt. Siehe Amazon-VPC-Kontingente.

500

Tausende

Maximale Anzahl laufender, langlebiger Ausführungen

1 000 000

Millionen

Weitere Details zur Gleichzeitigkeit und zur datenverkehrbasierten Skalierung der Funktionsgleichzeitigkeit von Lambda finden Sie unter Verstehen der Skalierung von Lambda-Funktionen.

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)

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

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

/tmp-Verzeichnisspeicher

Zwischen 512 MB und 10 240 MB, in 1-MB-Schritten.

Dateibeschreibungen

1,024

Anmerkung

Lambda Managed Instances verwenden ein höheres Dateideskriptorlimit von 4.096. Weitere Informationen finden Sie unter Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances.

Ausführung processes/threads

1,024

Anmerkung

Lambda Managed Instances verwenden die standardmäßigen Prozess- und Threadlimits von Bottlerocket. Weitere Informationen finden Sie unter Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances.

Maximale Anzahl dauerhafter Operationen pro dauerhafter Ausführung

3,000

Anmerkung

Weitere Informationen finden Sie unter Verfügbare dauerhafte Operationen.

Dauerhafter Ausführungsspeicher, geschrieben in Megabyte

100 MB

Anmerkung

Die kumulative Nutzlastgröße wird von dauerhaften Funktionen pro Ausführung beibehalten. Weitere Informationen finden Sie unter Dauerhafte Daten pro dauerhaftem Vorgang.

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 Verstehen der Skalierung von Lambda-Funktionen.

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 Verstehen der Skalierung von Lambda-Funktionen.

Aufrufanforderungen pro Funktionsversion oder Alias (Anfragen pro Sekunde)

10 x zugewiesene Provisioned Concurrency

Anmerkung

Dieses 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.

CheckpointDurableExecution-API-Anforderungen

1.000 Anfragen pro Sekunde.

GetDurableExecution-API-Anforderungen

30 Anfragen pro Sekunde.

GetDurableExecutionHistory-API-Anforderungen

15 Anforderungen pro Sekunde.

GetDurableExecutionState-API-Anforderungen

1.000 Anfragen pro Sekunde.

ListDurableExecutionsByFunction-API-Anforderungen

15 Anforderungen pro Sekunde.

SendDurableExecutionCallbackFailure-API-Anforderungen

300 Anfragen pro Sekunde.

SendDurableExecutionCallbackHeartbeat-API-Anforderungen

300 Anfragen pro Sekunde.

SendDurableExecutionCallbackSuccess-API-Anforderungen

300 Anfragen pro Sekunde.

StopDurableExecution-API-Anforderungen

30 Anfragen pro Sekunde.

Restliche API-Anfragen der Kontrollebene (ohne Aufrufe und GetPolicy Anfragen) GetFunction

15 Anforderungen pro Sekunde über alle APIs (nicht 15 Anforderungen pro Sekunde pro API). Kann nicht erhöht werden.

Lambda-MikroVMS

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).

Burst-fä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.

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, an denen Lambda beteiligt ist, 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, als 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 auch die Leistung einer Anwendung von Ende zu Ende überwachen, bevor sie in der Produktion eingesetzt wird. 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.