Skalierungsverhalten für Lambda Web Functions

Lambda skaliert den Endpunkt Ihrer Web Function automatisch, sobald der Datenverkehr eingeht. Es skaliert in zwei Dimensionen:

• Anzahl der Umgebungen — Lambda fügt mehr Ausführungsumgebungen hinzu, bis zumaxEnvironments.

• Gleichzeitige Anfragen pro Umgebung — Jede Umgebung verarbeitet mehrere Anfragen gleichzeitig. Lambda verwaltet ein dynamisches Parallelitätslimit pro Umgebung, das auf Ihrer Ressourcennutzung basiert. Sie steuern die Obergrenze dieses dynamischen Limits mithilfe von. maxConcurrencyPerEnvironment Weitere Informationen finden Sie unter Dynamisches Parallelitätslimit pro Umgebung.

Sie können auch für einen Endpunkt festlegenrateLimit, dass dessen Anforderungsrate begrenzt wird. Diese Einstellung ist optional und wird angewendet, bevor Anfragen Ihre Umgebungen erreichen.

Ein Endpunkt skaliert von Null aus. Wenn kein Verkehr vorhanden ist, führt Lambda keine Umgebungen aus. Auf dieser Seite werden die Skalierungseinstellungen eines Endpunkts, die zugehörigen Kontokontingente und die Auswahl von Werten zur Kosten- oder Leistungsoptimierung erläutert.

Ausführungsumgebungen

Eine Ausführungsumgebung ist eine isolierte Recheninstanz, auf der Ihr HTTP-Server ausgeführt wird. Jede Umgebung hat ihren eigenen Speicher, ihr eigenes Dateisystem und ihren eigenen Prozessraum. Informationen darüber, wie Lambda eine Ausführungsumgebung initialisiert, wiederverwendet und herunterfährt, finden Sie unter. Lebenszyklus der Ausführungsumgebung

Lambda erstellt und entfernt Umgebungen automatisch auf der Grundlage des Datenverkehrs:

• Wenn der Verkehr zunimmt, erstellt Lambda zusätzliche Umgebungen, um den Verkehrsbedarf zu decken.

• Wenn der Verkehr abnimmt, entleert Lambda nicht ausgelastete Umgebungen und entfernt sie.

• Wenn kein Verkehr vorhanden ist, entfernt Lambda alle Umgebungen. Der Endpunkt wird auf Null skaliert.

Es gibt keine Einstellung für eine minimale oder reservierte Umgebung. Ein Endpunkt wird immer von Null aus skaliert, wenn Datenverkehr eingeht. Um Kaltstarts bei geringem Anstieg des Datenverkehrs zu vermeiden, skaliert Lambda die Ausführungsumgebungen automatisch vor dem Bedarf, um Reservekapazitäten (Headroom) für eingehenden Datenverkehr zu erhalten. Wenn Umgebungen nicht ausgelastet sind, skaliert Lambda sie nach unten, auch auf Null.

Dynamisches Parallelitätslimit pro Umgebung

Das dynamische Parallelitätslimit pro Umgebung ist ein Lambda-managed Limit für die Anzahl der Anfragen, die eine einzelne Ausführungsumgebung gleichzeitig verarbeitet. Basierend auf dem Ressourcenverbrauch Ihrer Funktion passt Lambda diesen Grenzwert automatisch an, um Effizienz und Leistung zu optimieren. Lambda skaliert neue Umgebungen, wenn bestehende Umgebungen an ihre Grenzen stoßen. Wenn das Limit verhindert, dass alle vorhandenen Umgebungen mehr Anfragen annehmen, werden Anfragen in eine Warteschlange gestellt und auf die nächste verfügbare Umgebung gewartet.

