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.
# Verbesserung der Startleistung mit Lambda SnapStart
Lambda SnapStart kann eine Startleistung von nur unter einer Sekunde bieten, in der Regel ohne Änderungen an Ihrem Event-Funktionscode. SnapStart macht es einfacher, reaktionsschnelle und skalierbare Anwendungen zu erstellen, ohne Ressourcen bereitzustellen oder komplexe Leistungsoptimierungen zu implementieren.
Der größte Beitrag zur Startup-Latenz (oft als Kaltstartzeit bezeichnet) ist die Zeit, die Lambda für die Initialisierung der Funktion aufwendet. Dazu gehören das Laden des Funktionscodes, der Start der Laufzeit und die Initialisierung des Funktionscodes. Mit SnapStart initialisiert Lambda Ihre Event-Funktion, wenn Sie eine Funktionsversion veröffentlichen. Lambda erstellt einen [Firecracker MicroVM-Snapshot](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/) des Speicher- und Festplattenstatus der initialisierten [Ausführungsumgebung](lambda-runtime-environment.md), verschlüsselt den Snapshot und speichert ihn intelligent im Cache, um die Abruflatenz zu optimieren.
Um die Stabilität zu gewährleisten, verwaltet Lambda mehrere Kopien jedes Snapshots. Lambda patcht Snapshots und ihre Kopien automatisch mit den neuesten Laufzeit- und Sicherheitsupdates. Wenn Sie die Event Function-Version zum ersten Mal aufrufen und die Aufrufe immer größer werden, nimmt Lambda neue Ausführungsumgebungen aus dem zwischengespeicherten Snapshot wieder auf, anstatt sie von Grund auf neu zu initialisieren, wodurch die Startlatenz verbessert wird.
**Wichtig**
Wenn Ihre Anwendungen von der Eindeutigkeit des Zustands abhängen, müssen Sie Ihren Funktionscode auswerten und sicherstellen, dass er gegenüber Snapshot-Vorgängen widerstandsfähig ist. Weitere Informationen finden Sie unter [Umgang mit Einzigartigkeit mit Lambda SnapStart](snapstart-uniqueness.md).
Wenn Sie auf Probleme stoßen, finden Sie weitere Informationen unter. [Behebung SnapStart von Fehlern für Lambda-Ereignisfunktionen](snapstart-troubleshooting.md)
**Topics**
+ [Wann verwenden SnapStart](#snapstart-use-cases)
+ [Unterstützte Funktionen und Einschränkungen](#snapstart-runtimes)
+ [Unterstützte Regionen](#snapstart-supported-regions)
+ [Erwägungen zur Kompatibilität](#snapstart-compatibility)
+ [SnapStart Preisgestaltung](#snapstart-pricing)
+ [Lambda aktivieren und verwalten SnapStart](snapstart-activate.md)
+ [Umgang mit Einzigartigkeit mit Lambda SnapStart](snapstart-uniqueness.md)
+ [Implementieren Sie Code vor oder nach Snapshots der Lambda-Ereignisfunktion](snapstart-runtime-hooks.md)
+ [Überwachung für Lambda SnapStart](snapstart-monitoring.md)
+ [Sicherheitsmodell für Lambda SnapStart](snapstart-security.md)
+ [Maximieren Sie die Lambda-Leistung SnapStart](snapstart-best-practices.md)
+ [Behebung SnapStart von Fehlern für Lambda-Ereignisfunktionen](snapstart-troubleshooting.md)
## Wann verwenden SnapStart
Lambda SnapStart wurde entwickelt, um die Latenzvariabilität zu beheben, die durch einmaligen Initialisierungscode verursacht wird, z. B. beim Laden von Modulabhängigkeiten oder Frameworks. Beim ersten Aufruf kann es manchmal mehrere Sekunden dauern, bis diese Vorgänge abgeschlossen sind. Wird verwendet SnapStart , um diese Latenz in optimalen Szenarien von mehreren Sekunden auf weniger als eine Sekunde zu reduzieren. SnapStart funktioniert am besten, wenn es mit Funktionsaufrufen in großem Maßstab verwendet wird. Funktionen, die selten aufgerufen werden, weisen möglicherweise nicht dieselben Leistungsverbesserungen auf.
SnapStart ist besonders vorteilhaft für zwei Haupttypen von Anwendungen:
+ **Latency-sensitive APIs und Benutzerabläufe:** Funktionen, die Teil kritischer API-Endpunkte oder benutzerorientierter Abläufe sind, können von SnapStart der geringeren Latenz und den verbesserten Reaktionszeiten profitieren.
+ **Latency-sensitive Datenverarbeitungs-Workflows:** Time-bound Datenverarbeitungs-Workflows, die Lambda Event Functions verwenden, können einen besseren Durchsatz erzielen, indem sie die Latenz bei der Initialisierung von Ausreißerfunktionen reduzieren.
Durch die [bereitgestellte Parallelität](provisioned-concurrency.md) werden Event Functions initialisiert und sind innerhalb von zweistelligen Millisekunden bereit, darauf zu reagieren. Verwenden Sie die bereitgestellte Parallelität, wenn Ihre Anwendung strenge Kaltstart-Latenzanforderungen hat, die nicht angemessen erfüllt werden können. SnapStart
## Unterstützte Funktionen und Einschränkungen
SnapStart unterstützt die folgenden von [Lambda verwalteten Laufzeiten](lambda-runtimes.md) und die entsprechenden AWS Lambda-Basisimages im ZIP- und Container-Image-Bereitstellungsformat:
+ Java 11 und höher
+ Python 3.12 oder höher
+ .NET 8 und höher. Wenn Sie das [Lambda Annotations Framework für.NET](csharp-handler.md#csharp-handler-annotations) verwenden, führen Sie ein Upgrade auf [Amazon.Lambda.Annotations](https://www.nuget.org/packages/Amazon.Lambda.Annotations)Version 1.6.0 oder höher durch, um die Kompatibilität mit sicherzustellen. SnapStart
Für Container-Images, die auf AWS Lambda-Basis-Images oder benutzerdefinierten Basis-Images basieren, lesen Sie Ihren Funktionscode [Implementierung von SnapStart Hooks für Container-Images](snapstart-runtime-hooks-custom.md) und überprüfen Sie ihn für die Handhabung von SnapStart [Eindeutigkeitsanforderungen](snapstart-uniqueness.md).
Andere verwaltete Laufzeiten (wie `nodejs24.x` und`ruby4.0`) [OS-only Laufzeiten](runtimes-provided.md) werden nicht unterstützt. SnapStart unterstützt keine [bereitgestellte Parallelität](provisioned-concurrency.md), [Amazon Elastic File System (Amazon EFS), Amazon](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.html) [S3 S3-Dateien](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-files.html) oder kurzlebigen Speicher mit mehr als 512 MB.
**Anmerkung**
Sie können es SnapStart nur für [veröffentlichte Funktionsversionen und [Aliase](configuration-aliases.md) verwenden, die auf Versionen](configuration-versions.md#configuration-versions-config) verweisen. Sie können es nicht für die unveröffentlichte Version einer Funktion ($LATEST) verwenden SnapStart .
## Unterstützte Regionen
Lambda SnapStart ist in allen [Handelsregionen](https://docs.aws.amazon.com/general/latest/gr/glos-chap.html#region) außer Asien-Pazifik (Neuseeland) und Asien-Pazifik (Taipeh) erhältlich.
## Erwägungen zur Kompatibilität
Mit SnapStart verwendet Lambda einen einzelnen Snapshot als Ausgangszustand für mehrere Ausführungsumgebungen. Wenn Ihre Funktion während der [Initialisierungsphase](lambda-runtime-environment.md#runtimes-lifecycle-ib) eines der folgenden Elemente verwendet, müssen Sie vor der Verwendung möglicherweise einige Änderungen vornehmen: SnapStart
**Eindeutigkeit**
Wenn Ihr Initialisierungscode eindeutigen Inhalt generiert, der im Snapshot enthalten ist, ist der Inhalt möglicherweise nicht eindeutig, wenn er in Ausführungsumgebungen wiederverwendet wird. Um die Einzigartigkeit bei der Verwendung zu wahren SnapStart, müssen Sie nach der Initialisierung eindeutige Inhalte generieren. Dazu gehören eindeutige IDs, eindeutige Geheimnisse und Entropie, die zum Generieren von Pseudozufälligkeiten verwendet wird. Informationen zum Wiederherstellen von Eindeutigkeit finden Sie unter [Umgang mit Einzigartigkeit mit Lambda SnapStart](snapstart-uniqueness.md).
**Netzwerkverbindungen**
Der Status der Verbindungen, die Ihre Event-Funktion während der Initialisierungsphase herstellt, ist nicht garantiert, wenn Lambda Ihre Funktion von einem Snapshot aus wieder aufnimmt. Überprüfen Sie den Status Ihrer Netzwerkverbindungen und stellen Sie diese bei Bedarf wieder her. In den meisten Fällen werden Netzwerkverbindungen, die ein AWS SDK herstellt, automatisch wieder aufgenommen. Für andere Verbindungen lesen Sie die [bewährten Methoden](snapstart-best-practices.md).
**Temporäre Daten**
Einige Funktionen laden während der Initialisierungsphase kurzlebige Daten herunter oder initialisieren diese, wie etwa temporäre Anmeldeinformationen oder im Cache gespeicherte Zeitstempel. Aktualisieren Sie kurzlebige Daten im Funktionshandler, bevor Sie sie verwenden, auch wenn Sie sie nicht verwenden. SnapStart
## SnapStart Preisgestaltung
**Anmerkung**
Für Java-verwaltete Laufzeiten fallen keine zusätzlichen Kosten für SnapStart an. Die Abrechnung erfolgt basierend auf der Anzahl der Anfragen für Ihre Funktionen, der Zeit, die Ihr Code zum Ausführen benötigt, und dem für Ihre Funktion konfigurierten Arbeitsspeicher.
Die Kosten für die Nutzung SnapStart beinhalten Folgendes:
+ **Caching:** Für jede Funktionsversion, die Sie mit SnapStart aktivierter Option veröffentlichen, zahlen Sie die Kosten für das Zwischenspeichern und Verwalten des Snapshots. Der Preis hängt von der [Speicher](configuration-memory.md)menge ab, die Sie Ihrer Funktion zuweisen. Ihnen werden mindestens 3 Stunden in Rechnung gestellt.
[Ihnen werden weiterhin Gebühren berechnet, solange Ihre Funktion aktiv ist.](snapstart-activate.md#snapstart-active) Verwenden Sie die [ListVersionsByFunction](https://docs.aws.amazon.com/lambda/latest/api/API_ListVersionsByFunction.html)API-Aktion, um Funktionsversionen zu identifizieren, und verwenden Sie sie dann, [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)um ungenutzte Versionen zu löschen. Informationen zum automatischen Löschen ungenutzter Funktionsversionen finden Sie im [Lambda Version Cleanup](https://serverlessland.com/workflows/step-functions-lambda-version-cleanup)-Pattern auf Serverless Land.
+ **Wiederherstellung:** Jedes Mal, wenn eine Funktions-Instance aus einem Snapshot wiederhergestellt wird, zahlen Sie eine Wiederherstellungsgebühr. Der Preis hängt von der Speichermenge ab, die Sie Ihrer Funktion zuweisen.
Wie bei allen Lambda-Ereignisfunktionen fallen Gebühren für die Dauer von Code an, der im Funktionshandler ausgeführt wird. Bei SnapStart Funktionen fallen Dauergebühren auch für Initialisierungscode an, der außerhalb des Handlers deklariert wurde, für die Zeit, die zum Laden der Laufzeit benötigt wird, und für jeden Code, der in einem [Runtime-Hook](snapstart-runtime-hooks.md) ausgeführt wird. Die Dauer wird vom Beginn der Ausführung Ihres Codes bis zur Rückgabe oder einem anderen Ende berechnet, aufgerundet auf die nächste 1 ms. Lambda verwaltet aus Gründen der Ausfallsicherheit zwischengespeicherte Kopien Ihres Snapshots und wendet automatisch Softwareupdates wie Laufzeit-Upgrades und Sicherheitspatches auf diese an. Jedes Mal, wenn Lambda Ihren Initialisierungscode erneut ausführt, um Softwareupdates zu installieren, fallen Gebühren an.
Weitere Informationen zu den Nutzungskosten finden Sie unter SnapStart [AWS Lambda Preisgestaltung](https://aws.amazon.com/lambda/pricing/#SnapStart_Pricing).