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, normalerweise ohne Änderungen an Ihrem 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 initialisiert Lambda Ihre Funktion SnapStart, wenn Sie eine Funktionsversion veröffentlichen. Lambda erstellt einen [Firecracker-microVM](https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/)-Snapshot des Arbeitsspeichers und des Festplattenstatus der initialisierten [Ausführungsumgebung](lambda-runtime-environment.md), verschlüsselt den Snapshot und legt ihn in einem intelligenten Cache ab, 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 Funktionsversion zum ersten Mal aufrufen und wenn die Aufrufe hochskalieren, nimmt Lambda neue Ausführungsumgebungen aus dem im Cache gespeicherten Snapshot wieder auf, anstatt sie von Grund auf neu zu initialisieren, wodurch die Startup-Latenz 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).
**Topics**
+ [Wann sollte es verwendet werden 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 Lambda-Funktions-Snapshots](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-Funktionen](snapstart-troubleshooting.md)
## Wann sollte es verwendet werden 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:
+ **Latenzabhängige Abläufe APIs und Benutzerabläufe:** Funktionen, die Teil kritischer API-Endpunkte oder benutzerorientierter Abläufe sind, können von der geringeren Latenz und den verbesserten SnapStart Reaktionszeiten profitieren.
+ **Workflows zur latenzsensitiven Datenverarbeitung:** Zeitgebundene Datenverarbeitungsworkflows, die Lambda-Funktionen verwenden, können einen besseren Durchsatz erzielen, indem sie die Latenz bei der Initialisierung von Ausreißerfunktionen reduzieren.
Die [bereitgestellte Gleichzeitigkeit](provisioned-concurrency.md) sorgt dafür, dass die Funktionen im zweistelligen Millisekundenbereich initialisiert und reaktionsbereit sind. Verwenden Sie 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 ist für die folgenden von [Lambda verwalteten Laufzeiten](lambda-runtimes.md) verfügbar:
+ 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 Version 1.6.0 oder höher durch, um die Kompatibilität mit sicherzustellen](https://www.nuget.org/packages/Amazon.Lambda.Annotations). SnapStart
Andere verwaltete Laufzeiten (wie `nodejs24.x` und `ruby3.4`), [Reine OS-Laufzeiten](runtimes-provided.md) und [Container-Images](images-create.md) werden nicht unterstützt.
SnapStart unterstützt keine [bereitgestellte Parallelität](provisioned-concurrency.md), [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/efs/latest/ug/accessing-fs.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 (\$1LATEST) 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 einzigartige IDs, einzigartige Geheimnisse und Entropie, die verwendet wird, um Pseudozufälligkeit zu erzeugen. Informationen zum Wiederherstellen von Eindeutigkeit finden Sie unter [Umgang mit Einzigartigkeit mit Lambda SnapStart](snapstart-uniqueness.md).
**Netzwerkverbindungen**
Der Zustand der Verbindungen, die Ihre Funktion während der Initialisierungsphase herstellt, ist nicht garantiert, wenn Lambda Ihre Funktion von einem Snapshot fortsetzt. Überprüfen Sie den Status Ihrer Netzwerkverbindungen und stellen Sie diese bei Bedarf wieder her. In den meisten Fällen werden Netzwerkverbindungen, die ein SDK herstellt, automatisch wieder aufgenommen. AWS 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 für die Zwischenspeicherung und Wartung 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 Gebühren berechnet, solange Ihre Funktion [aktiv](snapstart-activate.md#snapstart-active) ist. 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, um ungenutzte Versionen [DeleteFunction](https://docs.aws.amazon.com/lambda/latest/api/API_DeleteFunction.html)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-Funktionen fallen Dauergebühren für Code an, der im Funktionshandler ausgeführt wird. Bei SnapStart Funktionen fallen Gebühren für die Dauer 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).
# Lambda aktivieren und verwalten SnapStart
Um es zu verwenden SnapStart, aktivieren Sie es SnapStart auf einer neuen oder vorhandenen Lambda-Funktion. Veröffentlichen und rufen Sie dann eine Funktionsversion auf.
**Topics**
+ [Aktivierung SnapStart (Konsole)](#snapshot-console)
+ [SnapStart Aktiviert (AWS CLI)](#snapshot-cli)
+ [Aktivierung SnapStart (API)](#snapshot-api)
+ [Lambda SnapStart und Funktionszustände](#snapstart-function-states)
+ [Aktualisieren eines Snapshots](#update-snapshot)
+ [SnapStart Verwenden mit AWS SDKs](#snapstart-credentials)
+ [Verwenden Sie SnapStart mit CloudFormation AWS SAM, und AWS CDK](#snapstart-cfn-sam)
+ [Löschen von Snapshots](#snapshot-delete)
## Aktivierung SnapStart (Konsole)
**Zur Aktivierung SnapStart für eine Funktion**
1. Öffnen Sie die Seite [Funktionen](https://console.aws.amazon.com/lambda/home#/functions) der Lambda-Konsole.
1. Wählen Sie den Namen einer Funktion aus.
1. Wählen Sie **Configuration** (Konfiguration) und dann **General configuration** (Allgemeine Konfiguration).
1. Wählen Sie im Bereich **General configuration** (Allgemeine Konfiguration) die Option **Edit** (Bearbeiten) aus.
1. Wählen Sie auf der Seite **Grundeinstellungen bearbeiten** für die **SnapStart**Option **Veröffentlichte Versionen** aus.
1. Wählen Sie **Speichern**.
1. [Veröffentlichen einer Funktionsversion](configuration-versions.md#configuration-versions-config). Lambda initialisiert Ihren Code, erstellt einen Snapshot der initialisierten Ausführungsumgebung und speichert den Snapshot im Cache für einen Zugriff mit geringer Latenz.
1. [Rufen Sie die Funktionsversion auf](configuration-versions.md#versioning-versions-using).
## SnapStart Aktiviert (AWS CLI)
**Zur Aktivierung SnapStart für eine bestehende Funktion**
1. Aktualisieren Sie die Funktionskonfiguration, indem [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)Sie den Befehl mit der **--snap-start** Option ausführen.
```
aws lambda update-function-configuration \
--function-name my-function \
--snap-start ApplyOn=PublishedVersions
```
1. Veröffentlichen Sie eine Funktionsversion mit dem [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html)-Befehl.
```
aws lambda publish-version \
--function-name my-function
```
1. Bestätigen Sie, dass sie für die Funktionsversion aktiviert SnapStart ist, indem Sie den [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)Befehl ausführen und die Versionsnummer angeben. Das folgende Beispiel legt Version 1 fest.
```
aws lambda get-function-configuration \
--function-name my-function:1
```
Wenn in der Antwort angezeigt [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)wird, dass dies der [Fall ist `On` und der Status](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart lautet`Active`, dann ist aktiviert und ein Snapshot ist für die angegebene Funktionsversion verfügbar.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Rufen Sie die Funktionsversion auf, indem Sie den [Aufruf](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html)-Befehl ausführen und die Version angeben. Das folgende Beispiel ruft Version 1 auf.
```
aws lambda invoke \
--cli-binary-format raw-in-base64-out \
--function-name my-function:1 \
--payload '{ "name": "Bob" }' \
response.json
```
Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*.
**Zur Aktivierung SnapStart , wenn Sie eine neue Funktion erstellen**
1. Erstellen Sie eine Funktion, indem Sie den [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html)-Befehl mit der **--snap-start**-Option ausführen. Geben Sie für **--role** den Amazon-Ressourcennamen (ARN) Ihrer [Ausführungsrolle](lambda-intro-execution-role.md) an.
```
aws lambda create-function \
--function-name my-function \
--runtime "java25" \
--zip-file fileb://my-function.zip \
--handler my-function.handler \
--role arn:aws:iam::111122223333:role/lambda-ex \
--snap-start ApplyOn=PublishedVersions
```
1. Erstellen Sie eine Version mit dem [publish-version](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/publish-version.html)-Befehl.
```
aws lambda publish-version \
--function-name my-function
```
1. Bestätigen Sie, dass sie für die Funktionsversion aktiviert SnapStart ist, indem Sie den [get-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/get-function-configuration.html)Befehl ausführen und die Versionsnummer angeben. Das folgende Beispiel legt Version 1 fest.
```
aws lambda get-function-configuration \
--function-name my-function:1
```
Wenn in der Antwort angezeigt [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)wird, dass dies der [Fall ist `On` und der Status](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart lautet`Active`, dann ist aktiviert und ein Snapshot ist für die angegebene Funktionsversion verfügbar.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Rufen Sie die Funktionsversion auf, indem Sie den [Aufruf](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/invoke.html)-Befehl ausführen und die Version angeben. Das folgende Beispiel ruft Version 1 auf.
```
aws lambda invoke \
--cli-binary-format raw-in-base64-out \
--function-name my-function:1 \
--payload '{ "name": "Bob" }' \
response.json
```
Die **cli-binary-format** Option ist erforderlich, wenn Sie AWS CLI Version 2 verwenden. Um dies zur Standardeinstellung zu machen, führen Sie `aws configure set cli-binary-format raw-in-base64-out` aus. Weitere Informationen finden Sie unter [Von AWS CLI unterstützte globale Befehlszeilenoptionen](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-options.html#cli-configure-options-list) im *AWS Command Line Interface -Benutzerhandbuch für Version 2*.
## Aktivierung SnapStart (API)
**Um zu aktivieren SnapStart**
1. Führen Sie eine der folgenden Aktionen aus:
+ Erstellen Sie eine neue Funktion mit SnapStart aktiviertem Wert, indem Sie die [CreateFunction](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html)API-Aktion mit dem [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)Parameter verwenden.
+ Aktivieren Sie sie SnapStart für eine vorhandene Funktion, indem Sie die [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html)Aktion mit dem [SnapStart](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStart.html)Parameter verwenden.
1. Veröffentlichen Sie eine Funktionsversion mit der [PublishVersion](https://docs.aws.amazon.com/lambda/latest/api/API_PublishVersion.html)Aktion. Lambda initialisiert Ihren Code, erstellt einen Snapshot der initialisierten Ausführungsumgebung und speichert den Snapshot im Cache für einen Zugriff mit geringer Latenz.
1. Bestätigen Sie mithilfe der [GetFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html)Aktion, dass sie für die Funktionsversion aktiviert SnapStart ist. Geben Sie eine Versionsnummer an, um zu bestätigen, dass die Version für diese Version aktiviert SnapStart ist. Wenn in der Antwort angezeigt [OptimizationStatus](https://docs.aws.amazon.com/lambda/latest/api/API_SnapStartResponse.html)wird, dass dies der [Fall ist `On` und der Status](https://docs.aws.amazon.com/lambda/latest/api/API_GetFunctionConfiguration.html#lambda-GetFunctionConfiguration-response-State) SnapStart lautet`Active`, dann ist aktiviert und ein Snapshot ist für die angegebene Funktionsversion verfügbar.
```
"SnapStart": {
"ApplyOn": "PublishedVersions",
"OptimizationStatus": "On"
},
"State": "Active",
```
1. Rufen Sie die Funktionsversion mit der [Aufruf](https://docs.aws.amazon.com/lambda/latest/api/API_Invoke.html)-Aktion auf.
## Lambda SnapStart und Funktionszustände
Die folgenden Funktionszustände können auftreten, wenn Sie verwenden SnapStart.
**Ausstehend**
Lambda initialisiert Ihren Code und erstellt einen Snapshot der initialisierten Ausführungsumgebung. Alle Aufrufe oder andere API-Aktionen, die auf der Funktionsversion ausgeführt werden, schlagen fehl.
**Aktiv**
Die Snapshot-Erstellung ist abgeschlossen und Sie können die Funktion aufrufen. Zur Verwendung SnapStart müssen Sie die veröffentlichte Funktionsversion aufrufen, nicht die unveröffentlichte Version (\$1LATEST).
**Inaktiv**
Der Status `Inactive` kann auftreten, wenn Lambda regelmäßig Funktions-Snapshots neu generiert, um Software-Updates anzuwenden. In diesem Fall kann Ihre Funktion in einen `Inactive`-Zustand übergehen, wenn sie nicht initialisiert werden kann.
Bei Funktionen, die eine Java-Laufzeit verwenden, löscht Lambda Snapshots nach 14 Tagen ohne Aufruf. Wenn Sie die Funktionsversion nach 14 Tagen aufrufen, gibt Lambda eine `SnapStartNotReadyException`-Antwort zurück und beginnt mit der Initialisierung eines neuen Snapshots. Warten Sie, bis die Funktionsversion den `Active`-Status erreicht hat, und rufen Sie es dann erneut auf.
**Fehlgeschlagen**
Lambda hat beim Ausführen des Initialisierungscodes oder beim Erstellen des Snapshots einen Fehler festgestellt.
## Aktualisieren eines Snapshots
Lambda erstellt für jede veröffentlichte Funktionsversion einen Snapshot. Um einen Snapshot zu aktualisieren, veröffentlichen Sie eine neue Funktionsversion.
## SnapStart Verwenden mit AWS SDKs
Um AWS SDK-Aufrufe von Ihrer Funktion aus durchzuführen, generiert Lambda einen kurzlebigen Satz von Anmeldeinformationen, indem es die Ausführungsrolle Ihrer Funktion übernimmt. Diese Anmeldeinformationen sind während des Aufrufs Ihrer Funktion als Umgebungsvariablen verfügbar. Sie müssen keine Anmeldeinformationen für das SDK direkt im Code bereitstellen. Standardmäßig überprüft die Kette der Anbieter von Anmeldeinformationen nacheinander jeden Ort, an dem Sie Anmeldeinformationen festlegen können, und wählt die erste verfügbare aus – in der Regel die Umgebungsvariablen (`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` und `AWS_SESSION_TOKEN`).
**Anmerkung**
Wenn SnapStart aktiviert, verwendet die Lambda-Laufzeit automatisch die Container-Anmeldeinformationen (`AWS_CONTAINER_CREDENTIALS_FULL_URI`und`AWS_CONTAINER_AUTHORIZATION_TOKEN`) anstelle der Umgebungsvariablen für die Zugriffsschlüssel. Dadurch wird verhindert, dass Anmeldeinformationen ablaufen, bevor die Funktion wiederhergestellt wird.
## Verwenden Sie SnapStart mit CloudFormation AWS SAM, und AWS CDK
+ **AWS CloudFormation:** Deklarieren Sie die [SnapStart](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-lambda-function-snapstart.html)Entität in Ihrer Vorlage.
+ **AWS Serverless Application Model (AWS SAM):** Deklarieren Sie die [SnapStart](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-snapstart)Eigenschaft in Ihrer Vorlage.
+ **AWS Cloud Development Kit (AWS CDK):** Verwenden Sie den [SnapStartProperty](https://docs.aws.amazon.com/cdk/api/v2/java/software/amazon/awscdk/services/lambda/CfnFunction.SnapStartProperty.html)Typ.
## Löschen von Snapshots
Lambda löscht Snapshots, wenn:
+ Sie die Funktion oder Funktionsversion löschen.
+ **Nur Java-Laufzeiten** – Sie die Funktionsversion 14 Tage lang nicht aufrufen. Wenn nach 14 Tagen ohne Aufruf die Funktionsversion in den Status [Inaktiv](#snapstart-function-states) übergeht. Wenn Sie die Funktionsversion nach 14 Tagen aufrufen, gibt Lambda eine `SnapStartNotReadyException`-Antwort zurück und beginnt mit der Initialisierung eines neuen Snapshots. Warten Sie, bis die Funktionsversion den Status [Aktiv](#snapstart-function-states) erreicht hat, und rufen Sie es dann erneut auf.
Lambda entfernt alle Ressourcen, die mit gelöschten Snapshots verknüpft sind, gemäß der Allgemeinen Datenschutzverordnung (DSGVO).
# Umgang mit Einzigartigkeit mit Lambda SnapStart
Wenn Aufrufe für eine SnapStart Funktion skaliert werden, verwendet Lambda einen einzigen initialisierten Snapshot, um mehrere Ausführungsumgebungen wieder aufzunehmen. 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 einzigartige IDs, einzigartige Geheimnisse und Entropie, die verwendet wird, um Pseudozufälligkeit zu erzeugen.
Im Folgenden finden Sie einige bewährte Methoden für die Aufrechterhaltung der Eindeutigkeit Ihres Codes. Für Java-Funktionen bietet Lambda auch ein [SnapStart Open-Source-Scan-Tool](#snapstart-scanning), mit dessen Hilfe nach Code gesucht werden kann, der Eindeutigkeit voraussetzt. Wenn Sie während der Initialisierungsphase eindeutige Daten generieren, können Sie eine [Laufzeit-Hook](snapstart-runtime-hooks.md) verwenden, um die Eindeutigkeit wiederherzustellen. Mit Laufzeit-Hooks können Sie bestimmten Code ausführen, unmittelbar bevor Lambda einen Snapshot aufnimmt oder unmittelbar nachdem Lambda eine Funktion aus einem Snapshot fortsetzt.
## Vermeiden des Speicherns eines Zustands, der von der Eindeutigkeit während der Initialisierung abhängt
Vermeiden Sie während der [Initialisierungsphase](lambda-runtime-environment.md#runtimes-lifecycle-ib) Ihrer Funktion das Zwischenspeichern von Daten, die eindeutig sein sollen, z. B. das Generieren einer eindeutigen ID für die Protokollierung oder das Setzen von Seeds für Zufallsfunktionen. Stattdessen empfehlen wir Ihnen, eindeutige Daten zu generieren oder Seeds für Zufallsfunktionen in Ihrem Funktionshandler festzulegen – oder einen [Laufzeit-Hook](snapstart-runtime-hooks.md) zu verwenden.
Die folgenden Beispiele zeigen, wie eine UUID im Funktionshandler erzeugt werden kann.
------
#### [ Java ]
**Example – Generierung einer eindeutigen ID im Funktionshandler**
```
import java.util.UUID;
public class Handler implements RequestHandler {
private static UUID uniqueSandboxId = null;
@Override
public String handleRequest(String event, Context context) {
if (uniqueSandboxId == null)
uniqueSandboxId = UUID.randomUUID();
System.out.println("Unique Sandbox Id: " + uniqueSandboxId);
return "Hello, World!";
}
}
```
------
#### [ Python ]
**Example – Generierung einer eindeutigen ID im Funktionshandler**
```
import json
import random
import time
unique_number = None
def lambda_handler(event, context):
seed = int(time.time() * 1000)
random.seed(seed)
global unique_number
if not unique_number:
unique_number = random.randint(1, 10000)
print("Unique number: ", unique_number)
return "Hello, World!"
```
------
#### [ .NET ]
**Example – Generierung einer eindeutigen ID im Funktionshandler**
```
namespace Example;
public class SnapstartExample
{
private Guid _myExecutionEnvironmentGuid;
public SnapstartExample()
{
// This GUID is set for non-restore use cases, such as testing or if SnapStart is turned off
_myExecutionEnvironmentGuid = new Guid();
// Register the method which will run after each restore. You may need to update Amazon.Lambda.Core to see this
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(MyAfterRestore);
}
private ValueTask MyAfterRestore()
{
// After restoring this snapshot to a new execution environment, update the GUID
_myExecutionEnvironmentGuid = new Guid();
return ValueTask.CompletedTask;
}
public string Handler()
{
return $"Hello World! My Execution Environment GUID is {_myExecutionEnvironmentGuid}";
}
}
```
------
## Verwenden Sie kryptografisch sichere Pseudozufallszahlengeneratoren () CSPRNGs
Wenn Ihre Anwendung von Zufälligkeit abhängt, empfehlen wir Ihnen, kryptografisch sichere Zufallszahlengeneratoren () zu verwenden. CSPRNGs Zusätzlich zu OpenSSL 1.0.2 enthalten die von Lambda verwalteten Laufzeiten auch die folgenden integrierten Funktionen: CSPRNGs
+ **Java:** `java.security.SecureRandom`
+ **Python:** `random.SystemRandom`
+ **.NET:** `System.Security.Cryptography.RandomNumberGenerator`
Software, die immer Zufallszahlen von erhält `/dev/random` oder `/dev/urandom` auch deren Zufälligkeit beibehält. SnapStart
AWS Kryptografie-Bibliotheken behalten automatisch die Zufälligkeit bei, SnapStart beginnend mit den in der folgenden Tabelle angegebenen Mindestversionen. Wenn Sie diese Bibliotheken mit Ihren Lambda-Funktionen verwenden, stellen Sie sicher, dass Sie die folgenden Mindestversionen oder neuere Versionen verwenden:
****
| Bibliothek | Unterstützte Mindestversion (x86) | Unterstützte Mindestversion (ARM) |
| --- | --- | --- |
| AWS libcrypto (-LC)AWS | 1.16.0 | 1.30.0 |
| AWS libcrypto FIPS | 2.0.13 | 2.0.13 |
Wenn Sie die vorangehenden kryptografischen Bibliotheken mit Ihren Lambda-Funktionen als transitive Abhängigkeiten über die folgenden Bibliotheken paketieren, stellen Sie sicher, dass Sie die folgenden Mindestversionen oder neuere Versionen verwenden:
****
| Bibliothek | Unterstützte Mindestversion (x86) | Unterstützte Mindestversion (ARM) |
| --- | --- | --- |
| AWS SDK for Java 2.x | 2.23.20 | 2,26,12 |
| AWS Allgemeine Runtime für Java | 0.29.8 | 0,29,25 |
| Kryptoanbieter Amazon Corretto | 2.4.1 | 2.4.1 |
| Amazon Corretto Kryptoanbieter FIPS | 2.4.1 | 2.4.1 |
Die folgenden Beispiele zeigen, wie eindeutige Zahlenfolgen garantiert werden können CSPRNGs , auch wenn die Funktion aus einem Snapshot wiederhergestellt wird.
------
#### [ Java ]
**Example — java.security. SecureRandom**
```
import java.security.SecureRandom;
public class Handler implements RequestHandler {
private static SecureRandom rng = new SecureRandom();
@Override
public String handleRequest(String event, Context context) {
for (int i = 0; i < 10; i++) {
System.out.println(rng.next());
}
return "Hello, World!";
}
}
```
------
#### [ Python ]
**Example — zufällig. SystemRandom**
```
import json
import random
secure_rng = random.SystemRandom()
def lambda_handler(event, context):
random_numbers = [secure_rng.random() for _ in range(10)]
for number in random_numbers:
print(number)
return "Hello, World!"
```
------
#### [ .NET ]
**Example – RandomNumberGenerator**
```
using Amazon.Lambda.Core;
using System.Security.Cryptography;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace DotnetSecureRandom;
public class Function
{
public string FunctionHandler()
{
using (RandomNumberGenerator rng = RandomNumberGenerator.Create())
{
byte[] randomUnsignedInteger32Bytes = new byte[4];
for (int i = 0; i < 10; i++)
{
rng.GetBytes(randomUnsignedInteger32Bytes);
int randomInt32 = BitConverter.ToInt32(randomUnsignedInteger32Bytes, 0);
Console.WriteLine("{0:G}", randomInt32);
}
}
return "Hello World!";
}
}
```
------
## SnapStart Scan-Tool (nur Java)
Lambda bietet ein Scan-Tool für Java an, um nach Code zu suchen, der Eindeutigkeit voraussetzt. Das SnapStart Scan-Tool ist ein [SpotBugs](https://spotbugs.github.io/)Open-Source-Plugin, das eine statische Analyse anhand einer Reihe von Regeln durchführt. Das Scan-Tool hilft dabei, potenzielle Codeimplementierungen zu identifizieren, die Annahmen bezüglich der Eindeutigkeit widerlegen könnten. Installationsanweisungen und eine Liste der Prüfungen, die das Scan-Tool durchführt, finden Sie im Repository [aws-lambda-snapstart-java-rules](https://github.com/aws/aws-lambda-snapstart-java-rules) unter. GitHub
Weitere Informationen zum Umgang mit SnapStart Einzigartigkeit finden Sie unter [Schneller starten mit AWS Lambda SnapStart](https://aws.amazon.com/blogs/compute/starting-up-faster-with-aws-lambda-snapstart/) im AWS Compute-Blog.
# Implementieren Sie Code vor oder nach Lambda-Funktions-Snapshots
Sie können Laufzeit-Hooks verwenden, um Code zu implementieren, bevor Lambda einen Snapshot erstellt oder nachdem Lambda eine Funktion aus einem Snapshot fortsetzt. Laufzeit-Hooks sind für eine Vielzahl von Zwecken nützlich, z. B.:
+ **Bereinigung und Initialisierung:** Bevor ein Snapshot erstellt wird, können Sie einen Laufzeit-Hook verwenden, um Bereinigungs- oder Ressourcenfreigabeoperationen durchzuführen. Nachdem ein Snapshot wiederhergestellt wurde, können Sie einen Laufzeit-Hook verwenden, um alle Ressourcen oder Zustände, die nicht im Snapshot erfasst wurden, neu zu initialisieren.
+ **Dynamische Konfiguration:** Sie können Laufzeit-Hooks verwenden, um die Konfiguration oder andere Metadaten dynamisch zu aktualisieren, bevor ein Snapshot erstellt wird oder nachdem er wiederhergestellt wurde. Dies kann nützlich sein, wenn sich Ihre Funktion an Änderungen in der Laufzeitumgebung anpassen muss.
+ **Externe Integrationen:** Sie können Laufzeit-Hooks zur Integration mit externen Diensten oder Systemen verwenden, z. B. zum Senden von Benachrichtigungen oder zum Aktualisieren des externen Status als Teil des Checkpointing- und Wiederherstellungsprozesses.
+ **Leistungsoptimierung:** Sie können Laufzeit-Hooks verwenden, um die Startsequenz Ihrer Funktion fein abzustimmen, z. B. durch Vorladen von Abhängigkeiten. Weitere Informationen finden Sie unter [Leistungsoptimierung](snapstart-best-practices.md#snapstart-tuning).
Auf den folgenden Seiten wird erläutert, wie Sie Laufzeit-Hooks für Ihre bevorzugte Laufzeitumgebung implementieren.
**Topics**
+ [Java](snapstart-runtime-hooks-java.md)
+ [Python](snapstart-runtime-hooks-python.md)
+ [.NET](snapstart-runtime-hooks-dotnet.md)
# SnapStart Lambda-Laufzeit-Hooks für Java
Sie können Laufzeit-Hooks verwenden, um Code zu implementieren, bevor Lambda einen Snapshot erstellt oder nachdem Lambda eine Funktion aus einem Snapshot fortsetzt. Runtime-Hooks sind als Teil des Open-Source-Projekts Coordinated Restore at Checkpoint (CRaC) verfügbar. CRaC befindet sich in der Entwicklung für das [Open Java Development Kit (OpenJDK](https://wiki.openjdk.org/display/crac)). Ein Beispiel für die Verwendung von CRa C mit einer Referenzanwendung finden Sie im [CRaC-Repository](https://github.com/CRaC/docs/blob/master/STEP-BY-STEP.md) unter. GitHub CRaC verwendet drei Hauptelemente:
+ `Resource` – Eine Schnittstelle mit zwei Methoden, `beforeCheckpoint()` und `afterRestore()`. Verwenden Sie diese Methoden, um den Code zu implementieren, den Sie vor einem Snapshot und nach einer Wiederherstellung ausführen möchten.
+ `Context ` – Um Benachrichtigungen für Prüfpunkte und Wiederherstellungen zu erhalten, muss eine `Resource` mit einem `Context` registriert sein.
+ `Core` – Der Koordinationsservice, der das standardmäßige globale `Context` über die statische Methode `Core.getGlobalContext()` bereitstellt.
Weitere Informationen zu `Context` und `Resource` finden Sie unter [Package org.crac](https://javadoc.io/doc/io.github.crac/org-crac/latest/index.html) in der CRa C-Dokumentation.
Gehen Sie wie folgt vor, um Laufzeit-Hooks mit dem [Paket org.crac](https://github.com/CRaC/org.crac) zu implementieren. Die Lambda-Laufzeit enthält eine benutzerdefinierte CRa C-Kontextimplementierung, die Ihre Runtime-Hooks vor dem Checkpointing und nach der Wiederherstellung aufruft.
## Registrierung und Ausführung von Laufzeit-Hooks
Die Reihenfolge, in der Lambda Ihre Laufzeit-Hooks ausführt, wird durch die Reihenfolge der Registrierung bestimmt. Die Reihenfolge der Registrierung entspricht der Reihenfolge des Imports, der Definition oder der Ausführung in Ihrem Code.
+ `beforeCheckpoint()`: Wird in umgekehrter Reihenfolge der Registrierung ausgeführt
+ `afterRestore()`: Wird in Reihenfolge der Registrierung ausgeführt
Vergewissern Sie sich, dass alle registrierten Hooks ordnungsgemäß importiert und in den Code Ihrer Funktion aufgenommen wurden. Wenn Sie Laufzeit-Hooks in einer separaten Datei oder einem Modul registrieren, müssen Sie sicherstellen, dass das Modul entweder direkt oder als Teil eines größeren Pakets in der Handler-Datei Ihrer Funktion importiert wird. Wenn die Datei oder das Modul nicht in den Funktionshandler importiert wird, ignoriert Lambda die Laufzeithaken.
**Anmerkung**
Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist. Ihre `beforeCheckpoint()`-Laufzeit-Hooks werden auf das Zeitlimit des Initialisierungscodes angerechnet. Wenn Lambda einen Snapshot wiederherstellt, muss die Laufzeit geladen werden und `afterRestore()`-Laufzeit-Hooks müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine. SnapStartTimeoutException
## Schritt 1: Aktualisieren der Entwicklungskonfiguration
Fügen Sie die `org.crac`-Abhängigkeit zur Entwicklungskonfiguration hinzu. Im folgenden Beispiel wird Gradle verwendet. Beispiele für andere Entwicklungssysteme finden Sie in der [Apache-Maven-Dokumentation](https://search.maven.org/artifact/io.github.crac/org-crac/0.1.3/jar).
```
dependencies {
compile group: 'com.amazonaws', name: 'aws-lambda-java-core', version: '1.2.1'
# All other project dependecies go here:
# ...
# Then, add the org.crac dependency:
implementation group: 'org.crac', name: 'crac', version: '1.4.0'
}
```
## Schritt 2: Aktualisieren des Lambda-Handlers
Der Lambda-Funktions*handler* ist die Methode in Ihrem Funktionscode, die Ereignisse verarbeitet. Wenn Ihre Funktion aufgerufen wird, führt Lambda die Handler-Methode aus. Ihre Funktion wird so lange ausgeführt, bis der Handler eine Antwort zurückgibt, beendet wird oder ein Timeout auftritt.
Weitere Informationen finden Sie unter [Definieren des Lambda-Funktions-Handlers in Java](java-handler.md).
Der folgende Beispielhandler zeigt, wie Code vor Checkpointing (`beforeCheckpoint()`) und nach der Wiederherstellung (`afterRestore()`) ausgeführt wird. Dieser Handler registriert auch die `Resource` im Laufzeit-verwalteten globalen `Context`.
**Anmerkung**
Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist. Ihre `beforeCheckpoint()`-Laufzeit-Hooks werden auf das Zeitlimit des Initialisierungscodes angerechnet. Wenn Lambda einen Snapshot wiederherstellt, muss die Laufzeit (JVM) geladen werden und `afterRestore()`-Laufzeit-Hooks müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls bekommst du eine SnapStartTimeoutException.
```
...
import org.crac.Resource;
import org.crac.Core;
...
public class CRaCDemo implements RequestStreamHandler, Resource {
public CRaCDemo() {
Core.getGlobalContext().register(this);
}
public String handleRequest(String name, Context context) throws IOException {
System.out.println("Handler execution");
return "Hello " + name;
}
@Override
public void beforeCheckpoint(org.crac.Context context)
throws Exception {
System.out.println("Before checkpoint");
}
@Override
public void afterRestore(org.crac.Context context)
throws Exception {
System.out.println("After restore");
```
Der `Context` verwaltet nur ein [https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ref/WeakReference.html) auf dem registrierten Objekt. Wenn für eine [https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html](https://javadoc.io/static/io.github.crac/org-crac/0.1.3/org/crac/Resource.html) eine Garbage Collection durchgeführt wird, werden Laufzeit-Hooks nicht ausgeführt. Ihr Code muss einen starken Verweis auf die `Resource` beibehalten, um sicherzustellen, dass der Laufzeit-Hook ausgeführt wird.
Hier sind zwei Beispiele für zu vermeidende Muster:
**Example – Objekt ohne starke Referenz**
```
Core.getGlobalContext().register( new MyResource() );
```
**Example – Objekte anonymer Klassen**
```
Core.getGlobalContext().register( new Resource() {
@Override
public void afterRestore(Context context) throws Exception {
// ...
}
@Override
public void beforeCheckpoint(Context context) throws Exception {
// ...
}
} );
```
Behalten Sie stattdessen eine starke Referenz bei. Im folgenden Beispiel wird die registrierte Ressource nicht von der Garbage Collection erfasst und Laufzeit-Hooks werden konsistent ausgeführt.
**Example – Objekt mit starker Referenz**
```
Resource myResource = new MyResource(); // This reference must be maintained to prevent the registered resource from being garbage collected
Core.getGlobalContext().register( myResource );
```
# Lambda SnapStart-Laufzeit-Hooks für Python
Sie können Laufzeit-Hooks verwenden, um Code zu implementieren, bevor Lambda einen Snapshot erstellt oder nachdem Lambda eine Funktion aus einem Snapshot fortsetzt. Python-Laufzeit-Hooks sind als Teil der Open-Source-[Bibliothek Snapshot Restore für Python](https://pypi.org/project/snapshot-restore-py/) verfügbar, die in den von Python verwalteten Laufzeiten enthalten ist. Diese Bibliothek bietet zwei Dekoratoren, mit denen Sie Ihre Laufzeit-Hooks definieren können:
+ `@register_before_snapshot`: Für Funktionen, die Sie ausführen möchten, bevor Lambda einen Snapshot erstellt.
+ `@register_after_restore`: Für Funktionen, die Sie ausführen möchten, wenn Lambda eine Funktion aus einem Snapshot wieder aufnimmt.
Alternativ können Sie auch die folgenden Methoden verwenden, um Callables für Laufzeit-Hooks zu registrieren:
+ `register_before_snapshot(func, *args, **kwargs)`
+ `register_after_restore(func, *args, **kwargs)`
## Registrierung und Ausführung von Laufzeit-Hooks
Die Reihenfolge, in der Lambda Ihre Laufzeit-Hooks ausführt, wird durch die Reihenfolge der Registrierung bestimmt:
+ Vor dem Snapshot: Wird in umgekehrter Reihenfolge der Registrierung ausgeführt
+ Nach dem Snapshot: Wird in Reihenfolge der Registrierung ausgeführt
Die Reihenfolge der Registrierung von Hooks zur Laufzeit hängt davon ab, wie Sie die Hooks definieren. Wenn Sie Dekoratoren (`@register_before_snapshot` und `@register_after_restore`) verwenden, folgt die Reihenfolge der Registrierung der Reihenfolge des Imports, der Definition oder der Ausführung in Ihrem Code. Wenn Sie mehr Kontrolle über die Registrierungsreihenfolge benötigen, verwenden Sie die `register_before_snapshot()`- und `register_after_restore()`-Methoden anstelle von Dekoratoren.
Vergewissern Sie sich, dass alle registrierten Hooks ordnungsgemäß importiert und in den Code Ihrer Funktion aufgenommen wurden. Wenn Sie Laufzeit-Hooks in einer separaten Datei oder einem Modul registrieren, müssen Sie sicherstellen, dass das Modul entweder direkt oder als Teil eines größeren Pakets in der Handler-Datei Ihrer Funktion importiert wird. Wenn die Datei oder das Modul nicht in den Funktionshandler importiert wird, ignoriert Lambda die Laufzeithaken.
**Anmerkung**
Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist. Ihre `@register_before_snapshot`-Laufzeit-Hooks werden auf das Zeitlimit des Initialisierungscodes angerechnet. Wenn Lambda einen Snapshot wiederherstellt, muss die Laufzeit geladen werden und `@register_after_restore`-Laufzeit-Hooks müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine SnapStartTimeoutException.
## Beispiel
Der folgende Beispielhandler zeigt, wie Code vor Checkpointing (`@register_before_snapshot`) und nach der Wiederherstellung (`@register_after_restore`) ausgeführt wird.
```
from snapshot_restore_py import register_before_snapshot, register_after_restore
def lambda_handler(event, context):
# Handler code
@register_before_snapshot
def before_checkpoint():
# Logic to be executed before taking snapshots
@register_after_restore
def after_restore():
# Logic to be executed after restore
```
Weitere Beispiele finden Sie unter [Snapshot Restore für Python](https://github.com/aws/snapshot-restore-py/tree/main/examples) im AWS GitHub-Repository.
# Lambda SnapStart-Laufzeit-Hooks für .NET
Sie können Laufzeit-Hooks verwenden, um Code zu implementieren, bevor Lambda einen Snapshot erstellt oder nachdem Lambda eine Funktion aus einem Snapshot fortsetzt. .NET-Laufzeit-Hooks sind als Teil des [Amazon.Lambda.Core](https://www.nuget.org/packages/Amazon.Lambda.Core)-Pakets (Version 2.5.0 oder höher) verfügbar. Diese Bibliothek bietet zwei Methoden, mit denen Sie Ihre Laufzeit-Hooks definieren können:
+ `RegisterBeforeSnapshot()`: Code, der vor der Snapshot-Erstellung ausgeführt werden soll
+ `RegisterAfterSnapshot()`: Code, der nach der Wiederaufnahme einer Funktion aus einem Snapshot ausgeführt wird
**Anmerkung**
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 SnapStart sicherzustellen.
## Registrierung und Ausführung von Laufzeit-Hooks
Registrieren Sie Ihre Hooks in Ihrem Initialisierungscode. Beachten Sie die folgenden Richtlinien, die auf dem [Ausführungsmodell](csharp-handler.md#csharp-handler-setup) Ihrer Lambda-Funktion basieren:
+ Für den [Ansatz der ausführbaren Assemblierung](csharp-handler.md#csharp-executable-assembly-handlers) müssen Sie Ihre Hooks registrieren, bevor Sie den Lambda-Bootstrap mit `RunAsync` starten.
+ Für den [Ansatz der Klassenbibliothek](csharp-handler.md#csharp-class-library-handlers) registrieren Sie Ihre Hooks im Konstruktor der Handler-Klasse.
+ Für [ASP.NET Core-Anwendungen](csharp-package-asp.md) registrieren Sie Ihre Hooks, bevor Sie die `WebApplications.Run`-Methode aufrufen.
Um Laufzeit-Hooks für SnapStart in .NET zu registrieren, verwenden Sie die folgenden Methoden:
```
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
```
Wenn mehrere Hook-Typen registriert sind, wird die Reihenfolge, in der Lambda Ihre Laufzeit-Hooks ausführt, durch die Reihenfolge der Registrierung bestimmt:
+ `RegisterBeforeSnapshot()`: Wird in umgekehrter Reihenfolge der Registrierung ausgeführt
+ `RegisterAfterSnapshot()`: Wird in Reihenfolge der Registrierung ausgeführt
**Anmerkung**
Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist. Ihre `RegisterBeforeSnapshot()`-Laufzeit-Hooks werden auf das Zeitlimit des Initialisierungscodes angerechnet. Wenn Lambda einen Snapshot wiederherstellt, muss die Laufzeit geladen werden und `RegisterAfterSnapshot()`-Laufzeit-Hooks müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine SnapStartTimeoutException.
## Beispiel
Die folgende Beispielfunktion zeigt, wie Code vor Checkpointing (`RegisterBeforeSnapshot`) und nach der Wiederherstellung (`RegisterAfterRestore`) ausgeführt wird.
```
public class SampleClass
{
public SampleClass()
{
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint);
Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterCheckpoint);
}
private ValueTask BeforeCheckpoint()
{
// Add logic to be executed before taking the snapshot
return ValueTask.CompletedTask;
}
private ValueTask AfterCheckpoint()
{
// Add logic to be executed after restoring the snapshot
return ValueTask.CompletedTask;
}
public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
// Add business logic
return new APIGatewayProxyResponse
{
StatusCode = 200
};
}
}
```
# Überwachung für Lambda SnapStart
Sie können Ihre Lambda-SnapStart-Funktionen mit Amazon CloudWatch, AWS X-Ray und der [Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die Telemetrie-API](telemetry-api.md) überwachen.
**Anmerkung**
Die [Umgebungsvariablen](configuration-envvars.md#configuration-envvars-runtime) `AWS_LAMBDA_LOG_GROUP_NAME` und `AWS_LAMBDA_LOG_STREAM_NAME` sind in den Lambda-SnapStart-Funktionen nicht verfügbar.
## Verstehen des Protokollierungs- und Abrechnungsverhaltens mit SnapStart
Es gibt einige Unterschiede zum [CloudWatch-Protokollstream](monitoring-cloudwatchlogs.md)-Format für SnapStart-Funktionen:
+ **Initialisierungsprotokolle** – Wenn eine neue Ausführungsumgebung erstellt wird, enthält `REPORT` das Feld `Init Duration` nicht. Das liegt daran, dass Lambda SnapStart-Funktionen initialisiert, wenn Sie eine Version erstellen und nicht während des Funktionsaufrufs. Für SnapStart-Funktionen befindet sich das `Init Duration`-Feld im `INIT_REPORT`-Datensatz. Dieser Datensatz zeigt die Dauer von [Init-Phase](lambda-runtime-environment.md#runtimes-lifecycle-ib), einschließlich der Dauer aller `beforeCheckpoint`-[Laufizeit-Hooks](snapstart-runtime-hooks.md) an.
+ **Aufrufprotokolle** – Wenn eine neue Ausführungsumgebung erstellt wird, enthält `REPORT` die Felder `Restore Duration` und `Billed Restore Duration`:
+ `Restore Duration`: Die Zeit, die Lambda benötigt, um einen Snapshot wiederherzustellen, die Laufzeit zu laden und ggf. [Laufzeit-Hooks](snapstart-runtime-hooks.md) nach der Wiederherstellung auszuführen. Der Prozess der Wiederherstellung von Snapshots kann Zeit beinhalten, die für Aktivitäten außerhalb der MicroVM aufgewendet wird. Diese Zeit wird in erfasst `Restore Duration`.
+ `Billed Restore Duration`: Die Zeit, die Lambda benötigt, um die Laufzeit zu laden und ggf. [Laufzeit-Hooks](snapstart-runtime-hooks.md) nach der Wiederherstellung auszuführen.
**Anmerkung**
Wie bei allen Lambda-Funktionen fallen Dauergebühren für Code an, der im Funktionshandler ausgeführt wird. Bei SnapStart-Funktionen gelten die Gebühren für die Dauer auch für Initialisierungscode, der außerhalb des Handlers deklariert wird, für die Zeit, die die Laufzeit zum Laden benötigt, und für jeden Code, der in einem [Laufzeit-Hook](snapstart-runtime-hooks.md) ausgeführt wird.
Die Kaltstartdauer ist die Summe von `Restore Duration` \$1 `Duration`.
Das folgende Beispiel ist eine Lambda-Insights-Abfrage, die die Latenzperzentile für SnapStart-Funktionen zurückgibt. Weitere Informationen zu Lambda-Insights-Abfragen finden Sie unter [Beispiel-Workflow mit Abfragen zur Fehlerbehebung einer Funktion](monitoring-insights.md#monitoring-insights-queries).
```
filter @type = "REPORT"
| parse @log /\d+:\/aws\/lambda\/(?.*)/
| parse @message /Restore Duration: (?.*?) ms/
| stats
count(*) as invocations,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 50) as p50,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 90) as p90,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99) as p99,
pct(@duration+coalesce(@initDuration,0)+coalesce(restoreDuration,0), 99.9) as p99.9
group by function, (ispresent(@initDuration) or ispresent(restoreDuration)) as coldstart
| sort by coldstart desc
```
## Aktive X-Ray-Ablaufverfolgung für SnapStart
Sie können [X-Ray](services-xray.md) verwenden, um Anforderungen an Lambda-SnapStart-Funktionen nachzuverfolgen. Bei den X-Ray-Teilsegmenten für SnapStart-Funktionen gibt es einige Unterschiede:
+ Es gibt kein `Initialization`-Teilsegment für SnapStart-Funktionen.
+ Das Teilsegment `Restore` zeigt die Zeit an, die Lambda benötigt, um einen Snapshot wiederherzustellen, die Laufzeit zu laden und vorhandene [Laufzeit-Hooks](snapstart-runtime-hooks.md) nach der Wiederherstellung auszuführen. Der Prozess der Wiederherstellung von Snapshots kann Zeit beinhalten, die für Aktivitäten außerhalb der MicroVM aufgewendet wird. Diese Zeit wird im `Restore`-Untersegment erfasst. Die Zeit, die Sie außerhalb der microVM für die Wiederherstellung eines Snapshots aufwenden, wird Ihnen nicht in Rechnung gestellt.
## Telemetrie-API-Ereignisse für SnapStart
Lambda sendet die folgenden SnapStart-Ereignisse an [Telemetrie-API](telemetry-api.md):
+ [`platform.restoreStart`](telemetry-schema-reference.md#platform-restoreStart) – Zeigt die Zeit an, zu der die [`Restore`-Phase](lambda-runtime-environment.md#runtimes-lifecycle-restore) gestartet wurde.
+ [`platform.restoreRuntimeDone`](telemetry-schema-reference.md#platform-restoreRuntimeDone) – Zeigt an, ob die `Restore`-Phase erfolgreich war. Lambda sendet diese Nachricht, wenn die Laufzeit eine `restore/next`-Laufzeit-API-Anfrage sendet. Es gibt drei mögliche Status: erfolgreich, fehlgeschlagen und Timeout.
+ [`platform.restoreReport`](telemetry-schema-reference.md#platform-restoreReport) – Zeigt an, wie lange die `Restore`-Phase gedauert hat und wie viele Millisekunden Ihnen während dieser Phase in Rechnung gestellt wurden.
## Amazon-API-Gateway- und Funktions-URL-Metriken
Wenn Sie eine Web-API [mit API-Gateway](services-apigateway.md) erstellen, können Sie die [IntegrationLatency](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-metrics-and-dimensions.html)-Metrik verwenden, um die durchgehende Latenz zu messen (die Zeit zwischen der Weiterleitung einer Anfrage an das Backend durch API-Gateway und dem Empfang einer Antwort vom Backend.
Wenn Sie eine [Lambda-Funktions-URL](urls-configuration.md) verwenden, können Sie die [UrlRequestLatency](urls-monitoring.md)-Metrik verwenden, um die durchgehende Latenz zu messen (die Zeit zwischen dem Empfang einer Anfrage durch die Funktions-URL und der Rückgabe einer Antwort durch die Funktions-URL).
# Sicherheitsmodell für Lambda SnapStart
Lambda SnapStart unterstützt die Verschlüsselung im Ruhezustand. Lambda verschlüsselt Snapshots mit einem AWS KMS key. Standardmäßig verwendet Lambda einen Von AWS verwalteter Schlüssel. Wenn dieses Standardverhalten für Ihren Workflow geeignet ist, müssen Sie nichts weiter einrichten. Andernfalls können Sie die `--kms-key-arn`-Option im [create-function](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html)- oder [update-function-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-configuration.html)-Befehl verwenden, um einen vom AWS KMS-Kunden verwalteten Schlüssel bereitzustellen. Sie können dies tun, um die Rotation des KMS-Schlüssels zu steuern oder um die Anforderungen Ihrer Organisation für die Verwaltung von KMS-Schlüsseln zu erfüllen. Für vom Kunden verwaltete Schlüssel fallen Standard-AWS KMS-Gebühren an. Weitere Informationen finden Sie unter [AWS Key Management Service Preise](https://aws.amazon.com/kms/pricing/).
Wenn Sie eine SnapStart-Funktion oder Funktionsversion löschen, schlagen alle `Invoke`-Anfragen an diese Funktion oder Funktionsversion fehl. Lambda entfernt alle Ressourcen, die mit gelöschten Snapshots verknüpft sind, gemäß der Allgemeinen Datenschutzverordnung (DSGVO).
# Maximieren Sie die Lambda-Leistung SnapStart
**Topics**
+ [Leistungsoptimierung](#snapstart-tuning)
+ [Bewährte Praktiken für das Netzwerk](#snapstart-networking)
## Leistungsoptimierung
Beachten Sie die folgenden Empfehlungen zur Codeoptimierung für Ihre Runtime SnapStart, um die Vorteile von zu maximieren.
**Anmerkung**
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.
### Java
Um die Vorteile von zu maximieren SnapStart, empfehlen wir, Abhängigkeiten vorab zu laden und Ressourcen, die zur Startlatenz beitragen, in Ihrem Initialisierungscode statt im Funktionshandler zu initialisieren. Dadurch wird die Latenz, die mit dem Laden schwerer Klassen verbunden ist, aus dem Aufrufpfad entfernt, wodurch die Startleistung mit optimiert wird. SnapStart
Wenn Sie Abhängigkeiten oder Ressourcen nicht während der Initialisierung vorladen können, empfehlen wir Ihnen, sie mit Dummy-Aufrufen vorzuladen. Aktualisieren Sie dazu den Code des Funktionshandlers, wie im folgenden Beispiel aus der [Funktion pet store im](https://github.com/awslabs/aws-serverless-java-container/tree/main/samples/spring/pet-store) AWS GitHub Labs-Repository gezeigt.
```
private static SpringLambdaContainerHandler handler;
static {
try {
handler = SpringLambdaContainerHandler.getAwsProxyHandler(PetStoreSpringAppConfig.class);
// Use the onStartup method of the handler to register the custom filter
handler.onStartup(servletContext -> {
FilterRegistration.Dynamic registration = servletContext.addFilter("CognitoIdentityFilter", CognitoIdentityFilter.class);
registration.addMappingForUrlPatterns(EnumSet.of(DispatcherType.REQUEST), false, "/*");
});
// Send a fake Amazon API Gateway request to the handler to load classes ahead of time
ApiGatewayRequestIdentity identity = new ApiGatewayRequestIdentity();
identity.setApiKey("foo");
identity.setAccountId("foo");
identity.setAccessKey("foo");
AwsProxyRequestContext reqCtx = new AwsProxyRequestContext();
reqCtx.setPath("/pets");
reqCtx.setStage("default");
reqCtx.setAuthorizer(null);
reqCtx.setIdentity(identity);
AwsProxyRequest req = new AwsProxyRequest();
req.setHttpMethod("GET");
req.setPath("/pets");
req.setBody("");
req.setRequestContext(reqCtx);
Context ctx = new TestContext();
handler.proxy(req, ctx);
} catch (ContainerInitializationException e) {
// if we fail here. We re-throw the exception to force another cold start
e.printStackTrace();
throw new RuntimeException("Could not initialize Spring framework", e);
}
}
```
### Python
Um die Vorteile von zu maximieren SnapStart, konzentrieren Sie sich auf eine effiziente Codeorganisation und Ressourcenverwaltung innerhalb Ihrer Python-Funktionen. Als allgemeine Richtlinie gilt, dass Sie während der [Initialisierungsphase](lambda-runtime-environment.md#runtimes-lifecycle-ib) umfangreiche Rechenaufgaben ausführen sollten. Mit diesem Ansatz werden zeitaufwändige Operationen aus dem Aufrufpfad herausgenommen, was die Gesamtleistung der Funktion verbessert. Um diese Strategie wirksam umzusetzen, empfehlen wir die folgenden bewährten Verfahren:
+ Import von Abhängigkeiten außerhalb des Funktionshandlers.
+ Erstellen Sie `boto3`-Instances außerhalb des Handlers.
+ Initialisieren Sie statische Ressourcen oder Konfigurationen, bevor der Handler aufgerufen wird.
+ Erwägen Sie die Verwendung eines [Laufzeit-Hooks](snapstart-runtime-hooks-python.md) vor dem Snapshot für ressourcenintensive Aufgaben wie das Herunterladen externer Dateien, das Vorladen von Frameworks wie Django oder das Laden von Machine-Learning-Modellen.
**Example — Optimiere die Python-Funktion für SnapStart**
```
# Import all dependencies outside of Lambda handler
from snapshot_restore_py import register_before_snapshot
import boto3
import pandas
import pydantic
# Create S3 and SSM clients outside of Lambda handler
s3_client = boto3.client("s3")
# Register the function to be called before snapshot
@register_before_snapshot
def download_llm_models():
# Download an object from S3 and save to tmp
# This files will persist in this snapshot
with open('/tmp/FILE_NAME', 'wb') as f:
s3_client.download_fileobj('amzn-s3-demo-bucket', 'OBJECT_NAME', f)
...
def lambda_handler(event, context):
...
```
### .NET
Um die just-in-time (JIT-) Kompilierung und das Laden von Assemblys zu reduzieren, sollten Sie erwägen, Ihren Funktionshandler von einem `RegisterBeforeCheckpoint` [Runtime-Hook](snapstart-runtime-hooks-dotnet.md) aus aufzurufen. Aufgrund der Funktionsweise von .NET Tiered Compilation erhalten Sie optimale Ergebnisse, wenn Sie den Handler mehrfach aufrufen, wie im folgenden Beispiel gezeigt.
**Wichtig**
Vergewissern Sie sich, dass Ihr Dummy-Funktionsaufruf keine unbeabsichtigten Nebeneffekte hervorruft, wie z. B. das Auslösen von Geschäftstransaktionen.
**Example**
```
public class Function
{
public Function()
{
Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(FunctionWarmup);
}
// Warmup method that calls the function handler before snapshot to warm up the .NET code and runtime.
// This speeds up future cold starts after restoring from a snapshot.
private async ValueTask FunctionWarmup()
{
var request = new APIGatewayProxyRequest
{
Path = "/heathcheck",
HttpMethod = "GET"
};
for (var i = 0; i < 10; i++)
{
await FunctionHandler(request, null);
}
}
public async Task FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context)
{
//
// Process HTTP request
//
var response = new APIGatewayProxyResponse
{
StatusCode = 200
};
return await Task.FromResult(response);
}
}
```
## Bewährte Praktiken für das Netzwerk
Der Zustand der Verbindungen, die Ihre Funktion während der Initialisierungsphase erstellt, wird nicht garantiert, wenn Lambda Ihre Funktion aus einem Snapshot wieder aufnimmt. In den meisten Fällen werden Netzwerkverbindungen, die ein AWS SDK herstellt, automatisch wieder aufgenommen. Für andere Verbindungen empfehlen wir die folgenden bewährten Methoden.
**Wiederherstellen von Netzwerkverbindungen**
Stellen Sie Ihre Netzwerkverbindungen immer wieder her, wenn Ihre Funktion von einem Snapshot fortgesetzt wird. Wir empfehlen, dass Sie die Netzwerkverbindungen im Funktionshandler wiederherstellen. Alternativ können Sie ein After-Restore-[Laufzeit-Hook](snapstart-runtime-hooks.md) verwenden.
**Verwenden Sie den Hostnamen nicht als eindeutige ID der Ausführungsumgebung**
Wir raten davon ab, `hostname` zu verwenden, um Ihre Ausführungsumgebung als eindeutigen Knoten oder Container in Ihren Anwendungen zu identifizieren. Bei SnapStart wird ein einzelner Snapshot als Ausgangszustand für mehrere Ausführungsumgebungen verwendet. Alle Ausführungsumgebungen geben denselben `hostname`-Wert für `InetAddress.getLocalHost()` (Java), `socket.gethostname()` (Python) und `Dns.GetHostName()` (.NET) zurück. Für Anwendungen, die eine eindeutige Identität oder einen eindeutigen `hostname`-Wert der Ausführungsumgebung erfordern, empfehlen wir, im Funktionshandler eine eindeutige ID zu generieren. Oder verwenden Sie einen After-Restore-[Laufzeit-Hook](snapstart-runtime-hooks.md), um eine eindeutige ID zu generieren und verwenden Sie dann die eindeutige ID für die Ausführungsumgebung.
**Vermeiden der Bindung von Verbindungen an feste Quellports**
Wir empfehlen, Netzwerkverbindungen nicht an feste Quellports zu binden. Wenn eine Funktion nach einem Snapshot wieder aufgenommen wird, werden die Verbindungen neu aufgebaut, und Netzwerkverbindungen, die an einen festen Quellport gebunden sind, können fehlschlagen.
**Vermeiden der Verwendung von Java-DNS-Cache**
Lambda-Funktionen speichern DNS-Antworten bereits im Cache. Wenn Sie einen anderen DNS-Cache mit verwenden SnapStart, kann es zu Verbindungstimeouts kommen, wenn die Funktion von einem Snapshot aus wieder aufgenommen wird.
Die `java.util.logging.Logger`-Klasse kann indirekt den JVM-DNS-Cache aktivieren. Um die Standardeinstellungen zu überschreiben, setzen Sie [networkaddress.cache.ttl](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/net/InetAddress.html#inetaddress-caching-heading) auf 0, bevor Sie `logger` initialisieren. Beispiel:
```
public class MyHandler {
// first set TTL property
static{
java.security.Security.setProperty("networkaddress.cache.ttl" , "0");
}
// then instantiate logger
var logger = org.apache.logging.log4j.LogManager.getLogger(MyHandler.class);
}
```
Um `UnknownHostException`-Ausfälle in der Java 11-Laufzeit zu vermeiden, empfehlen wir, `networkaddress.cache.negative.ttl` auf 0 zu setzen. In Java 17 und späteren Laufzeiten ist dieser Schritt nicht erforderlich. Sie können diese Eigenschaft für eine Lambda-Funktion mit der Umgebungsvariablen `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0` festlegen.
Das Deaktivieren des JVM-DNS-Cache deaktiviert nicht das verwaltete DNS-Caching von Lambda.
# Behebung SnapStart von Fehlern für Lambda-Funktionen
Auf dieser Seite werden häufig auftretende Probleme behandelt, die bei der Verwendung von Lambda auftreten SnapStart, darunter Fehler bei der Snapshot-Erstellung, Timeoutfehler und interne Dienstfehler.
## SnapStartNotReadyException
**Fehler:** Beim Aufrufen der Operation Invoke20150331 ist ein Fehler aufgetreten (SnapStartNotReadyException): Lambda initialisiert Ihre Funktion. Sie ist aufrufbereit, sobald der Status Ihrer Funktion auf AKTIV gesetzt wird.
### Häufige Ursachen
Dieser Fehler tritt auf, wenn Sie versuchen, eine Funktionsversion aufzurufen, die sich im `Inactive` [Status](snapstart-activate.md#snapstart-function-states) befindet. Die Version Ihrer Funktion wird zu `Inactive`, wenn sie 14 Tage lang nicht mehr aufgerufen wurde oder wenn Lambda die Ausführungsumgebung periodisch recycelt
### Auflösung
Warten Sie, bis die Funktionsversion den `Active`-Status erreicht hat, und rufen Sie es dann erneut auf.
## SnapStartTimeoutException
**Problem:** Sie erhalten eine, `SnapStartTimeoutException` wenn Sie versuchen, eine Funktionsversion aufzurufen. SnapStart
### Häufige Ursache
In der [Wiederherstellungs](lambda-runtime-environment.md#runtimes-lifecycle-restore)phase stellt Lambda die Java-Laufzeit wieder her und führt alle [Laufzeit-Hooks](snapstart-runtime-hooks.md) nach der Wiederherstellung aus. Wenn ein Laufzeit-Hook nach der Wiederherstellung länger als 10 Sekunden läuft, wird die `Restore`-Phase unterbrochen und Sie erhalten einen Fehler, wenn Sie versuchen, die Funktion aufzurufen. Probleme mit der Netzwerkverbindung und den Anmeldeinformationen können auch zu `Restore`-Phase-Timeouts führen.
### Auflösung
Suchen Sie in den CloudWatch Protokollen der Funktion nach Timeoutfehlern, die während der [Wiederherstellungsphase](lambda-runtime-environment.md#runtimes-lifecycle-restore) aufgetreten sind. Stellen Sie sicher, dass alle Hooks nach der Wiederherstellung in weniger als 10 Sekunden abgeschlossen sind.
**Example CloudWatch protokollieren**
```
{ "cause": "Lambda couldn't restore the snapshot within the timeout limit. (Service: Lambda, Status Code: 408, Request ID: 11a222c3-410f-427c-ab22-931d6bcbf4f2)", "error": "Lambda.SnapStartTimeoutException"}
```
## 500 Interner Dienstfehler
**Fehler:** Lambda konnte keinen neuen Snapshot erstellen, weil Sie das Limit für die gleichzeitige Erstellung von Snapshots erreicht haben.
### Häufige Ursache
Ein 500-Fehler ist ein interner Fehler innerhalb des Lambda-Service selbst und kein Problem mit Ihrer Funktion oder Ihrem Code. Diese Fehler treten häufig sporadisch auf.
### Auflösung
Versuchen Sie erneut, die Funktionsversion zu veröffentlichen.
## 401 Nicht autorisiert
**Fehler:** Falsches Sitzungstoken oder Header-Schlüssel
### Häufige Ursache
Dieser Fehler tritt auf, wenn der [AWS Systems Manager Parameter Store und die AWS Secrets Manager Erweiterung](with-secrets-manager.md) mit Lambda SnapStart verwendet werden.
### Auflösung
Der AWS Systems Manager Parameterspeicher und die AWS Secrets Manager Erweiterung sind nicht kompatibel mit SnapStart. Die Erweiterung generiert Anmeldeinformationen für die Kommunikation mit ihnen AWS Secrets Manager während der Funktionsinitialisierung, was bei Verwendung von zu Fehlern mit abgelaufenen Anmeldeinformationen führt. SnapStart
## UnknownHostException (Java)
**Fehler:** HTTP-Anfrage kann nicht ausgeführt werden: Das Zertifikat für `abc.us-east-1.amazonaws.com` stimmt mit keinem der alternativen Namen des Betreffs überein.
### Häufige Ursache
Lambda-Funktionen speichern DNS-Antworten bereits im Cache. Wenn Sie einen anderen DNS-Cache mit verwenden SnapStart, kann es zu Verbindungs-Timeouts kommen, wenn die Funktion von einem Snapshot aus wieder aufgenommen wird.
### Auflösung
Um `UnknownHostException`-Ausfälle in der Java 11-Laufzeit zu vermeiden, empfehlen wir, `networkaddress.cache.negative.ttl` auf 0 zu setzen. In Java 17 und späteren Laufzeiten ist dieser Schritt nicht erforderlich. Sie können diese Eigenschaft für eine Lambda-Funktion mit der Umgebungsvariablen `AWS_LAMBDA_JAVA_NETWORKADDRESS_CACHE_NEGATIVE_TTL=0` festlegen.
## Fehler bei der Erstellung von Snapshots
**Fehler: Ihre** AWS Lambda Funktion konnte nicht aufgerufen werden. SnapStart Wenn dieser Fehler weiterhin besteht, überprüfen Sie die CloudWatch Protokolle Ihrer Funktion auf Initialisierungsfehler.
### Auflösung
Überprüfen Sie die CloudWatch Amazon-Logs Ihrer Funktion auf Timeouts vor dem [Checkpoint-Runtime-Hook](snapstart-runtime-hooks.md). Sie können auch versuchen, eine neue Funktionsversion zu veröffentlichen, wodurch das Problem manchmal behoben werden kann.
## Latenzzeit bei der Snapshot-Erstellung
**Problem:** Wenn Sie eine neue Funktionsversion veröffentlichen, bleibt die Funktion lange im `Pending` [Status](snapstart-activate.md#snapstart-function-states).
### Häufige Ursache
Wenn Lambda einen Snapshot erstellt, kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. Das Zeitlimit beträgt 130 Sekunden oder das [konfigurierte Funktions-Timeout](configuration-timeout.md) (maximal 900 Sekunden), je nachdem, welcher Wert höher ist.
Wenn Ihre Funktion mit einer [VPC verbunden ist](configuration-vpc.md#configuration-vpc-attaching), muss Lambda möglicherweise auch Netzwerkschnittstellen erstellen, bevor die Funktion `Active` wird. Wenn Sie versuchen, die Funktionsversion aufzurufen, während die Funktion `Pending` ist, erhalten Sie möglicherweise eine 409 `ResourceConflictException`. Wenn die Funktion über einen Amazon-API-Gateway-Endpunkt aufgerufen wird, erhalten Sie möglicherweise einen 500-Fehler im API Gateway.
### Auflösung
Warten Sie mindestens 15 Minuten, bis die Funktionsversion initialisiert ist, bevor Sie sie aufrufen.