Sie konfigurieren das dynamische Limit nicht direkt. Stattdessen können Sie ihm eine Obergrenze zuweisen, indem Sie ihn für die Revision festlegenmaxConcurrencyPerEnvironment. Der dynamische Grenzwert von Lambda kann unter diesem Wert liegen, ihn jedoch nie überschreiten. Wenn Sie beispielsweise maxConcurrencyPerEnvironment auf 32 setzen, leitet Lambda maximal 32 gleichzeitige Anfragen an eine beliebige Umgebung weiter, auch wenn die Umgebung Kapazität für mehr hat.

Die meisten Anwendungen können sich auf das dynamische Limit verlassen, ohne sich zu ändern. maxConcurrencyPerEnvironment Hinweise dazu, wann es geändert werden sollte, finden Sie unterSkalierungseinstellungen wählen.

Einstellungen skalieren

Drei Einstellungen steuern, wie Lambda Ihre Webfunktion skaliert. Sie konfigurieren jede Einstellung entweder am Endpunkt oder in der Revision.

Einstellung	Konfiguriert am	Gültiger Bereich	Standard	Description
maxConcurrencyPerEnvironment	Revision	1—128	64	Die Obergrenze des Lambda-managed dynamischen Parallelitätslimits pro Umgebung. Lambda passt die tatsächliche Parallelität pro Umgebung automatisch an, sodass sich die meisten Anwendungen auf das dynamische Limit verlassen können, ohne diesen Wert zu ändern.
maxEnvironments	Endpoint	Optional. 2—10.000	Keine	Schränkt die Anzahl der Ausführungsumgebungen für den jeweiligen Endpunkt ein. AWS-Region Steuert die horizontale Skalierung. Die Skalierung der Endpunktumgebung ist immer durch das verfügbare vCPU-Kontingent für Konten begrenzt, auch wenn maxEnvironments es nicht festgelegt ist.
rateLimit	Endpoint	Optional. 0—10.000	Keine	Beschränkt die Eingangsrate der Anfragen auf dem Endpunkt, jeweils in Anfragen pro Sekunde. AWS-Region Werte bis 1.000 müssen ein Vielfaches von 100 sein, und Werte über 1.000 müssen ein Vielfaches von 1.000 sein. Ein Wert von 0 blockiert den gesamten Verkehr. Anfragen, die das effektive Ratenlimit überschreiten, erhalten eine HTTP 429-Antwort (Too Many Requests). Wenn nicht festgelegt, wird die Eingangsrate des Endpunkts durch das Kontingent pro Endpunkt pro Konto begrenzt.

maxEnvironmentsund rateLimit sind optionale Endpunkteigenschaften. Sie können sie aktualisieren, ohne eine neue Revision zu erstellen. Standardmäßig ist keines von beiden festgelegt. Ein großer Wert garantiert maxEnvironments nicht, dass der Endpunkt so weit skaliert werden kann. Die Umgebungsskalierung ist immer durch das regionale vCPU-Kontingent des Kontos begrenzt. Ein Wert rateLimit von 0 blockiert den gesamten Datenverkehr. Details hierzu finden Sie unter Drosselung. Die Anforderungsrate für Endgeräte ist immer durch das Kontingent für die Anforderungsrate des Kontos begrenzt, auch wenn dieses nicht festgelegt rateLimit ist. Die Kontingente finden Sie im nächsten Abschnitt.

Um maxEnvironments oder zu ändernrateLimit, führen Sie den Befehl aws lambda-web update-web-function-endpoint mit dem --throttle-config Parameter --scaling-config or aus, z. B. --scaling-config '{"maxEnvironments": 50}' oder--throttle-config '{"rateLimit": 8000}'. Lassen Sie einen Parameter weg, um seinen aktuellen Wert beizubehalten. Um einen von Ihnen festgelegten Wert zu löschen, übergeben Sie ein leeres Objekt, z. B. --scaling-config '{}' Weitere Informationen finden Sie unterAktualisierung eines Endpunkts. maxConcurrencyPerEnvironmentist eine Revisionseinstellung. Um sie zu ändern, erstellen Sie eine neue Revision. Ob die neue Version Datenverkehr empfängt, hängt vom automatischen Bereitstellungsmodus des Endpunkts ab. Weitere Informationen finden Sie unter Eine Revision erstellen.

Kontingente

Diese Kontingente gelten pro AWS-Region. Sie gelten immer zusätzlich zu Ihren optional konfigurierten Endpunktlimits.

• Per-endpoint Ratenlimit — 10.000 Anfragen pro Sekunde (RPS).

• Gesamtratenlimit für Konten — 100.000 RPS für alle Endpunkte in der Region.

• Konto-vCPU-Limit — 2.000 vCPUs auf allen Endpunkten in der Region. Jede Ausführungsumgebung verbraucht 2 vCPUs, sodass dieses Kontingent die Gesamtzahl der Umgebungen pro AWS-Region Konto begrenzt.

Informationen zu den aktuellen Kontingentwerten und dazu, wie Sie eine Erhöhung beantragen können, finden Sie unter. Lambda-Webfunktionen

Wie die Skalierungseinstellungen interagieren

Diese drei Skalierungseinstellungen werden unabhängig voneinander verwendet, um die Skalierung Ihres Endpunkts zu bestimmen. Mit Ausnahme der Kontokontingente skaliert jeder Endpunkt unabhängig, auch Endgeräte, die zu derselben Webfunktion gehören.

Gesamtkapazität für Parallelität

Sie können sich vorstellen, dass die maximale Anzahl von In-Flight-Anfragen am Endpunkt ungefähr dem maxEnvironments Mehrfachen des dynamischen Parallelitätslimits pro Umgebung entspricht, das Lambda derzeit zulässt. Das Maximum, das der Endpunkt gleichzeitig verarbeiten kann, ist ×. maxEnvironments maxConcurrencyPerEnvironment Er erreicht diese Zahl nur, wenn er maxEnvironments Umgebungen ausführt und jede Umgebung maxConcurrencyPerEnvironment Anfragen bearbeitet. Wenn maxEnvironments nicht festgelegt, skaliert der Endpunkt je nach Bedarf bis zum vCPU-Kontingent des Kontos.

Gesamtlimit für die Anforderungsrate

rateLimitbegrenzt Anfragen pro Sekunde, unabhängig von der Parallelitätskapazität. Lambda gibt HTTP 429 für Anfragen zurück, die über dem Ratenlimit liegen, auch wenn Umgebungen die Kapazität haben, sie zu bedienen.

Hochskalierung

Bevor alle Umgebungen das Limit für dynamische Parallelität erreichen, skaliert Lambda weitere Umgebungen auf bis zu. maxEnvironments Ein Endpunkt wird nicht mehr hochskaliert, wenn er das vCPU-Kontingent des Kontos erreichtmaxEnvironments. Wenn ein Endpunkt nicht hochskaliert werden kann und alle vorhandenen Umgebungen voll ausgelastet sind, drosselt Lambda neue Anfragen sofort mit einer HTTP 429-Antwort (Too Many Requests). Lambda stellt gedrosselte Anfragen nicht in die Warteschlange. Wenn eine neue Ausführungsumgebung initialisiert wird, werden Anfragen in eine Warteschlange gestellt, anstatt sofort gedrosselt zu werden.

Vorübergehende Überschreitung

Bei Änderungen des Revisionsgewichts, interner Flottenzyklen und anderen betrieblichen Ereignissen kann Lambda vorübergehend die Verfügbarkeit überschreiten, maxEnvironments um der Verfügbarkeit Priorität einzuräumen. Diese Überschreitung ist kurz und Lambda kehrt automatisch zum konfigurierten Grenzwert zurück. Sie müssen keinen Spielraum für diese betrieblichen Ereignisse einplanen, wenn Sie dies wünschen. maxEnvironments

Beispiel Beispiel: Kapazitätsberechnung

Sie konfigurieren die folgenden Einstellungen für Ihre Webfunktion:

• maxEnvironments= 10

• maxConcurrencyPerEnvironment= 64

• rateLimit= 800

Mit diesen Einstellungen werden Parallelität (gleichzeitig laufende Anfragen) und Anforderungsrate (pro Sekunde angenommene Anfragen) getrennt voneinander begrenzt. Bei bis zu 10 Umgebungen und jeweils bis zu 64 gleichzeitigen Anfragen kann der Endpunkt maximal etwa 640 gleichzeitige Anfragen (10 × 64) bearbeiten. Das dynamische Limit ist oft niedriger, sodass die anhaltende Parallelität in der Regel geringer ist. Welches Limit der Endpunkt zuerst erreicht, hängt davon ab, wie lange jede Anfrage dauert.

Concurrency-bound Endpunkt

Nehmen wir an, dass jede Anfrage 200 ms dauert, weil sie beispielsweise auf eine Datenbankabfrage wartet. Bei 640 laufenden Anfragen bearbeitet der Endpunkt höchstens etwa 3.200 Anfragen pro Sekunde (640 ÷0,2 s), was unter den 8.000 RPS liegt. rateLimit Wenn alle 10 Umgebungen voll ausgelastet sind, drosselt Lambda neue Anfragen mit HTTP 429. Erhöhen Sie die Anzahl, um mehr Traffic bereitzustellen. maxEnvironments

Request-rate-bound Endpunkt

Nehmen wir an, dass jede Anfrage 10 ms dauert. Bei 8.000 Anfragen pro Sekunde sind etwa 80 Anfragen im Umlauf (8.000 × 0,01 s), also deutlich weniger als 640. Lambda gibt HTTP 429 für Anfragen über 8.000 RPS zurück, obwohl die Umgebungen die Kapazität haben, sie zu bedienen. Um mehr Anfragen anzunehmen, erhöhen rateLimit Sie das Kontingent auf bis zu 10.000 RPS pro Endpunkt.

Drosselung

Wenn die Rate eingehender Anfragen die rateLimit Einstellung überschreitet, gibt Lambda eine HTTP 429-Antwort (Too Many Requests) für zu viele Anfragen zurück. Die Ratenbegrenzung gilt jeweils für den gesamten Endpunkt. AWS-Region

Lambda gibt auch eine HTTP 429-Antwort zurück, wenn alle Umgebungen voll ausgelastet sind, entweder weil der Endpunkt erreicht wurde maxEnvironments oder das Konto sein vCPU-Kontingent erreicht hat. Weitere Informationen finden Sie unter Wie die Skalierungseinstellungen interagieren.

Lambda kann auch HTTP 429 mit dem Platform.EndpointConcurrentInitThrottle Fehlertyp zurückgeben, wenn zu viele Ausführungsumgebungen gleichzeitig initialisiert werden. Diese Drosselung erhöht keine Drosselungsmetrik. Informationen zu den Metriken, die die anderen Drosseltypen erhöhen, finden Sie unter. Verwenden von CloudWatch Metriken mit Lambda-Webfunktionen

Wenn der Wert eines Endpunkts 0 rateLimit ist, gibt Lambda HTTP 503 (Service Unavailable) statt HTTP 429 mit dem lambda-web-error-type Header zurück. Platform.EndpointDisabled Lambda kann auch HTTP 503 zurückgeben, wenn es Last verliert, um den Dienst zu schützen. Versuchen Sie es erneut mit einem 503 ohne lambda-web-error-type Header mit Backoff und Jitter. Ein 503 mit Platform.EndpointDisabled wird fortgesetzt, bis Sie einen Wert ungleich Null rateLimit einstellen.

Lambda misst das Ratenlimit pro Sekunde. Kurzzeitige Überschreitungen des Grenzwerts können akzeptiert werden. Anhaltender Verkehr über dem Limit führt zu Drosselung.

Wenn Ihre Anwendung HTTP 429-Antworten empfängt, implementieren Sie exponentielles Backoff mit Jitter in Ihrem Client-Code, um gedrosselte Anfragen erneut zu versuchen.

Hochskalieren und Herunterskalieren

Aufwärtsskalierung

Wenn der Verkehr zunimmt und bestehende Umgebungen sich dem dynamischen Parallelitätslimit pro Umgebung nähern, erstellt Lambda zusätzliche Ausführungsumgebungen. Jede neue Umgebung wird initialisiert, bevor sie Anfragen bearbeitet. Die Initialisierungsschritte und das Zeitlimit für den Start finden Sie unter. Initialisierung (Kaltstart)

Während eine neue Umgebung initialisiert wird, leitet Lambda Anfragen an bestehende Umgebungen mit verfügbarer Kapazität weiter. Wenn keine Umgebung über Kapazität verfügt, wartet die Anfrage, während Lambda eine neue initialisiert (ein Kaltstart). Lambda gibt HTTP 429 nur zurück, wenn einer der angegebenen Grenzwerte Drosselung zutrifft, z. B. maxEnvironments oder das vCPU-Kontingent des Kontos.

Verkleinern

Wenn der Traffic abnimmt, identifiziert Lambda nicht ausgelastete Umgebungen und entfernt sie. Lambda leert eine Umgebung, bevor sie entfernt wird. Es stoppt die Weiterleitung neuer Anfragen an die Umgebung, lässt laufende Anfragen nach bestem Wissen und Gewissen abwickeln und sendet. SIGTERM Details hierzu finden Sie unter Lebenszyklus der Ausführungsumgebung.

Lambda skaliert auf Null-Umgebungen herunter, wenn kein Verkehr vorhanden ist. Die nächste Anfrage danach startet eine neue Umgebung (ein Kaltstart).

Skalierungseinstellungen wählen

Beachten Sie Folgendes, wenn Sie Werte für Endpunkt rateLimitmaxEnvironments, Endpunkt und Revision auswählenmaxConcurrencyPerEnvironment.

Wählen rateLimit

Der Standardwert ist keiner, was bedeutet, dass die Anforderungsrate eines Endpunkts sowohl durch das RPS-Kontingent von 10.000 pro Endpunkt als auch durch das RPS-Kontingent von 100.000 Konten begrenzt ist. Erwägen Sie, einen rateLimit Wert festzulegen, wenn Sie einschränken möchten, wie viel ein Endpunkt vom RPS-Kontingent Ihres Kontos beanspruchen kann, das von allen Ihren Endpunkten gemeinsam genutzt wird.

Die Einstellung eines rateLimit kann auch hilfreich sein, um den Gesamtdatenverkehr auf nachgelagerte Abhängigkeiten zu beschränken.

Wählen maxEnvironments

Der Standardwert ist none, was bedeutet, dass die Anzahl der Umgebungen eines Endpunkts nur durch das vCPU-Kontingent des Kontos eingeschränkt ist. Erwägen Sie die Festlegung eines maxEnvironments Werts, wenn Sie einschränken möchten, wie viel ein Endpunkt vom vCPU-Kontingent Ihres Kontos beanspruchen kann, das von allen Ihren Endpoints gemeinsam genutzt wird.

Wenn Sie einen maxEnvironments Wert festlegen, sollten Sie die Anzahl der Endpunkt-Umgebungen überwachen, sodass Sie benachrichtigt werden, wenn sie sich Ihrem maxEnvironments Limit nähern, und Maßnahmen ergreifen, um Drosselungen für eine Anwendung zu vermeiden, die im Laufe der Zeit organisch wächst.

Wenn Sie einen niedrigen Wert von festlegen, maxEnvironments können Sie die Kosten für den Betrieb von Umgebungen für Ihren Endpunkt begrenzen. Erwägen Sie die Verwendung eines niedrigen Werts für unkritische Hobbyprojekte.

Wählen maxConcurrencyPerEnvironment

Bei einer Revision maxConcurrencyPerEnvironment handelt es sich um die Obergrenze für das von Lambda verwaltete dynamische Parallelitätslimit pro Umgebung. Der Standardwert ist 64, und die meisten Benutzer sollten keinen optimalen Wert auswählen müssen.

Bei speichergebundenen Anwendungen kann eine maxConcurrencyPerEnvironment niedrigere Einstellung als der Standardwert zu einem vorhersehbareren Verhalten beitragen.

Bei CPU-bound Anwendungen kann eine maxConcurrencyPerEnvironment niedrigere Einstellung als die Standardeinstellung die CPU-Auslastung verringern und die Latenz im Steady-State-Zustand in warmen Umgebungen verbessern, aber auch zu häufigeren Kaltstarts führen. Eine maxConcurrencyPerEnvironment höhere Einstellung als die Standardeinstellung hat wahrscheinlich keine Auswirkung, wenn das von Lambda verwaltete dynamische Parallelitätslimit den Datenverkehr in der Umgebung einschränkt.

Bei I/O-bound Anwendungen kann maxConcurrencyPerEnvironment eine höhere Einstellung als die Standardeinstellung die Auslastung pro Umgebung verbessern und die Kosten senken.

Überwachen Sie die folgenden CloudWatch Messwerte, um festzustellen, ob Ihre Skalierungseinstellungen angemessen sind. Definitionen von Metriken finden Sie unterVerwenden von CloudWatch Metriken mit Lambda-Webfunktionen.

• EndpointRequestThrottlesund AccountRequestThrottles — Wenn der Wert durchweg größer als Null EndpointRequestThrottles istrateLimit, erhöhen Sie ihn bis zu einer Quote pro Endpunkt von 10.000 RPS. AccountRequestThrottleserhöht sich, wenn das Konto seine Quote für die Anforderungsrate in der Region erreicht. Um diese Drosselungen zu verringern, fordern Sie eine Erhöhung oder Senkung des Kontingents an anderen Endpunkten an. rateLimit

• EndpointActiveEnvironmentThrottlesund AccountActiveVCPUArm64Throttles — Diese Metriken erhöhen sich, wenn maxEnvironments oder das vCPU-Kontingent des Kontos eine zusätzliche Skalierung verhindert. Um diese Drosselungen zu reduzieren, erhöhen Sie das maxEnvironments vCPU-Kontingent oder fordern Sie eine Erhöhung an.

• EndpointActiveEnvironmentsund EnvironmentConcurrentRequests — Wenn sich aktive Umgebungen nähern maxEnvironments oder gleichzeitige Anfragen pro Umgebung in der Nähe bleibenmaxConcurrencyPerEnvironment, erhöhen Sie die entsprechende Einstellung.

• Anwendungslatenz — Messen Sie die Latenz anhand einer Anwendungsmetrik, anhand strukturierter Protokolle oder anhand der Latenzmessungen an Ihrer Haustür. Wenn die Latenz mit zunehmender Parallelität pro Umgebung zunimmt, reduzieren Sie die Latenz, maxConcurrencyPerEnvironment um Konflikte pro Umgebung zu reduzieren und die Last auf mehrere Umgebungen zu verteilen.

Skalierung für Endgeräte MultiRegion PerRegion

Für Webfunktionen mit Endpunkten MultiRegionoder PerRegionEndpunkten gelten die Skalierungseinstellungen unabhängig voneinander für jeden Standort, AWS-Region an dem der Endpunkt betrieben wird.

Jede Region erstellt und verwaltet ihren eigenen Pool von Ausführungsumgebungen. Der Verkehr in einer Region verbraucht nicht die Skalierungskapazität einer anderen Region.

Beispiele für Skalierung

Lambda skaliert Ihren Endpunkt, um den Headroom über der aktuellen Last zu halten. Der Headroom ist der Unterschied zwischen der Last eingehender Anfragen und der gesamten Anforderungslast, die warme Ausführungsumgebungen bewältigen können. Es absorbiert kleine Datenverkehrszuwächse, ohne auf den Start neuer Umgebungen warten zu müssen. Die Kapazität steigt schrittweise, da jede neue Umgebung die Kapazität erst nach Abschluss der Initialisierung erhöht. Wenn der Endpunkt ein Limit erreicht, hört die Kapazität auf zu wachsen, und Lambda drosselt Anfragen, die über das hinausgehen, was der Endpunkt akzeptieren kann.

Die folgenden Beispiele zeigen, wie der Endpunkt mit einem Datenverkehrsschub umgeht und wie er sich verhält, wenn die Last die einzelnen Grenzwerte erreicht. Die Diagramme veranschaulichen das allgemeine Verhalten und sind nicht maßstabsgetreu dargestellt.

Umgang mit einem Verkehrsstau

Wenn die Last allmählich zunimmt, absorbiert Headroom den Anstieg, während Lambda im Hintergrund neue Umgebungen skaliert. Wenn die Last schneller steigt, als der verfügbare Speicherplatz aufnehmen kann, können die warmen Umgebungen nicht alle eingehenden Anfragen verarbeiten. Lambda startet neue Umgebungen, um die Last zu bewältigen, die über dem Headroom liegt, und diese Anfragen warten auf den Kaltstart der neuen Umgebungen. Sobald die neuen Umgebungen bereit sind, stellt Lambda den Headroom über der neuen Last wieder her.

Das Limit für die Anforderungsrate pro Endpunkt wurde erreicht

Das Limit für die Anforderungsrate begrenzt, wie viel Last der Endpunkt aufnehmen kann, sodass die Kapazität nicht überschritten wird. Wenn sich die Auslastung dem Ratenkontingent pro Endpunkt oder Ihrer rateLimit Einstellung nähert, schrumpft der Spielraum. Wenn die Last das Limit überschreitet, gibt Lambda HTTP 429 für Anfragen zurück, die darüber liegen. Wenn Sie mehr Anfragen annehmen möchtenrateLimit, erhöhen Sie den Wert bis zur Höhe der Ratenquote pro Endpunkt.

Max Environments wird erreicht

In diesem Beispiel maxEnvironments ist es niedriger als das Limit für die Anforderungsrate. Wenn der Endpunkt erreicht istmaxEnvironments, beendet Lambda das Hinzufügen von Ausführungsumgebungen. Die Auslastung kann weiter zunehmen, sodass der Spielraum schrumpft. Wenn die Last das übersteigt, was die Umgebungen bewältigen können, drosselt Lambda neue Anfragen mit HTTP 429, obwohl die Anforderungsrate immer noch unter dem Ratenlimit liegt. Erhöhen Sie die Kapazität, um mehr Kapazität zu ermöglichen. maxEnvironments

Das vCPU-Kontingent für das Konto wird erreicht

Alle Endpoints in einem Konto teilen sich das vCPU-Kontingent in jedem. AWS-Region Umgebungen, die von anderen Endpunkten verwendet werden, reduzieren die Skalierbarkeit dieses Endpunkts. In diesem Beispiel ist das für den Endpunkt verfügbare vCPU-Kontingent niedriger als sowohl seine maxEnvironments Einstellung als auch sein Limit für die Anforderungsrate. Wenn das Konto das Kontingent erreicht, beendet Lambda das Hinzufügen von Umgebungen und drosselt Anfragen, die die verfügbare Kapazität überschreiten, obwohl der Endpunkt seine eigenen Grenzwerte nicht erreicht hat. Um mehr Kapazität zu ermöglichen, fordern Sie eine Erhöhung des vCPU-Kontingents an.