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.
# Was ist AWS Lambda?
**Tipp**
Nehmen Sie an kostenlosen praktischen Workshops von Serverless-Experten teil, um zu erfahren, wie Sie mithilfe von Best Practices serverlose Anwendungen erstellen können. [Klicken Sie hier](https://aws-experience.com/amer/smb/events/series/Get-Hands-On-With-Serverless?trk=188abe3e-9f94-4e84-aefb-398d944ad567%26sc_channel%3Del), um sich anzumelden.
AWS Lambda ist ein Rechendienst, der Code ausführt, ohne dass Server verwaltet werden müssen. Ihr Code wird ausgeführt und automatisch nach oben und unten skaliert, mit pay-per-use Preisgestaltung. Um zu beginnen, sehen Sie sich [Erstellen Sie Ihre erste Funktion](getting-started.md) an.
Sie können Lambda für Folgendes verwenden:
+ **Dateiverarbeitung**: Dateien werden automatisch verarbeitet, wenn sie auf Amazon Simple Storage Service hochgeladen werden. Einzelheiten finden Sie in den [Beispielen zur Dateiverarbeitung](example-apps.md#examples-apps-file).
+ **Workflows mit langer Laufzeit:** Verwenden Sie [langlebige Lambda-Funktionen](durable-functions.md), um statusbehaftete, mehrstufige Workflows zu erstellen, die bis zu einem Jahr lang ausgeführt werden können. Perfekt für Auftragsabwicklung, Genehmigungsworkflows, human-in-the-loop Prozesse und komplexe Daten-Pipelines, die ihren Fortschritt speichern müssen.
+ **Beispiele für Datenbankoperationen und -integration**: Reagieren Sie auf Datenbankänderungen und automatisieren Sie Datenworkflows. Einzelheiten finden Sie in den [Datenbankbeispielen](example-apps.md#examples-apps-database).
+ **Geplante und regelmäßige Aufgaben**: Führen Sie automatisierte Vorgänge nach einem regelmäßigen Zeitplan aus mit EventBridge. Einzelheiten finden Sie in den [Beispielen für geplante Aufgaben](example-apps.md#examples-apps-scheduled).
+ **Stream-Verarbeitung**: Verarbeiten Sie Echtzeit-Datenströme für Analytik und Überwachung. Einzelheiten finden Sie unter [Kinesis Data Streams](with-kinesis.md).
+ **Webanwendungen**: Erstellen Sie skalierbare Webanwendungen, die sich automatisch an die Nachfrage anpassen.
+ **Mobile Backends**: Erstellen Sie sichere API-Backends für Mobil- und Webanwendungen.
+ **IoT-Backends**: Verarbeiten Sie Web-, Mobil-, IoT- und Drittanbieter-API-Anfragen. Weitere Details finden Sie unter [IoT](services-iot.md).
Preisinformationen finden Sie unter [AWS Lambda – Preise](https://aws.amazon.com/lambda/pricing/).
## Funktionsweise von Lambda
Wenn Sie Lambda verwenden, sind Sie nur für Ihren Code verantwortlich. Lambda führt Ihren Code auf einer hochverfügbaren Datenverarbeitungsinfrastruktur aus und verwaltet alle Datenverarbeitungsressourcen, einschließlich Server- und Betriebssystemwartung, Kapazitätsbereitstellung, automatische Skalierung und Protokollierung.
Da Lambda ein ereignisgesteuerter Serverless-Datenverarbeitungsdienst ist, verwendet er ein anderes Programmierparadigma als herkömmliche Webanwendungen. Das folgende Modell veranschaulicht die Funktionsweise von Lambda:
1. Sie schreiben und organisieren Ihren Code in [Lambda-Funktionen](concepts-basics.md#gettingstarted-concepts-function), die die grundlegenden Bausteine für die Erstellung einer Lambda-Anwendung darstellen.
1. Sie kontrollieren Sicherheit und Zugriff über [Lambda-Berechtigungen](lambda-permissions.md) und verwalten mithilfe von [Ausführungsrollen](lambda-intro-execution-role.md), mit welchen AWS Diensten Ihre Funktionen interagieren können und welche Ressourcenrichtlinien mit Ihrem Code interagieren können.
1. Ereignisquellen und AWS Dienste [lösen](concepts-event-driven-architectures.md) Ihre Lambda-Funktionen aus, indem sie Ereignisdaten im JSON-Format übergeben, die von Ihren Funktionen verarbeitet werden (dazu gehören auch Zuordnungen von Ereignisquellen).
1. [Lambda führt Ihren Code](concepts-how-lambda-runs-code.md) mit sprachspezifischen Laufzeiten (wie Node.js und Python) in Ausführungsumgebungen aus, die Ihre Laufzeit, Ebenen und Erweiterungen bündeln.
**Tipp**
Weitere Informationen zum Erstellen von **Serverless-Lösungen** finden Sie im [Serverless-Benutzerhandbuch](https://docs.aws.amazon.com/serverless/latest/devguide/).
## Schlüssel-Features
**Konfigurieren, Steuern und Bereitstellen sicherer Anwendungen:**
+ [Umgebungsvariablen](configuration-envvars.md): Modifizieren Sie das Verhalten von Anwendungen, ohne dass neuer Code bereitgestellt werden muss.
+ [Versionen](configuration-versions.md): Testen Sie neue Funktionen auf sichere Weise und sorgen Sie gleichzeitig für stabile Produktionsumgebungen.
+ [Lambda-Ebenen](chapter-layers.md): Optimieren Sie die Wiederverwendung und Wartung von Code, indem Sie gemeinsame Komponenten über mehrere Funktionen hinweg gemeinsam nutzen.
+ [Codesignatur](configuration-codesigning.md): Sorgen Sie für die Einhaltung der Sicherheitsbestimmungen, indem Sie sicherstellen, dass nur genehmigter Code die Produktionssysteme erreicht.
**Zuverlässiges Skalieren Arbeiten:**
+ [Parallelitäts- und Skalierungskontrollen](lambda-concurrency.md) steuern präzise die Reaktionsfähigkeit von Anwendungen und die Ressourcennutzung während Verkehrsspitzen.
+ [Lambda SnapStart](snapstart.md): Reduzieren Sie die Kaltstartzeiten erheblich. Lambda SnapStart kann eine Startleistung von nur unter einer Sekunde bieten, in der Regel ohne Änderungen an Ihrem Funktionscode.
+ [Antwort-Streaming](configuration-response-streaming.md): Optimieren Sie die Funktionsleistung, indem Sie große Nutzdaten schrittweise für die Echtzeitverarbeitung bereitstellen.
+ [Container-Images](images-create.md): Verpacken Sie Funktionen mit komplexen Abhängigkeiten mithilfe von Container-Workflows.
**Nahtloses Verbinden und Integrieren:**
+ [VPC-Netzwerke](configuration-vpc.md) sichern sensible Ressourcen und interne Dienste.
+ Die [Dateisystem](configuration-filesystem.md)-Integration nutzt persistente Daten gemeinsam und verwaltet zustandsbehaftete Vorgänge über Funktionsaufrufe hinweg.
+ [Funktion URLs](urls-configuration.md)erstellen Sie öffentlich zugängliche Endgeräte APIs und Endgeräte ohne zusätzliche Dienste.
+ [Lambda-Erweiterungen](lambda-extensions.md): Erweitern Sie die Funktionen durch Überwachungs-, Sicherheits- und Betriebstools.
## Ähnliche Informationen
+ Weitere Informationen zur Funktionsweise von Lambda finden Sie unter [Funktionsweise von Lambda](concepts-basics.md).
+ Informationen zum Einstieg in Lambda finden Sie unter [Erstellen Sie Ihre erste Lambda-Funktion](getting-started.md).
+ Eine Liste von Beispielanwendungen finden Sie unter [Erste Schritte mit Beispielanwendungen und -mustern](example-apps.md).
# Funktionsweise von Lambda
Lambda-Funktionen sind die grundlegenden Bausteine, die Sie zum Erstellen von Lambda-Anwendungen verwenden. Beim Schreiben von Funktionen ist es wichtig, die Kernkonzepte und -komponenten zu verstehen, aus denen das Lambda-Programmiermodell besteht. In diesem Abschnitt werden die grundlegenden Elemente vorgestellt, die Sie benötigen, um mit der Entwicklung von Serverless-Anwendungen mit Lambda zu beginnen.
+ **[Lambda-Funktionen und -Funktionshandler](#gettingstarted-concepts-function)**- Eine Lambda-Funktion ist ein kleiner Codeblock, der als Reaktion auf Ereignisse ausgeführt wird. Die Funktionen können standardmäßig (bis zu 15 Minuten) oder [dauerhaft](durable-functions.md) (bis zu einem Jahr) ausgeführt werden. Funktionen sind die grundlegenden Bausteine, die Sie zum Erstellen von Anwendungen verwenden. Funktionshandler sind der Einstiegspunkt für Ereignisobjekte, die Ihr Lambda-Funktionscode verarbeitet.
+ **[Lambda-Ausführungsumgebung und -Laufzeiten](#gettingstarted-concepts-runtime)**: Lambda-Ausführungsumgebungen verwalten die Ressourcen, die zum Ausführen Ihrer Funktion erforderlich sind. Für [langlebige Funktionen](durable-functions.md) umfasst die Ausführungsumgebung automatische Statusverwaltungs- und Checkpoint-Funktionen. Runtimes sind die sprachspezifischen Umgebungen, in denen Ihre Funktionen ausgeführt werden.
+ **[Ereignisse und Auslöser](#gettingstarted-concepts-event)**- Andere AWS-Services können Ihre Funktionen als Reaktion auf bestimmte Ereignisse aufrufen. Bei dauerhaften Funktionen können Ereignisse auch die Wiederaufnahme unterbrochener Workflows auslösen.
+ **[Lambda-Berechtigungen und -Rollen](#gettingstarted-concepts-permissions)**- Steuern Sie, wer auf Ihre Funktionen zugreifen kann und mit welchen anderen Funktionen AWS-Services Sie interagieren können. Dauerhafte Funktionen erfordern zusätzliche Berechtigungen für die Statusverwaltung und die erweiterte Ausführung.
**Tipp**
Wenn Sie die Entwicklung von Serverless-Komponenten zuerst besser verstehen möchten, lesen Sie die Informationen zum [Unterschied zwischen herkömmlicher Entwicklung und Serverless-Entwicklung](https://docs.aws.amazon.com/serverless/latest/devguide/serverless-shift-mindset.html) im *AWS -Serverless-Entwicklerhandbuch*.
## Lambda-Funktionen und -Funktionshandler
In Lambda sind **Funktionen** die grundlegenden Bausteine, mit denen Sie Anwendungen erstellen. Eine Lambda-Funktion ist ein Codeteil, der als Reaktion auf Ereignisse ausgeführt wird, z. B. wenn ein Benutzer auf eine Schaltfläche auf einer Website klickt oder eine Datei in einen Bucket in Amazon Simple Storage Service (Amazon S3) hochgeladen wird. Mit dauerhaften Funktionen kann Ihr Code die Ausführung zwischen den einzelnen Schritten unterbrechen und so den Status automatisch beibehalten. Dadurch eignen sie sich ideal für langwierige Workflows wie Auftragsverarbeitung oder Inhaltsmoderation. Sie können sich eine Funktion als eine Art eigenständiges Programm mit den folgenden Eigenschaften vorstellen.
Ein Lambda-**Funktionshandler** ist die Methode in Ihrem Funktionscode, die Ereignisse verarbeitet. Wenn eine Funktion als Reaktion auf ein Ereignis ausgeführt wird, führt Lambda den Funktionshandler aus. Daten zum Ereignis, das die Ausführung der Funktion verursacht hat, werden direkt an den Handler übergeben. Während der Code in einer Lambda-Funktion mehrere Methoden oder Funktionen enthalten kann, können Lambda-Funktionen nur einen Handler enthalten.
Um eine Lambda-Funktion zu erstellen, bündeln Sie den Funktionscode und die zugehörigen Abhängigkeiten in einem Bereitstellungspaket. Lambda unterstützt zwei Arten von Bereitstellungspaketen: [ZIP-Dateiarchive](configuration-function-zip.md) und [Container-Images](images-create.md).
+ Eine Funktion hat eine bestimmte Aufgabe oder einen bestimmten Zweck.
+ Sie wird nur ausgeführt, wenn sie als Reaktion auf bestimmte Ereignisse benötigt wird.
+ Sie wird automatisch beendet, wenn sie fertig ist.
## Lambda-Ausführungsumgebung und -Laufzeiten
Lambda-Funktionen werden in einer sicheren, isolierten *[Ausführungsumgebung](lambda-runtime-environment.md)* ausgeführt, die Lambda für Sie verwaltet. Für [langlebige Funktionen](durable-functions.md) umfasst die Ausführungsumgebung zusätzliche Komponenten für die Statusverwaltung und die Workflow-Koordination. Die Ausführungsumgebung verwaltet die Prozesse und Ressourcen, die für die Ausführung Ihrer Funktion erforderlich sind. Wenn eine Funktion zum ersten Mal aufgerufen wird, erstellt Lambda eine neue Ausführungsumgebung, in der die Funktion ausgeführt werden kann. Nachdem die Ausführung der Funktion abgeschlossen wurde, beendet Lambda die Ausführungsumgebung nicht sofort. Wenn die Funktion erneut aufgerufen wird, kann Lambda die vorhandene Ausführungsumgebung wiederverwenden.
Die Lambda-Ausführungsumgebung enthält außerdem eine *Laufzeit*, eine sprachspezifische Umgebung, die Ereignisinformationen und Antworten zwischen Lambda und Ihrer Funktion weiterleitet. Lambda bietet eine Reihe von [verwalteten Laufzeiten](lambda-runtimes.md#runtimes-supported) für die gängigsten Programmiersprachen, Sie können aber auch eigene erstellen.
Bei verwalteten Laufzeiten wendet Lambda automatisch Sicherheitsupdates und Patches auf Funktionen an, die die Laufzeit verwenden.
## Ereignisse und Auslöser
Sie können eine Lambda-Funktion auch direkt aufrufen, [AWS CLI](https://aws.amazon.com/cli/)indem Sie die Lambda-Konsole oder eines der [AWS Software Development Kits](https://aws.amazon.com/developer/tools/) () verwenden. SDKs In einer Produktionsanwendung ist es üblicher, dass Ihre Funktion als Reaktion auf ein bestimmtes Ereignis von einer anderen AWS-Service aufgerufen wird. Sie möchten beispielsweise, dass eine Funktion immer dann ausgeführt wird, wenn ein Element zu einer Amazon-DynamoDB-Tabelle hinzugefügt wird.
Damit Ihre Funktion auf Ereignisse reagiert, richten Sie einen **Auslöser** ein. Ein Auslöser verbindet Ihre Funktion mit einer Ereignisquelle und Ihre Funktion kann mehrere Auslöser haben. Wenn ein Ereignis eintritt, empfängt Lambda Ereignisdaten als JSON-Dokument und konvertiert es in ein Objekt, das Ihr Code verarbeiten kann. Sie können das folgende JSON-Format für Ihr Ereignis definieren und die Lambda-Laufzeit konvertiert dieses JSON-Dokument in ein Objekt, bevor es an den Handler Ihrer Funktion übergeben wird.
**Example Benutzerdefiniertes Lambda-Ereignis**
```
{
"Location": "SEA",
"WeatherData":{
"TemperaturesF":{
"MinTempF": 22,
"MaxTempF": 78
},
"PressuresHPa":{
"MinPressureHPa": 1015,
"MaxPressureHPa": 1027
}
}
}
```
Stream- und Warteschlangendienste wie Amazon Kinesis oder Amazon SQS verwenden eine [Ereignisquellenzuordnung](invocation-eventsourcemapping.md) anstelle eines Standardauslösers. Bei Zuordnungen von Ereignisquellen wird die Quelle nach neuen Daten abgefragt, Datensätze gebündelt und anschließend Ihre Funktion mit den gebündelten Ereignissen aufgerufen. Weitere Informationen finden Sie unter [Wie unterscheiden sich Zuordnungen von Ereignisquellen von direkten Auslösern](invocation-eventsourcemapping.md#eventsourcemapping-trigger-difference).
Um zu verstehen, wie ein Auslöser funktioniert, beginnen Sie mit dem Tutorial [Verwenden eines Amazon-S3-Auslösers](with-s3-example.md). Einen allgemeinen Überblick über die Verwendung von Auslösern und Anweisungen zum Erstellen eines Auslösers mithilfe der Lambda-Konsole finden Sie unter [Integration anderer Services](lambda-services.md).
## Lambda-Berechtigungen und -Rollen
Bei Lambda gibt es zwei Haupttypen von [Berechtigungen](permissions-granting-access.md), die Sie konfigurieren müssen:
+ Berechtigungen, die Ihre Funktion benötigt, um auf andere zuzugreifen AWS-Services
+ Berechtigungen, die andere Benutzer für den Zugriff auf Ihre Funktion AWS-Services benötigen
In den folgenden Abschnitten werden diese beiden Berechtigungstypen beschrieben und bewährte Methoden für die Anwendung von geringsten Berechtigungen erörtert.
### Berechtigungen für Funktionen, um auf andere AWS Ressourcen zuzugreifen
Lambda-Funktionen müssen häufig auf andere AWS Ressourcen zugreifen und Aktionen mit ihnen ausführen. Eine Funktion könnte beispielsweise Elemente aus einer DynamoDB-Tabelle lesen, ein Objekt in einem S3-Bucket speichern oder in eine Amazon-SQS-Warteschlange schreiben. *[Um Funktionen die Berechtigungen zu geben, die sie für die Ausführung dieser Aktionen benötigen, verwenden Sie eine Ausführungsrolle](lambda-intro-execution-role.md)*.
*Eine Lambda-Ausführungsrolle ist eine besondere [Rolle AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) (IAM), eine Identität, die Sie in Ihrem Konto erstellen und der in einer Richtlinie bestimmte Berechtigungen zugeordnet sind.*
Jede Lambda-Funktion muss eine Ausführungsrolle haben und eine einzelne Rolle kann von mehr als einer Funktion verwendet werden. Wenn eine Funktion aufgerufen wird, übernimmt Lambda die Ausführungsrolle der Funktion und erhält die Berechtigung, die in der Richtlinie der Rolle definierten Aktionen auszuführen.
Wenn Sie eine Funktion in der Lambda-Konsole erstellen, erstellt Lambda automatisch eine Ausführungsrolle für Ihre Funktion. Die Rollenrichtlinie gibt Ihrer Funktion grundlegende Berechtigungen zum Schreiben von Protokollausgaben in Amazon CloudWatch Logs. Um Ihrer Funktion die Erlaubnis zu erteilen, Aktionen mit anderen AWS Ressourcen durchzuführen, müssen Sie die Rolle bearbeiten, um die zusätzlichen Berechtigungen hinzuzufügen. Der einfachste Weg, Berechtigungen hinzuzufügen, ist die Verwendung einer AWS [verwalteten Richtlinie](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies). Verwaltete Richtlinien werden von vielen gängigen Anwendungsfällen erstellt AWS und verwaltet und bieten Berechtigungen für diese. Wenn Ihre Funktion beispielsweise CRUD-Operationen an einer DynamoDB-Tabelle ausführt, können Sie die [AmazonDynamoDBFullAccess-Richtlinie](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonDynamoDBFullAccess.html) zu Ihrer Rolle hinzufügen.
### Berechtigungen für andere Benutzer und Ressourcen für den Zugriff auf Ihre Funktion
Um anderen AWS-Service Zugriffsberechtigungen auf Ihre Lambda-Funktion zu gewähren, verwenden Sie eine *[ressourcenbasierte Richtlinie](access-control-resource-based.md)*. In IAM werden ressourcenbasierte Richtlinien einer Ressource zugeordnet (in diesem Fall Ihrer Lambda-Funktion). Sie definieren, wer auf die Ressource zugreifen kann und welche Aktionen sie ausführen können.
Damit eine andere AWS-Service Funktion Ihre Funktion über einen Trigger aufrufen kann, muss die ressourcenbasierte Richtlinie Ihrer Funktion diesem Dienst die Erlaubnis erteilen, die Aktion zu verwenden. `lambda:InvokeFunction` Wenn Sie den Auslöser mit der Konsole erstellen, fügt Lambda diese Berechtigung automatisch für Sie hinzu.
Um anderen AWS Benutzern die Erlaubnis zu erteilen, auf Ihre Funktion zuzugreifen, können Sie dies in der ressourcenbasierten Richtlinie Ihrer Funktion genauso definieren wie für eine andere OR-Ressource. AWS-Service Sie können auch eine *[identitätsbasierte Richtlinie](access-control-identity-based.md)* verwenden, die dem Benutzer zugeordnet ist.
### Bewährte Methoden für Lambda-Berechtigungen
Wenn Sie Berechtigungen mithilfe von IAM-Richtlinien festlegen, empfiehlt es sich aus [Sicherheitsgründen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) nur die zum Ausführen einer Aufgabe erforderlichen Berechtigungen zu erteilen. Dies wird als Prinzip der *geringsten Berechtigungen* bezeichnet. Um mit der Gewährung von Berechtigungen für Ihre Funktion zu beginnen, können Sie sich für die Verwendung einer AWS verwalteten Richtlinie entscheiden. Verwaltete Richtlinien können die schnellste und einfachste Methode sein, um Berechtigungen für die Ausführung einer Aufgabe zu erteilen. Sie können jedoch auch andere Berechtigungen beinhalten, die Sie nicht benötigen. Wenn Sie von der frühen Entwicklungsphase über die Testphase bis hin zur Produktion voranschreiten, empfehlen wir Ihnen, die Berechtigungen auf die erforderlichen zu reduzieren, indem Sie Ihre eigenen [vom Kunden verwalteten Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) definieren.
Das gleiche Prinzip gilt für die Erteilung von Berechtigungen für den Zugriff auf Ihre Funktion mithilfe einer ressourcenbasierten Richtlinie. Wenn Sie beispielsweise Amazon S3 die Erlaubnis geben möchten, Ihre Funktion aufzurufen, empfiehlt es sich, den Zugriff auf einzelne Buckets oder insbesondere Buckets zu beschränken AWS-Konten, anstatt dem S3-Service pauschale Berechtigungen zu erteilen.
# Ausführen von Code mit Lambda
Wenn Sie eine Lambda-Funktion schreiben, erstellen Sie Code, der in einer eindeutigen Serverless-Umgebung ausgeführt wird. Um zu verstehen, wie Lambda Ihren Code tatsächlich ausführt, müssen Sie zwei wichtige Aspekte kennen: das Programmiermodell, das definiert, wie Ihr Code mit Lambda interagiert, und den Lebenszyklus der Ausführungsumgebung, der bestimmt, wie Lambda die Laufzeitumgebung Ihres Codes verwaltet.
## Das Lambda-Programmiermodell
Das Programmiermodell dient als allgemeines Regelwerk dafür, wie Lambda mit Ihrem Code arbeitet, unabhängig davon, ob Sie in Python, Java oder einer anderen unterstützten Sprache schreiben. Das Programmiermodell umfasst Ihre Laufzeit und Ihren Handler.
**Für Standardfunktionen:**
1. Lambda empfängt ein Ereignis.
1. Lambda verwendet die Laufzeit, um das Ereignis in einem Format vorzubereiten, das Ihr Code verwenden kann.
1. Die Laufzeit sendet das formatierte Ereignis an Ihren Handler.
1. Ihr Handler verarbeitet das Ereignis mit dem Code, den Sie geschrieben haben.
**Für langlebige Funktionen:**
1. Lambda empfängt ein Ereignis
1. Die Runtime bereitet sowohl das Ereignis als auch DurableContext
1. Ihr Handler kann:
+ Prozessschritte mit automatischem Checkpointing
+ Unterbrechen Sie die Ausführung, ohne Ressourcen zu verbrauchen
+ Fahren Sie mit dem letzten erfolgreichen Checkpoint fort
+ Behalten Sie den Status zwischen den Schritten bei
Wesentlich für dieses Modell ist der *Handler*, an den Lambda Ereignisse sendet, die von Ihrem Code verarbeitet werden sollen. Betrachten Sie ihn als Einstiegspunkt für Ihren Code. Wenn Lambda ein Ereignis empfängt, leitet es dieses Ereignis und einige Kontextinformationen an Ihren Handler weiter. Der Handler führt dann Ihren Code aus, um diese Ereignisse zu verarbeiten – beispielsweise kann er eine Datei lesen, wenn sie in Amazon S3 hochgeladen wird, ein Bild analysieren oder eine Datenbank aktualisieren. Sobald Ihr Code die Verarbeitung eines Ereignisses abgeschlossen hat, ist der Handler bereit, das nächste Ereignis zu verarbeiten.
## Das Lambda-Ausführungsmodell
Während das Programmiermodell definiert, wie Lambda mit Ihrem Code interagiert, ist die Ausführungsumgebung der Ort, an dem Lambda Ihre Funktion tatsächlich ausführt — es handelt sich um einen sicheren, isolierten Rechenraum, der speziell für Ihre Funktion erstellt wurde.
**Jede Umgebung folgt einem Lebenszyklus, der zwischen Standardfunktionen und dauerhaften Funktionen variiert:**
**Standardfunktionen (bis zu 15 Minuten):**
1. **Initialisierung:** Einrichtung der Umgebung und Laden von Code
1. **Aufruf: Einmalige** Ausführung des Funktionscodes
1. **Herunterfahren: Bereinigung** der Umgebung
**Dauerhafte Funktionen (bis zu 1 Jahr):**
1. **Initialisierung: Einrichtung** der Umgebung und des dauerhaften Zustands
1. **Aufruf:** Mehrere Schritte mit automatischem Checkpointing
1. **Wartestatus:** Unterbrechen Sie die Ausführung ohne Ressourcenverbrauch
1. **Fortfahren:** Vom letzten Checkpoint aus neu starten
1. **Herunterfahren:** Bereinigung des dauerhaften Zustands
Diese Umgebung übernimmt wichtige Aspekte der Ausführung Ihrer Funktion. Sie stellt Ihrer Funktion Speicher und ein `/tmp`-Verzeichnis für die temporäre Speicherung zur Verfügung. **Für langlebige Funktionen verwaltet es außerdem:**
+ Automatische Beibehaltung des Zustands zwischen den Schritten
+ Checkpoint-Speicherung und Wiederherstellung
+ Warten Sie die staatliche Koordination
+ Verfolgung des Fortschritts bei lang andauernden Ausführungen
# Grundlegendes zum Lambda-Programmiermodell
Lambda bietet zwei Programmiermodelle: Standardfunktionen, die bis zu 15 Minuten laufen, und Durable Functions, die bis zu einem Jahr laufen können. Beide haben zwar gemeinsame Kernkonzepte, Durable Functions bieten jedoch zusätzliche Funktionen für langwierige, zustandsbehaftete Workflows.
Lambda stellt ein Programmiermodell bereit, das allen Laufzeitumgebungen gemeinsam ist. Das Programmiermodell definiert die Schnittstelle zwischen Ihrem Code und dem Lambda-System. Sie teilen Lambda den Einstiegspunkt für Ihre Funktion mit, indem Sie einen *Handler* in der Funktionskonfiguration definieren. Die Laufzeit übergibt Objekte an den Handler, die das *Aufrufereignis* und den *Kontext*, wie z. B. den Funktionsnamen und die Anforderungs-ID, enthalten.
**Bei Durable Functions erhält der Handler außerdem ein DurableContext Objekt, das Folgendes bereitstellt:**
+ Überprüfen Sie die Funktionen mithilfe von step ()
+ Warten Sie die Statusverwaltung mit wait () und waitForCallback ()
+ Automatische Statuspersistenz zwischen Aufrufen
Wenn der Handler die Verarbeitung des ersten Ereignisses beendet hat, sendet die Laufzeit ihm ein anderes. Bei dauerhaften Funktionen kann der Handler die Ausführung zwischen den Schritten unterbrechen, und Lambda speichert den Status automatisch und stellt ihn wieder her, wenn die Funktion wieder aufgenommen wird. Die Klasse der Funktion bleibt im Speicher, sodass Clients und Variablen, die außerhalb der Handler-Methode in *Initialisierungscode*deklariert sind, wiederverwendet werden können. Um die Verarbeitungszeit bei nachfolgenden Ereignissen zu verkürzen, erstellen Sie während der Initialisierung wiederverwendbare Ressourcen wie AWS SDK-Clients. Nach der Initialisierung kann jede Instance Ihrer Funktion Tausende von Anfragen verarbeiten.
Ihre Funktion hat auch Zugriff auf den lokalen Speicher im `/tmp`-Verzeichnis, einen temporären Zwischenspeicher, der für mehrere Aufrufe verwendet werden kann. Weitere Informationen finden Sie unter [Ausführungsumgebung](lambda-runtime-environment.md).
Wenn die [AWS X-Ray -Ablaufverfolgung](services-xray.md) aktiviert ist, zeichnet die Laufzeitumgebung separate Untersegmente für die Initialisierung und Ausführung auf.
Die Runtime erfasst die Protokollausgabe Ihrer Funktion und sendet sie an Amazon CloudWatch Logs. Neben der Protokollierung der Ausgabe Ihrer Funktion protokolliert die Laufzeitumgebung auch Einträge, wenn der Funktionsaufruf gestartet und beendet wird. Dazu gehört ein Berichtsprotokoll mit der Anforderungskennung, der fakturierten Dauer, der Initialisierungsdauer und weiteren Details. Wenn Ihre Funktion einen Fehler ausgibt, gibt die Laufzeit diesen Fehler an den Aufrufer zurück.
**Anmerkung**
Die Protokollierung unterliegt den [CloudWatch Log-Kontingenten](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html). Protokolldaten können durch Ablehnung verloren gehen, oder, in einigen Fällen, wenn eine Instance Ihrer Funktion gestoppt wird.
**Hauptunterschiede bei Durable Functions:**
+ Der Status wird zwischen den Schritten automatisch beibehalten
+ Funktionen können die Ausführung unterbrechen, ohne Ressourcen zu verbrauchen
+ Bei einem Fehler werden die Schritte automatisch wiederholt
+ Der Fortschritt wird anhand von Checkpoints verfolgt
Lambda skaliert Ihre Funktion, indem zusätzliche Instances davon ausgeführt werden, wenn der Bedarf steigt und indem Instances beendet werden, wenn der Bedarf sinkt. Dieses Modell führt zu Variationen in der Anwendungsarchitektur, wie zum Beispiel:
+ Sofern nicht anders angegeben, werden eingehende Anforderungen nicht in der richtigen Reihenfolge oder gleichzeitig verarbeitet.
+ Verlassen Sie sich nicht darauf, dass die Instances Ihrer Funktion langlebig sind, sondern speichern Sie den Zustand Ihrer Anwendung an anderer Stelle.
+ Verwenden Sie lokale Speicher und Objekte auf Klassenebene, um die Leistung zu steigern, aber halten Sie die Größe Ihres Bereitstellungspakets und die Datenmenge, die Sie in die Ausführungsumgebung übertragen, möglichst gering.
In den folgenden Kapiteln finden Sie eine praktische Einführung in das Programmiermodell in Ihrer bevorzugten Programmiersprache.
+ [Erstellen von Lambda-Funktionen mit Node.js](lambda-nodejs.md)
+ [Erstellen von Lambda-Funktionen mit Python](lambda-python.md)
+ [Erstellen von Lambda-Funktionen mit Ruby](lambda-ruby.md)
+ [Erstellen von Lambda-Funktionen mit Java](lambda-java.md)
+ [Erstellen von Lambda-Funktionen mit Go](lambda-golang.md)
+ [Erstellen von Lambda-Funktionen mit C\$1](lambda-csharp.md)
+ [Aufbau von Lambda-Funktionen mit PowerShell](lambda-powershell.md)
# Verständnis des Lebenszyklus der Lambda-Ausführungsumgebung
Lambda-Ausführungsumgebungen unterstützen sowohl Standardfunktionen (bis zu 15 Minuten) als auch dauerhafte Funktionen (bis zu einem Jahr). Beide haben zwar denselben grundlegenden Lebenszyklus, Durable Functions bieten jedoch zusätzliche Funktionen zur Statusverwaltung für Workflows mit langer Laufzeit.
Lambda ruft Ihre Funktion in einer Ausführungsumgebung auf, die eine sichere und isolierte Laufzeitumgebung bereitstellt. Die Ausführungsumgebung verwaltet die Ressourcen, die zum Ausführen Ihrer Funktion erforderlich sind. Die Ausführungsumgebung bietet auch Lebenszyklusunterstützung für die Laufzeit der Funktion und alle [externen Erweiterungen](lambda-extensions.md) die mit Ihrer Funktion verknüpft sind.
**Für Durable Functions umfasst die Ausführungsumgebung zusätzliche Komponenten für:**
+ Persistenz des Zustands zwischen den Schritten
+ Verwaltung von Kontrollpunkten
+ Warten Sie auf die staatliche Koordination
+ Verfolgung der Fortschritte
**Ausführungsumgebung für Lambda Managed Instances**
Wenn Sie [Lambda Managed Instances](lambda-managed-instances-execution-environment.md) verwenden, weist die Ausführungsumgebung wichtige Unterschiede zu Lambda-Funktionen (Standard) auf. Verwaltete Instances unterstützen gleichzeitige Aufrufe, verwenden ein anderes Lebenszyklusmodell und werden auf einer kundeneigenen Infrastruktur ausgeführt. Ausführliche Informationen zur Ausführungsumgebung von Managed Instances finden Sie unter. [Grundlegendes zur Ausführungsumgebung von Lambda Managed Instances](lambda-managed-instances-execution-environment.md)
Die Laufzeitumgebung der Funktion kommuniziert Lambda mit der [Laufzeit-API](runtimes-api.md). Erweiterungen kommunizieren mit Lambda über die [Erweiterungs-API](runtimes-extensions-api.md). Erweiterungen können mithilfe der [Telemetrie-API](telemetry-api.md) auch Protokollnachrichten und andere Telemetriedaten von der Funktion empfangen.
![\[Architekturdiagramm der Ausführungsumgebung.\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/telemetry-api-concept-diagram.png)
Wenn Sie Ihre Lambda-Funktion erstellen, geben Sie Konfigurationsinformationen an, z. B. den verfügbaren Arbeitsspeicher und die maximal zulässige Ausführungszeit für Ihre Funktion. Lambda verwendet diese Informationen, um die Ausführungsumgebung einzurichten.
Die Laufzeit der Funktion und jede externe Erweiterung sind Prozesse, die innerhalb der Ausführungsumgebung ausgeführt werden. Berechtigungen, Ressourcen, Anmeldeinformationen und Umgebungsvariablen werden von der Funktion und den Erweiterungen gemeinsam genutzt.
**Topics**
+ [
## Lebenszyklus der Lambda-Ausführungsumgebung
](#runtimes-lifecycle)
+ [
## Kaltstarts und Latenzzeiten
](#cold-start-latency)
+ [
## Reduzierung von Kaltstarts mit bereitgestellter Parallelität
](#cold-starts-pc)
+ [
## Optimierung der statischen Initialisierung
](#static-initialization)
## Lebenszyklus der Lambda-Ausführungsumgebung
![\[Lambda-Lebenszyklusphasen: Init, Invoke, Shutdown\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Overview-Successful-Invokes.png)
Jede Phase beginnt mit einem Ereignis, das Lambda an die Laufzeit und an alle registrierten Erweiterungen sendet. Die Laufzeit und jede Erweiterung zeigen den Abschluss durch Senden einer `Next`-API-Anfrage an. Lambda friert die Ausführungsumgebung ein, wenn die Laufzeit und jede Erweiterung abgeschlossen sind und keine ausstehenden Ereignisse vorhanden sind.
**Zu den Lebenszyklusphasen von Durable Functions gehören:**
+ **Init:** Standardinitialisierung plus Einrichtung eines dauerhaften Zustands
+ **Invoke:** Kann die Ausführung mehrerer Schritte mit automatischem Checkpointing beinhalten
+ **Warte:** Die Funktion kann die Ausführung unterbrechen, ohne Ressourcen zu verbrauchen
+ **Fortfahren:** Die Funktion wird vom letzten Checkpoint aus neu gestartet
+ **Herunterfahren: Wiederherstellung** des dauerhaften Zustands und der Ressourcen
**Topics**
+ [
### Init-Phase
](#runtimes-lifecycle-ib)
+ [
### Fehler in der Initialisierungsphase
](#runtimes-lifecycle-init-errors)
+ [
### Wiederherstellungsphase ( SnapStart nur Lambda)
](#runtimes-lifecycle-restore)
+ [
### Invoke-Phase
](#runtimes-lifecycle-invoke)
+ [
### Fehler während der Aufrufphase
](#runtimes-lifecycle-invoke-with-errors)
+ [
### Shutdown-Phase
](#runtimes-lifecycle-shutdown)
### Init-Phase
Lambda führt in der `Init`-Phase drei Aufgaben aus:
+ Alle Erweiterungen starten (`Extension init`)
+ Laufzeit-Bootstrap (`Runtime init`)
+ Ausführen des statischen Codes der Funktion (`Function init`)
+ Alle [Runtime-Hooks](snapstart-runtime-hooks.md) vor dem Checkpoint ausführen (nur Lambda) SnapStart
Die `Init`-Phase endet, wenn die Laufzeit und alle Erweiterungen signalisieren, dass sie bereit sind, indem sie eine `Next`-API-Anforderung senden. Die `Init`-Phase ist auf 10 Sekunden begrenzt. Wenn alle drei Aufgaben nicht innerhalb von 10 Sekunden abgeschlossen werden, versucht Lambda die `Init`-Phase zum Zeitpunkt des ersten Funktionsaufrufs mit dem konfigurierten Funktionstimeout erneut.
Wenn [Lambda SnapStart](snapstart.md) aktiviert ist, findet die `Init`-Phase statt, wenn Sie eine Funktionsversion veröffentlichen. Lambda speichert einen Snapshot des Arbeitsspeichers und des Festplattenzustands der initialisierten Ausführungsumgebung, speichert den verschlüsselten Snapshot und speichert ihn im Cache für den Zugriff mit geringer Latenz. Wenn Sie einen [Laufzeit-Hook](snapstart-runtime-hooks.md) vor dem Prüfpunkt haben, wird der Code am Ende der `Init`-Phase ausgeführt.
**Anmerkung**
Das 10-Sekunden-Timeout gilt nicht für Funktionen, die bereitgestellte Parallelität oder Lambda Managed SnapStart Instances verwenden. Für die Funktionen Provisioned Concurrency und Managed Instances kann Ihr Initialisierungscode bis zu 15 Minuten lang ausgeführt werden. SnapStart Das Zeitlimit beträgt 130 Sekunden oder das konfigurierte Funktions-Timeout (maximal 900 Sekunden), je nachdem, welcher Wert höher ist.
Wenn Sie die [bereitgestellte Gleichzeitigkeit](https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html) verwenden, initialisiert Lambda die Ausführungsumgebung, wenn Sie die PC-Einstellungen für eine Funktion konfigurieren. Lambda stellt außerdem sicher, dass initialisierte Ausführungsumgebungen vor Aufrufen immer verfügbar sind. Möglicherweise treten Lücken zwischen den Aufruf- und Initialisierungsphasen Ihrer Funktion auf. Abhängig von der Laufzeit- und Speicherkonfiguration Ihrer Funktion können beim ersten Aufruf in einer initialisierten Ausführungsumgebung auch variable Latenzzeiten auftreten.
Bei Funktionen, die On-Demand-Gleichzeitigkeit nutzen, initialisiert Lambda gelegentlich Ausführungsumgebungen vor Aufrufanfragen. In diesem Fall stellen Sie möglicherweise auch eine Zeitlücke zwischen der Initialisierungs- und der Aufrufphase Ihrer Funktion fest. Wir empfehlen Ihnen, sich nicht von diesem Verhalten abhängig zu machen.
### Fehler in der Initialisierungsphase
Wenn eine Funktion in der `Init`-Phase abstürzt oder ein Timeout auftritt, gibt Lambda Fehlerinformationen im `INIT_REPORT`-Protokoll aus.
**Example – INIT\$1REPORT-Protokoll für Timeout**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: timeout
```
**Example – INIT\$1REPORT-Protokoll für den Erweiterungsfehler**
```
INIT_REPORT Init Duration: 1236.04 ms Phase: init Status: error Error Type: Extension.Crash
```
Wenn die `Init` Phase erfolgreich ist, gibt Lambda das `INIT_REPORT` Protokoll nicht aus, es sei denn [SnapStart](snapstart.md), die [bereitgestellte Parallelität](provisioned-concurrency.md) ist aktiviert. SnapStart und bereitgestellte Parallelitätsfunktionen werden immer ausgegeben. `INIT_REPORT` Weitere Informationen finden Sie unter [Überwachung für Lambda SnapStart](snapstart-monitoring.md).
### Wiederherstellungsphase ( SnapStart nur Lambda)
Wenn Sie eine [SnapStart](snapstart.md)Funktion zum ersten Mal aufrufen und die Funktion skaliert wird, nimmt Lambda neue Ausführungsumgebungen aus dem persistenten Snapshot wieder auf, anstatt die Funktion von Grund auf neu zu initialisieren. Wenn Sie über einen [Laufzeit-Hook](snapstart-runtime-hooks.md) nach der Wiederherstellung verfügen, wird der Code am Ende der `Restore`-Phase ausgeführt. Die Dauer von Laufzeit-Hooks nach der Wiederherstellung wird Ihnen in Rechnung gestellt. Die Laufzeit muss geladen werden und Laufzeit-Hooks nach der Wiederherstellung müssen innerhalb des Timeout-Limits (10 Sekunden) abgeschlossen werden. Andernfalls erhalten Sie eine. SnapStartTimeoutException Wenn die `Restore`-Phase abgeschlossen ist, ruft Lambda den Funktionshandler ([Invoke-Phase](#runtimes-lifecycle-invoke)) auf.
#### Fehler in der Wiederherstellphase
Wenn die `Restore`-Phase fehlschlägt, gibt Lambda Fehlerinformationen im `RESTORE_REPORT`-Protokoll aus.
**Example – RESTORE\$1REPORT-Protokoll für Timeout**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: timeout
```
**Example – RESTORE\$1REPORT-Protokoll für einen Laufzeit-Hook-Fehler**
```
RESTORE_REPORT Restore Duration: 1236.04 ms Status: error Error Type: Runtime.ExitError
```
Weitere Informationen zum `RESTORE_REPORT`-Protokoll finden Sie unter [Überwachung für Lambda SnapStart](snapstart-monitoring.md).
### Invoke-Phase
Wenn eine Lambda-Funktion als Antwort auf eine `Next`-API-Anforderung aufgerufen wird, sendet Lambda ein `Invoke`-Ereignis an die Laufzeit und an jede Erweiterung.
Die Timeout-Einstellung der Funktion begrenzt die Dauer der gesamten `Invoke`-Phase. Wenn Sie beispielsweise die Zeitüberschreitung für die Funktion auf 360 Sekunden festlegen, müssen die Funktion und alle Erweiterungen innerhalb von 360 Sekunden abgeschlossen werden. Beachten Sie, dass es keine unabhängige Post-Invoke-Phase gibt. Die Dauer ist die Summe der gesamten Aufrufzeit (Laufzeit \$1 Erweiterungen) und wird erst berechnet, wenn die Funktion und alle Erweiterungen vollständig ausgeführt wurden.
Die Invoke-Phase endet nach der Laufzeit und alle Erweiterungen signalisieren durch Senden einer `Next`-API-Anforderung dass sie abgeschlossen sind.
### Fehler während der Aufrufphase
Wenn die Lambda-Funktion während der `Invoke`-Phase abstürzt oder das Zeitlimit überschreitet, setzt Lambda die Ausführungsumgebung zurück. Das folgende Diagramm veranschaulicht das Verhalten der Lambda-Ausführungsumgebung bei einem Aufruffehler:
![\[Beispiel für eine Ausführungsumgebung: Init, Invoke, Invoke with Error, Invoke, Shutdown\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/Overview-Invoke-with-Error.png)
In folgendem Diagramm:
+ Ist die erste Phase die **INIT**-Phase, die ohne Fehler läuft.
+ Ist die zweite Phase die **INVOKE**-Phase, die ohne Fehler läuft.
+ Angenommen, Ihre Funktion stößt irgendwann auf einen Aufruffehler (häufige Ursachen sind Funktions-Timeouts, Laufzeitfehler, Speichererschöpfung, VPC-Konnektivitätsprobleme, Berechtigungsfehler, Parallelitätsbeschränkungen und verschiedene Konfigurationsprobleme). Eine vollständige Liste möglicher Aufruffehler finden Sie unter [Beheben von Aufruf-Problemen in Lambda](troubleshooting-invocation.md). Die dritte Phase mit der Bezeichnung **INVOKE MIT FEHLER** veranschaulicht dieses Szenario. Wenn dies geschieht, führt der Lambda-Service einen Neustart durch. Der Reset verhält sich wie ein `Shutdown`-Ereignis. Zuerst beendet Lambda die Laufzeit und sendet dann ein `Shutdown`-Ereignis an jede registrierte externe Erweiterung. Das Ereignis enthält den Grund für das Abschalten. Wenn diese Umgebung für einen neuen Aufruf verwendet wird, initialisiert Lambda die Erweiterung und die Laufzeit als Teil des nächsten Aufrufers erneut.
Beachten Sie, dass der Lambda-Reset den Inhalt des `/tmp`-Verzeichnisses vor der nächsten Init-Phase nicht löscht. Dieses Verhalten stimmt mit der regulären Shutdown-Phase überein.
**Anmerkung**
AWS implementiert derzeit Änderungen am Lambda-Service. Aufgrund dieser Änderungen können geringfügige Unterschiede in Struktur und Inhalt der Systemprotokollmeldungen und Trace-Segmente auftreten, die von verschiedenen Lambda-Funktionen in Ihrem AWS-Konto.
Wenn die Systemprotokollkonfiguration Ihrer Funktion auf Klartext eingestellt ist, wirkt sich diese Änderung auf die Protokollnachrichten aus, die in CloudWatch Logs erfasst werden, wenn bei Ihrer Funktion ein Aufruffehler auftritt. Die folgenden Beispiele zeigen Protokollausgaben sowohl in alten als auch in neuen Formaten.
Diese Änderungen werden in den kommenden Wochen umgesetzt, und alle Funktionen AWS-Regionen außer China und den GovCloud Regionen werden auf die Verwendung der Protokollnachrichten und Trace-Segmente im neuen Format umgestellt.
**Example CloudWatch Protokolliert die Protokollausgabe (Laufzeit- oder Erweiterungsabsturz) — alter Stil**
```
START RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Version: $LATEST
RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Error: Runtime exited without providing a reason
Runtime.ExitError
END RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1
REPORT RequestId: c3252230-c73d-49f6-8844-968c01d1e2e1 Duration: 933.59 ms Billed Duration: 934 ms Memory Size: 128 MB Max Memory Used: 9 MB
```
**Example CloudWatch Protokolliert die Protokollausgabe (Funktions-Timeout) im alten Stil**
```
START RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Version: $LATEST
2024-03-04T17:22:38.033Z b70435cc-261c-4438-b9b6-efe4c8f04b21 Task timed out after 3.00 seconds
END RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21
REPORT RequestId: b70435cc-261c-4438-b9b6-efe4c8f04b21 Duration: 3004.92 ms Billed Duration: 3117 ms Memory Size: 128 MB Max Memory Used: 33 MB Init Duration: 111.23 ms
```
Das neue Format für CloudWatch Protokolle enthält ein zusätzliches `status` Feld in der `REPORT` Zeile. Im Falle eines Laufzeit- oder Erweiterungsabsturzes enthält die `REPORT`-Zeile auch ein Feld `ErrorType`.
**Example CloudWatch Protokolliert die Protokollausgabe (Laufzeit- oder Erweiterungsabsturz) — neuer Stil**
```
START RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Version: $LATEST
END RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd
REPORT RequestId: 5b866fb1-7154-4af6-8078-6ef6ca4c2ddd Duration: 133.61 ms Billed Duration: 214 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 80.00 ms Status: error Error Type: Runtime.ExitError
```
**Example CloudWatch Protokolliert die Protokollausgabe (Funktions-Timeout) — neuer Stil**
```
START RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Version: $LATEST
END RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda
REPORT RequestId: 527cb862-4f5e-49a9-9ae4-a7edc90f0fda Duration: 3016.78 ms Billed Duration: 3101 ms Memory Size: 128 MB Max Memory Used: 31 MB Init Duration: 84.00 ms Status: timeout
```
+ Die vierte Phase stellt die **INVOKE**-Phase unmittelbar nach einem Aufruffehler dar. Hier initialisiert Lambda die Umgebung erneut, indem es die **INIT**-Phase erneut ausführt. Dies wird als *unterdrückte Initialisierung* bezeichnet. Wenn unterdrückte Inits auftreten, meldet Lambda nicht explizit eine zusätzliche **INIT-Phase** in Logs. CloudWatch Stattdessen stellen Sie möglicherweise fest, dass die Dauer in der REPORT-Zeile eine zusätzliche **INIT**-Dauer plus die **INVOKE**-Dauer enthält. Nehmen wir zum Beispiel an, Sie sehen die folgenden Logs in: CloudWatch
```
2022-12-20T01:00:00.000-08:00 START RequestId: XXX Version: $LATEST
2022-12-20T01:00:02.500-08:00 END RequestId: XXX
2022-12-20T01:00:02.500-08:00 REPORT RequestId: XXX Duration: 3022.91 ms
Billed Duration: 3000 ms Memory Size: 512 MB Max Memory Used: 157 MB
```
In diesem Beispiel beträgt der Unterschied zwischen den Zeitstempeln BERICHT und START 2,5 Sekunden. Dies entspricht nicht der angegebenen Dauer von 3 022,91 Millsekunden, da es die zusätzliche **INIT** (unterdrückte Initialisierung), die Lambda ausgeführt hat, nicht berücksichtigt. In diesem Beispiel können Sie ableiten, dass die tatsächliche **INVOKE**-Phase 2,5 Sekunden gedauert hat.
Für mehr Einblick in dieses Verhalten können Sie die [Zugriff auf Echtzeit-Telemetriedaten für Erweiterungen über die Telemetrie-API](telemetry-api.md) verwenden. Die Telemetrie-API gibt `INIT_START`, `INIT_RUNTIME_DONE` und `INIT_REPORT`-Ereignisse mit `phase=invoke` immer dann aus, wenn unterdrückte Initialisierungen zwischen den Aufrufphasen auftreten.
+ Die fünfte Phase stellt die **SHUTDOWN**-Phase dar, die fehlerfrei abläuft.
### Shutdown-Phase
Wenn Lambda dabei ist, die Laufzeit herunterzufahren, sendet es ein `Shutdown`-Ereignis an jede registrierte externe Erweiterung. Erweiterungen können diese Zeit für abschließende Bereinigungsaufgaben verwenden. Das `Shutdown`-Ereignis ist eine Antwort auf eine `Next`-API-Anforderung.
**Duration Limit (Begrenzung der Dauer)**: Die maximale Dauer der `Shutdown`-Phase hängt von der Konfiguration der registrierten Erweiterungen ab:
+ 0 ms – Eine Funktion ohne registrierte Erweiterungen
+ 500 ms – Eine Funktion mit einer registrierten internen Erweiterung
+ 2.000 ms – Eine Funktion mit einer oder mehreren registrierten externen Erweiterungen
Wenn die Laufzeit oder eine Erweiterung nicht innerhalb des Limits auf das `Shutdown`-Ereignis reagiert, beendet Lambda den Prozess mit einem `SIGKILL`-Signal.
Nachdem die Funktion und alle Erweiterungen abgeschlossen sind, behält Lambda die Ausführungsumgebung für einige Zeit im Vorgriff auf einen anderen Funktionsaufruf bei. Lambda beendet jedoch alle paar Stunden die Ausführungsumgebungen, um Laufzeitaktualisierungen und -wartungen zu ermöglichen – selbst bei Funktionen, die kontinuierlich aufgerufen werden. Sie sollten nicht davon ausgehen, dass die Ausführungsumgebung auf unbestimmte Zeit bestehen bleibt. Weitere Informationen finden Sie unter [Implementieren der Zustandslosigkeit in Funktionen](concepts-application-design.md#statelessness-functions).
Wenn die Funktion erneut aufgerufen wird, taut Lambda die Umgebung zur Wiederverwendung auf. Die Wiederverwendung der Ausführungsumgebung hat folgende Auswirkungen:
+ Objekte, die außerhalb der Handler-Methode der Funktion deklariert sind, bleiben initialisiert und bieten eine zusätzliche Optimierung, wenn die Funktion erneut aufgerufen wird. Beispiel: Falls Ihre Lambda-Funktion eine Datenbankverbindung herstellt, statt die Verbindung neu herzustellen, wird die ursprüngliche Verbindung bei nachfolgenden Aufrufen verwendet. Wir empfehlen, dass Sie Ihrem Code eine Logik hinzufügen, um zu prüfen, ob eine Verbindung besteht, bevor Sie eine neue erstellen.
+ Jede Ausführungsumgebung stellt Speicherplatz von 512 MB bis 10 240 MB, in 1-MB-Schritten, im Verzeichnis `/tmp` zur Verfügung. Der Inhalt des Verzeichnisses bleibt bestehen, wenn die Ausführungsumgebung eingefroren ist, und bietet einen temporären Zwischenspeicher, der für mehrere Aufrufe verwendet werden kann. Sie können zusätzlichen Code hinzufügen, um zu prüfen, ob der Cache die gespeicherten Daten enthält. Weitere Informationen zu Beschränkungen der Bereitstellungsgröße finden Sie unter [Lambda-KontingenteLambda-Kontingente](gettingstarted-limits.md).
+ Hintergrundprozesse oder Callbacks, die von Ihrer Lambda-Funktion initiiert wurden und nicht abgeschlossen wurden, wenn die Funktion beendet wurde, werden wieder aufgenommen, wenn Lambda die Ausführungsumgebung wiederverwendet. Sie sollten sicherstellen, dass alle Hintergrundprozesse oder Callbacks in Ihrem Code abgeschlossen sind, bevor der Code beendet wird.
## Kaltstarts und Latenzzeiten
Wenn Lambda eine Anfrage zur Ausführung einer Funktion über die Lambda-API erhält, bereitet der Dienst zunächst eine Ausführungsumgebung vor. Während dieser Initialisierungsphase lädt der Dienst Ihren Code herunter, startet die Umgebung und führt jeglichen Initialisierungscode außerhalb des Haupt-Handlers aus. Schließlich führt Lambda den Handler-Code aus.
![\[Perf Optimize Abbildung 1\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/perf-optimize-figure-1.png)
In diesem Diagramm werden die ersten beiden Schritte, das Herunterladen des Codes und das Einrichten der Umgebung, häufig als „Kaltstart“ bezeichnet. [Diese Zeit wird Ihnen in Rechnung gestellt](https://aws.amazon.com/blogs/compute/aws-lambda-standardizes-billing-for-init-phase/) und verlängert die Gesamtdauer Ihres Aufrufs.
Nachdem der Aufruf abgeschlossen ist, wird die Ausführungsumgebung eingefroren. Um die Ressourcenverwaltung und die Leistung zu verbessern, behält Lambda die Ausführungsumgebung für einen bestimmten Zeitraum bei. Wenn während dieser Zeit eine andere Anfrage für dieselbe Funktion eingeht, kann Lambda die Umgebung wiederverwenden. Diese zweite Anfrage wird in der Regel schneller abgeschlossen, da die Ausführungsumgebung bereits vollständig eingerichtet ist. Dies wird als „Warmstart“ bezeichnet.
Kaltstarts treten in der Regel bei weniger als 1 % der Aufrufe auf. Die Dauer eines Kaltstarts variiert zwischen unter 100 ms und über 1 Sekunde. Im Allgemeinen kommen Kaltstarts in Entwicklungs- und Testfunktionen häufiger vor als in Produktions-Workloads. Das liegt daran, dass Entwicklungs- und Testfunktionen in der Regel seltener aufgerufen werden.
## Reduzierung von Kaltstarts mit bereitgestellter Parallelität
Wenn Sie vorhersehbare Startzeiten von Funktionen für Ihren Workload benötigen, ist [bereitgestellte Parallelität](provisioned-concurrency.md) die empfohlene Lösung, um eine möglichst geringe Latenz sicherzustellen. Mit diesem Feature werden Ausführungsumgebungen vorinitialisiert, was die Anzahl der Kaltstarts reduziert.
Für eine Funktion mit einer bereitgestellten Parallelität von 6 werden beispielsweise 6 Ausführungsumgebungen vorbereitet.
![\[Perf Optimize Abbildung 4\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/perf-optimize-figure-4.png)
## Optimierung der statischen Initialisierung
Die statische Initialisierung erfolgt, bevor der Handlercode in einer Funktion ausgeführt wird. Dies ist der von Ihnen bereitgestellte Initialisierungscode, der sich außerhalb des Haupt-Handlers befindet. Dieser Code wird häufig verwendet, um Bibliotheken und Abhängigkeiten zu importieren, Konfigurationen einzurichten und Verbindungen zu anderen Diensten zu initialisieren.
Das folgende Python-Beispiel zeigt den Import und die Konfiguration von Modulen sowie die Erstellung des Amazon-S3-Clients während der Initialisierungsphase, bevor die `lambda_handler`-Funktion während des Aufrufs ausgeführt wird.
```
import os
import json
import cv2
import logging
import boto3
s3 = boto3.client('s3')
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def lambda_handler(event, context):
# Handler logic...
```
Der größte Faktor für die Latenz vor der Funktionsausführung ist der Initialisierungscode. Dieser Code wird ausgeführt, wenn eine neue Ausführungsumgebung zum ersten Mal erstellt wird. Der Initialisierungscode wird nicht erneut ausgeführt, wenn ein Aufruf eine warme Ausführungsumgebung verwendet. Faktoren, die die Latenz des Initialisierungscodes beeinflussen, sind unter anderem:
+ Die Größe des Funktionspakets in Bezug auf importierte Bibliotheken und Abhängigkeiten sowie Lambda-Schichten.
+ Die Menge an Code und die Initialisierungsarbeit.
+ Die Leistung von Bibliotheken und anderen Diensten beim Aufbau von Verbindungen und anderen Ressourcen.
Es gibt eine Reihe von Maßnahmen, mit denen Entwickler die Latenzzeit bei der statischen Initialisierung optimieren können. Wenn eine Funktion viele Objekte und Verbindungen hat, können Sie eine einzelne Funktion möglicherweise in mehrere spezialisierte Funktionen umstrukturieren. Diese sind einzeln kleiner und haben jeweils weniger Initialisierungscode.
Es ist wichtig, dass Funktionen nur die Bibliotheken und Abhängigkeiten importieren, die sie benötigen. Wenn Sie beispielsweise nur Amazon DynamoDB im AWS SDK verwenden, können Sie anstelle des gesamten SDK einen einzelnen Service verlangen. Vergleichen Sie die folgenden drei Beispiele:
```
// Instead of const AWS = require('aws-sdk'), use:
const DynamoDB = require('aws-sdk/clients/dynamodb')
// Instead of const AWSXRay = require('aws-xray-sdk'), use:
const AWSXRay = require('aws-xray-sdk-core')
// Instead of const AWS = AWSXRay.captureAWS(require('aws-sdk')), use:
const dynamodb = new DynamoDB.DocumentClient()
AWSXRay.captureAWSClient(dynamodb.service)
```
Die statische Initialisierung ist auch oft der beste Ort, um Datenbankverbindungen zu öffnen, damit eine Funktion Verbindungen über mehrere Aufrufe derselben Ausführungsumgebung wiederverwenden kann. Möglicherweise verfügen Sie jedoch über eine große Anzahl von Objekten, die nur in bestimmten Ausführungspfaden in Ihrer Funktion verwendet werden. In diesem Fall können Sie Variablen im globalen Bereich langsam laden, um die Dauer der statischen Initialisierung zu reduzieren.
Vermeiden Sie globale Variablen für kontextspezifische Informationen. Wenn Ihre Funktion über eine globale Variable verfügt, die nur für die Lebensdauer eines einzelnen Aufrufs verwendet und für den nächsten Aufruf zurückgesetzt wird, verwenden Sie einen Variablenbereich, der für den Handler lokal ist. Dadurch wird nicht nur verhindert, dass globale Variablen bei Aufrufen verloren gehen, sondern verbessert auch die Leistung der statischen Initialisierung.
# Erstellen ereignisgesteuerter Architekturen mit Lambda
Ein Ereignis ist alles, was das Ausführen einer Lambda-Funktion auslöst. Ereignisse können eine Lambda-Funktion auf zwei Arten auslösen: durch direkten Aufruf (Push) und durch Zuordnungen von Ereignisquellen (Pull).
Viele AWS Dienste können Ihre Lambda-Funktionen direkt aufrufen. Diese Services leiten *Ereignisse* an Ihre Lambda-Funktion weiter. Ereignisse, die Funktionen auslösen, können fast alles sein, von einer HTTP-Anfrage über API Gateway, einem durch eine EventBridge Regel verwalteten Zeitplan, einem AWS IoT Ereignis oder einem Amazon S3 S3-Ereignis. Bei der Zuordnung von Ereignisquellen ruft Lambda aktiv Ereignisse aus einer Warteschlange oder einem Stream ab (*Pull*). Sie konfigurieren Lambda so, dass Lambda nach Ereignissen von einem unterstützten Service sucht, und Lambda kümmert sich um die Abfrage und den Aufruf Ihrer Funktion.
Wenn Ereignisse an Ihre Funktion übergeben werden, sind sie im JSON-Format strukturiert. Die JSON-Struktur variiert je nach Service, von dem sie generiert wird, und dem Ereignistyp. Während Standardaufrufe von Lambda-Funktionen bis zu 15 Minuten (oder bis zu einem Jahr bei [dauerhaften Funktionen](durable-functions.md)) dauern können, eignet sich Lambda am besten für kurze Aufrufe, die eine Sekunde oder weniger dauern. Dies gilt insbesondere für ereignisgesteuerte Architekturen, bei denen jede Lambda-Funktion als Mikroservice behandelt wird, der für die Ausführung eines engen Satzes spezifischer Befehle verantwortlich ist.
**Anmerkung**
Ereignisgesteuerte Architekturen kommunizieren systemübergreifend mithilfe von Netzwerken, was zu variabler Latenz führt. Für Workloads, die eine sehr geringe Latenz erfordern, wie z. B. Handelssysteme in Echtzeit, ist dieses Design möglicherweise nicht die beste Wahl. Für hoch skalierbare und verfügbare Workloads oder solche mit unvorhersehbaren Datenverkehrsmustern können ereignisgesteuerte Architekturen jedoch eine effektive Möglichkeit bieten, diese Anforderungen zu erfüllen.
**Topics**
+ [
## Vorteile einer ereignisgesteuerten Architektur
](#event-driven-benefits)
+ [
## Kompromisse ereignisgesteuerter Architekturen
](#event-driven-tradeoffs)
+ [
## Anti-Pattern in Lambda-basierten ereignisgesteuerten Anwendungen
](#event-driven-anti-patterns)
## Vorteile einer ereignisgesteuerten Architektur
Lambda unterstützt zwei Aufrufmethoden in ereignisgesteuerten Architekturen:
1. Direkter Aufruf (Push-Methode): AWS Dienste lösen Lambda-Funktionen direkt aus. Beispiel:
+ Amazon S3 löst eine Funktion aus, wenn eine Datei hochgeladen wird.
+ API Gateway löst eine Funktion aus, wenn es eine HTTP-Anfrage empfängt.
1. Zuordnung von Ereignisquellen (Pull-Methode): Lambda ruft Ereignisse ab und ruft Funktionen auf. Beispiel:
+ Lambda ruft Nachrichten aus einer Amazon-SQS-Warteschlange ab und ruft eine Funktion auf.
+ Lambda liest Datensätze aus einem DynamoDB-Stream und ruft eine Funktion auf.
Beide Methoden tragen zu den Vorteilen von ereignisgesteuerten Architekturen bei, wie unten beschrieben.
### Polling und Webhooks durch Ereignisse ersetzen
Viele traditionelle Architekturen verwenden Polling- und Webhook-Mechanismen, um den Status zwischen verschiedenen Komponenten zu kommunizieren. Das Abrufen von Aktualisierungen kann sehr ineffizient sein, da es eine Verzögerung zwischen der Verfügbarkeit neuer Daten und der Synchronisierung mit nachgelagerten Diensten gibt. Webhooks werden nicht immer von anderen Microservices unterstützt, in die Sie sich integrieren möchten. Sie erfordern möglicherweise auch benutzerdefinierte Autorisierungs- und Authentifizierungskonfigurationen. In beiden Fällen ist es schwierig, diese Integrationsmethoden ohne zusätzliche Arbeit der Entwicklungsteams bedarfsgerecht zu skalieren.
![\[Ereignisgesteuerte Architekturen Abbildung 7\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-7.png)
Diese beiden Mechanismen können durch Ereignisse ersetzt werden, die gefiltert, weitergeleitet und an nachgelagerte Microservices weitergeleitet werden können. Dieser Ansatz kann zu einem geringeren Bandbreitenverbrauch, einer geringeren CPU-Auslastung und potenziell niedrigeren Kosten führen. Diese Architekturen können auch die Komplexität verringern, da jede Funktionseinheit kleiner ist und oft weniger Code enthalten ist.
![\[Ereignisgesteuerte Architekturen Abbildung 8\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-8.png)
Ereignisgesteuerte Architekturen können auch das Entwerfen von near-real-time Systemen erleichtern und Unternehmen dabei helfen, sich von der stapelbasierten Verarbeitung abzuwenden. Ereignisse werden zu dem Zeitpunkt erzeugt, an dem sich der Zustand der Anwendung ändert. Der benutzerdefinierte Code eines Microservices sollte daher so konzipiert sein, dass er die Verarbeitung eines einzelnen Ereignisses verarbeiten kann. Da die Skalierung durch den Lambda-Dienst erfolgt, kann diese Architektur einen erheblichen Anstieg des Datenverkehrs ohne Änderung des benutzerdefinierten Codes bewältigen. Mit der Zunahme von Ereignissen wächst auch die Datenverarbeitungsschicht, die die Ereignisse verarbeitet.
### Reduzierung der Komplexität
Microservices ermöglichen es Entwicklern und Architekten, komplexe Workflows zu vereinfachen. Ein E-Commerce-Monolith kann beispielsweise in Auftragsannahme- und Zahlungsprozesse mit separaten Inventar-, Fulfillment- und Buchhaltungsdienstleistungen unterteilt werden. Was in einem Monolith komplex zu verwalten und zu orchestrieren sein könnte, wird zu einer Reihe von entkoppelten Diensten, die asynchron mit Ereignissen kommunizieren.
![\[Ereignisgesteuerte Architekturen Abbildung 9\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-9.png)
Dieser Ansatz ermöglicht auch die Zusammenstellung von Diensten, die Daten mit unterschiedlichen Geschwindigkeiten verarbeiten. In diesem Fall kann ein Microservice für die Auftragsannahme große Mengen eingehender Bestellungen speichern, indem er die Nachrichten in einer Amazon SQS SQS-Warteschlange zwischenspeichert.
Ein Zahlungsabwicklungsservice, der aufgrund der Komplexität der Zahlungsabwicklung in der Regel langsamer ist, kann einen stetigen Strom von Nachrichten aus der Amazon SQS-Warteschlange entgegennehmen. Er kann komplexe Wiederholungsversuche und Fehlerbehandlungslogik mithilfe von AWS Step Functions aktiven Zahlungsabläufen für Hunderttausende von Bestellungen orchestrieren und diese koordinieren.
**Alternativer Ansatz:** Für die Orchestrierung mit Standard-Programmiersprachen können Sie [langlebige Lambda-Funktionen](durable-functions.md) verwenden. Mit dauerhaften Funktionen können Sie die Auftragsannahme, die Zahlungsabwicklung und die Benachrichtigungslogik mit automatischem Checkpoint und automatischem Wiederholungsversuch in Code schreiben. Dieser Ansatz funktioniert gut, wenn der Workflow hauptsächlich Lambda-Funktionen umfasst und Sie es vorziehen, die Orchestrierungslogik im Code beizubehalten.
### Verbesserung der Skalierbarkeit und Erweiterbarkeit
Microservices generieren Ereignisse, die in der Regel in Messaging-Diensten wie Amazon SNS und Amazon SQS veröffentlicht werden. Diese verhalten sich wie ein elastischer Puffer zwischen Microservices und helfen bei der Skalierung, wenn der Datenverkehr zunimmt. Dienste wie Amazon EventBridge können dann Nachrichten je nach Inhalt des Ereignisses filtern und weiterleiten, wie in den Regeln definiert. Infolgedessen sind ereignisbasierte Anwendungen skalierbarer und bieten eine größere Redundanz als monolithische Anwendungen.
Dieses System ist außerdem in hohem Maße erweiterbar, so dass andere Teams die Features erweitern und neue Features hinzufügen können, ohne dass dies Auswirkungen auf die Microservices für die Auftrags- und Zahlungsabwicklung hat. Durch die Veröffentlichung von Ereignissen mithilfe EventBridge dieser Anwendung lässt sie sich in bestehende Systeme wie den Inventar-Microservice integrieren, ermöglicht aber auch die Integration jeder future Anwendung als Event-Consumer. Die Produzenten von Ereignissen haben keine Kenntnis über die Konsumenten von Ereignissen, was zur Vereinfachung der Logik des Mikrodienstes beitragen kann.
## Kompromisse ereignisgesteuerter Architekturen
### Variable Latenzzeit
Im Gegensatz zu monolithischen Anwendungen, die möglicherweise alles verarbeiten, was sich im selben Speicherbereich auf einem einzigen Gerät befindet, kommunizieren ereignisgesteuerte Anwendungen netzwerkübergreifend. Dieses Design führt zu einer variablen Latenzzeit. Es ist zwar möglich, Anwendungen so zu entwickeln, dass die Latenzzeit minimiert wird, aber monolithische Anwendungen können fast immer auf Kosten der Skalierbarkeit und Verfügbarkeit für eine geringere Latenzzeit optimiert werden.
Workloads, die eine konsistente Leistung mit geringer Latenz erfordern, wie z. B. Hochfrequenz-Handelsanwendungen in Banken oder die Submillisekunden-Automatisierung von Robotern in Lagerhäusern, sind keine guten Kandidaten für eine ereignisgesteuerte Architektur.
### Letztendliche Datenkonsistenz
Ein Ereignis stellt eine Zustandsänderung dar und da zu einem bestimmten Zeitpunkt viele Ereignisse durch verschiedene Dienste in einer Architektur fließen, sind solche Workloads oft [irgendwann konsistent](https://en.wikipedia.org/wiki/Eventual_consistency). Dies erschwert die Verarbeitung von Transaktionen, den Umgang mit Duplikaten oder die Ermittlung des genauen Gesamtzustands eines Systems.
Einige Workloads enthalten eine Kombination von Anforderungen, die eventuell konsistent (z. B. Gesamtaufträge in der aktuellen Stunde) oder stark konsistent (z. B. aktueller Bestand) sind. Für Workloads, die eine hohe Datenkonsistenz erfordern, gibt es Architekturmuster, die dies unterstützen. Beispiel:
+ DynamoDB kann [strikt konsistente Lesevorgänge](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html) bereitstellen, manchmal mit einer höheren Latenz, wodurch ein höherer Durchsatz als im Standardmodus verbraucht wird. DynamoDB kann auch [Transaktionen unterstützen](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/transactions.html), um die Datenkonsistenz aufrechtzuerhalten.
+ Sie können Amazon RDS für Features verwenden, die [ACID-Eigenschaften](https://en.wikipedia.org/wiki/ACID) benötigen, obwohl relationale Datenbanken weniger skalierbar sind als ein NoSQL-Datenbanken wie DynamoDB. [Amazon-RDS-Proxy](https://aws.amazon.com/rds/proxy/) kann dabei helfen, das Verbindungspooling und die Skalierung von kurzlebigen Verbrauchern wie Lambda-Funktionen zu verwalten.
Ereignisbasierte Architekturen sind in der Regel auf einzelne Ereignisse und nicht auf große Datenmengen ausgelegt. Im Allgemeinen sind Workflows so konzipiert, dass sie die Schritte eines einzelnen Ereignisses oder Ausführungsablaufs verwalten, anstatt mehrere Ereignisse gleichzeitig zu bearbeiten. In Serverless-Systemen wird die Echtzeit-Ereignisverarbeitung der Batch-Verarbeitung vorgezogen: Batches sollten durch viele kleinere inkrementelle Aktualisierungen ersetzt werden. Dies kann zwar die Verfügbarkeit und Skalierbarkeit von Workloads verbessern, macht es aber auch schwieriger für Ereignisse, andere Ereignisse zu erkennen.
### Rückgabe von Werten an Anrufer
In vielen Fällen sind ereignisbasierte Anwendungen asynchron. Das bedeutet, dass Anruferdienste nicht auf Anfragen von anderen Diensten warten, bevor sie mit anderen Aufgaben fortfahren. Dies ist eine grundlegende Eigenschaft ereignisgesteuerter Architekturen, die Skalierbarkeit und Flexibilität ermöglicht. Dies bedeutet, dass die Übergabe von Rückgabewerten oder des Ergebnisses eines Workflows komplexer ist als bei synchronen Ausführungsabläufen.
Die meisten Lambda-Aufrufe in Produktionssystemen sind [asynchron](invocation-async.md) und reagieren auf Ereignisse von Diensten wie Amazon S3 oder Amazon SQS. In diesen Fällen ist der Erfolg oder Misserfolg der Verarbeitung eines Ereignisses oft wichtiger als die Rückgabe eines Wertes. Funktionen wie [Warteschlangen](https://docs.aws.amazon.com/lambda/latest/dg/invocation-async.html) (DLQs) in Lambda sorgen dafür, dass Sie fehlgeschlagene Ereignisse identifizieren und erneut versuchen können, ohne den Anrufer benachrichtigen zu müssen.
### Dienst- und funktionsübergreifendes Debugging
Die Fehlersuche in ereignisgesteuerten Systemen unterscheidet sich ebenfalls von einer monolithischen Anwendung. Da verschiedene Systeme und Services Ereignisse weitergeben, ist es nicht möglich, den genauen Zustand mehrerer Services beim Auftreten von Fehlern zu erfassen und zu reproduzieren. Da jeder Dienst- und Funktionsaufruf über separate Protokolldateien verfügt, kann es komplizierter sein, festzustellen, was mit einem bestimmten Ereignis passiert ist, das einen Fehler verursacht hat.
Es gibt drei wichtige Voraussetzungen für den Aufbau eines erfolgreichen Debugging-Ansatzes in ereignisgesteuerten Systemen. Erstens ist ein robustes Protokollierungssystem von entscheidender Bedeutung. Dieses wird AWS dienstübergreifend bereitgestellt und von Amazon CloudWatch in Lambda-Funktionen eingebettet. Zweitens muss in diesen Systemen sichergestellt werden, dass jedes Ereignis eine Transaktionskennung hat, die bei jedem Schritt während einer Transaktion protokolliert wird, um die Suche nach Protokollen zu erleichtern.
Schließlich ist es sehr empfehlenswert, das Parsing und die Analyse von Protokollen mit Hilfe eines Debugging- und Überwachungsdienstes wie AWS X-Ray zu automatisieren. Dies kann Protokolle über mehrere Lambda-Aufrufe und -Dienste hinweg verbrauchen, wodurch es viel einfacher wird, die Ursache von Problemen zu ermitteln. Eine ausführliche Beschreibung der Verwendung von X-Ray zur Fehlerbehebung finden Sie unter [Fehlerbehebungs-Walkthrough](lambda-troubleshooting.md).
## Anti-Pattern in Lambda-basierten ereignisgesteuerten Anwendungen
Vermeiden Sie beim Aufbau ereignisgesteuerter Architekturen mit Lambda die folgenden gängigen Anti-Patterns. Diese Muster funktionieren, können aber die Kosten und die Komplexität erhöhen.
### Der Lambda-Monolith
Bei vielen Anwendungen, die von herkömmlichen Servern, wie Amazon-EC2-Instanzen oder Elastic-Beanstalk-Anwendungen migriert werden, führen Entwickler ein „Lift and Shift“ von bestehendem Code aus. Dies führt häufig zu einer einzigen Lambda-Funktion, die die gesamte Anwendungslogik enthält, die für alle Ereignisse ausgelöst wird. Bei einer einfachen Webanwendung würde eine monolithische Lambda-Funktion alle API-Gateway-Routen verwalten und mit allen erforderlichen nachgelagerten Ressourcen integrieren.
![\[Ereignisgesteuerte Architekturen Abbildung 13\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-13.png)
Dieser Ansatz hat mehrere Nachteile:
+ **Paketgröße** — Die Lambda-Funktion ist möglicherweise viel größer, da sie den gesamten möglichen Code für alle Pfade enthält, wodurch die Ausführung des Lambda-Dienstes langsamer wird.
+ **Es ist schwierig, die geringste Berechtigung durchzusetzen**: Die [Ausführungsrolle](lambda-intro-execution-role.md) der Funktion muss Berechtigungen für alle Ressourcen gewähren, die für alle Pfade benötigt werden, sodass die Berechtigungen sehr weit gefasst sind. Dies ist ein Sicherheitsproblem. Viele Pfade im funktionalen Monolithen benötigen nicht alle erteilten Berechtigungen.
+ **Schwieriger zu aktualisieren**: In einem Produktionssystem sind Upgrades für eine einzelne Funktion riskanter und können dazu führen, dass die gesamte Anwendung nicht mehr funktioniert. Das Upgrade eines einzelnen Pfads in der Lambda-Funktion ist ein Upgrade der gesamten Funktion.
+ **Schwieriger zu warten**: Es ist schwieriger, mehrere Entwickler an dem Dienst arbeiten zu lassen, da es sich um ein monolithisches Code-Repository handelt. Es erhöht auch die kognitive Belastung der Entwickler und erschwert es, eine angemessene Testabdeckung für Code zu schaffen.
+ **Schwieriger, Code wiederzuverwenden**: Es kann schwieriger sein, wiederverwendbare Bibliotheken von Monolithen zu trennen, was die Wiederverwendung von Code erschwert. Je mehr Projekte Sie entwickeln und unterstützen, desto schwieriger wird es, den Code zu unterstützen und die Geschwindigkeit Ihres Teams zu erhöhen.
+ **Schwieriger zu testen**: Mit zunehmender Anzahl von Codezeilen wird es immer schwieriger, für alle möglichen Kombinationen von Eingaben und Einstiegspunkten in der Codebasis einen Modultest durchzuführen. Es ist generell einfacher, Modultests für kleinere Dienste mit weniger Code zu implementieren.
Die bevorzugte Alternative besteht darin, die monolithische Lambda-Funktion in einzelne Microservices aufzuteilen und eine einzelne Lambda-Funktion einer einzigen, klar definierten Aufgabe zuzuordnen. In dieser einfachen Webanwendung mit einigen API-Endpunkten kann die resultierende Microservice-basierte Architektur auf den API-Gateway-Routen basieren.
![\[ereignisgesteuerte Architekturen, Abbildung 14\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-14.png)
### Rekursive Muster, die außer Kontrolle geratene Lambda-Funktionen verursachen
AWS Dienste generieren Ereignisse, die Lambda-Funktionen aufrufen, und Lambda-Funktionen können Nachrichten an Dienste senden. AWS Im Allgemeinen sollte sich der Dienst oder die Ressource, die eine Lambda-Funktion aufruft, von dem Dienst oder der Ressource unterscheiden, an den die Funktion ausgibt. Wenn dies nicht verwaltet wird, kann dies zu Endlosschleifen führen.
Zum Beispiel schreibt eine Lambda-Funktion ein Objekt in ein Amazon S3-Objekt, das wiederum dieselbe Lambda-Funktion über ein Put-Ereignis aufruft. Durch den Aufruf wird ein zweites Objekt in den Bucket geschrieben, das dieselbe Lambda-Funktion aufruft:
![\[Ereignisgesteuerte Architekturen Abbildung 15\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-15.png)
Während das Potenzial für Endlosschleifen in den meisten Programmiersprachen vorhanden ist, hat dieses Anti-Pattern das Potenzial, mehr Ressourcen in Serverless-Anwendungen zu verbrauchen. Sowohl Lambda als auch Amazon S3 skalieren automatisch auf der Grundlage des Datenverkehrs, sodass die Schleife dazu führen kann, dass Lambda skaliert, um die gesamte verfügbare Parallelität zu nutzen, und Amazon S3 schreibt weiterhin Objekte und generiert mehr Ereignisse für Lambda.
In diesem Beispiel wird S3 verwendet, aber das Risiko von rekursiven Schleifen besteht auch bei Amazon SNS, Amazon SQS, DynamoDB und anderen Diensten. Sie können die [rekursive Schleifenerkennung](invocation-recursion.md) verwenden, um dieses Anti-Pattern zu finden und zu vermeiden.
### Lambda-Funktionen, die Lambda-Funktionen aufrufen
Funktionen ermöglichen die Kapselung und die Wiederverwendung von Code. Die meisten Programmiersprachen unterstützen das Konzept des synchronen Aufrufs von Funktionen innerhalb einer Codebasis. Wenn die Funktion einen Fehler zurückgibt, gibt die Funktion eine Antwort zurück.
**Anmerkung**
Während Lambda-Funktionen, die direkt andere Lambda-Funktionen aufrufen, aus Kosten- und Komplexitätsgründen im Allgemeinen ein Anti-Pattern darstellen, gilt dies nicht für [langlebige Funktionen](durable-functions.md), die speziell dafür konzipiert sind, mehrstufige Workflows zu orchestrieren, indem sie andere Funktionen aufrufen.
Wenn dies auf einem herkömmlichen Server oder einer virtuellen Instance geschieht, wechselt der Scheduler des Betriebssystems zu einer anderen verfügbaren Arbeit. Ob die CPU zu 0 % oder zu 100 % läuft, hat keinen Einfluss auf die Gesamtkosten der Anwendung, da Sie für die Fixkosten des Besitzes und des Betriebs eines Servers zahlen.
Dieses Modell eignet sich häufig nicht gut für die Serverless-Entwicklung. Nehmen wir zum Beispiel eine einfache E-Commerce-Anwendung, die aus drei Lambda-Funktionen besteht, die eine Bestellung verarbeiten:
![\[Ereignisgesteuerte Architekturen Abbildung 16\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-16.png)
In diesem Fall ruft die Funktion *Bestellung erstellen* die Funktion *Zahlung bearbeiten* auf, die wiederum die Funktion *Rechnung erstellen* aufruft. Dieser synchrone Ablauf kann zwar innerhalb einer einzelnen Anwendung auf einem Server funktionieren, führt aber in einer verteilten serverlosen Architektur zu mehreren vermeidbaren Problemen:
+ **Kosten**: Bei Lambda zahlen Sie für die Dauer eines Aufrufs. In diesem Beispiel laufen während der Ausführung der Funktion *Rechnung erstellen* zwei weitere Funktionen in einem Wartezustand, der im Diagramm in Rot dargestellt ist.
+ **Fehlerbehandlung**: Bei verschachtelten Aufrufen kann die Fehlerbehandlung viel komplexer werden. *Ein Fehler in *Rechnung erstellen* kann beispielsweise dazu führen, dass die Funktion „*Zahlung verarbeiten*“ die Belastung rückgängig macht, oder es wird stattdessen der Vorgang „Rechnung erstellen“ erneut versucht.*
+ **Enge Verknüpfung**: Die Bearbeitung einer Zahlung dauert in der Regel länger als die Erstellung einer Rechnung. Bei diesem Modell wird die Verfügbarkeit des gesamten Workflows durch die langsamste Funktion eingeschränkt.
+ **Skalierung**: Die [Gleichzeitigkeit](lambda-concurrency.md) aller drei Funktionen muss gleich sein. In einem stark frequentierten System wird dadurch mehr Gleichzeitigkeit verwendet, als andernfalls erforderlich wäre.
Bei Serverless-Anwendungen gibt es zwei gängige Ansätze, um dieses Muster zu vermeiden. Verwenden Sie zunächst eine Amazon-SQS-Warteschlange zwischen Lambda-Funktionen. Wenn ein nachgeschalteter Prozess langsamer ist als ein vorgeschalteter Prozess, hält die Warteschlange die Nachrichten dauerhaft fest und entkoppelt die beiden Funktionen. In diesem Beispiel würde die Funktion *Bestellung erstellen* eine Nachricht in einer Amazon SQS SQS-Warteschlange veröffentlichen, und die Funktion *Zahlung verarbeiten verarbeitet* Nachrichten aus der Warteschlange.
Der zweite Ansatz besteht darin, AWS Step Functions zu verwenden. Bei komplexen Prozessen mit mehreren Arten von Fehlern und Wiederholungslogik können Schrittfunktionen dazu beitragen, den Umfang des benutzerdefinierten Codes zu reduzieren, der für die Orchestrierung des Workflows erforderlich ist. Infolgedessen orchestriert Step Functions die Arbeit und behandelt Fehler und Wiederholungen zuverlässig und die Lambda-Funktionen enthalten nur Geschäftslogik.
### Synchrones Warten innerhalb einer einzigen Lambda-Funktion
Stellen Sie sicher, dass potenziell gleichzeitige Aktivitäten nicht synchron innerhalb einer einzelnen Lambda-Funktion geplant werden. Eine Lambda-Funktion könnte beispielsweise in einen S3-Bucket und dann in eine DynamoDB-Tabelle schreiben:
![\[Ereignisgesteuerte Architekturen Abbildung 17\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-17.png)
In diesem Design sind die Wartezeiten zusammengesetzt, weil die Aktivitäten sequentiell sind. In Fällen, in denen die zweite Aufgabe von der Fertigstellung der ersten Aufgabe abhängt, können Sie die Gesamtwartezeit und die Ausführungskosten verringern, indem Sie zwei separate Lambda-Funktionen verwenden:
![\[Ereignisgesteuerte Architekturen Abbildung 19\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-19.png)
In diesem Design reagiert die erste Lambda-Funktion sofort, nachdem das Objekt in den Amazon-S3-Bucket gestellt wurde. Der S3-Dienst ruft die zweite Lambda-Funktion auf, die dann Daten in die DynamoDB-Tabelle schreibt. Dieser Ansatz minimiert die Gesamtwartezeit bei der Ausführung von Lambda-Funktionen.
# Entwerfen von Lambda-Anwendungen
Eine gut konzipierte ereignisgesteuerte Anwendung verwendet eine Kombination aus AWS Diensten und benutzerdefiniertem Code, um Anfragen und Daten zu verarbeiten und zu verwalten. Dieses Kapitel konzentriert sich auf Lambda-spezifische Themen im Anwendungsdesign. Bei der Entwicklung von Anwendungen für stark frequentierte Produktionssysteme gibt es viele wichtige Überlegungen für Serverless-Architekten.
Viele der bewährten Verfahren, die für die Softwareentwicklung und verteilte Systeme gelten, gelten auch für die Entwicklung Serverless-Anwendungen. Das übergeordnete Ziel besteht darin, Workloads zu entwickeln, die:
+ **zuverlässig** sind: Sie bieten Ihren Endnutzern ein hohes Maß an Verfügbarkeit. AWS -Serverless-Dienste sind zuverlässig, weil sie auch für Ausfälle ausgelegt sind.
+ **langlebig** sind: Sie bieten Speicheroptionen, die den Anforderungen an die Haltbarkeit Ihrer Workloads gerecht werden.
+ **sicher** sind: Befolgen Sie bewährte Verfahren und verwenden Sie die bereitgestellten Tools, um den Zugriff auf Workloads zu sichern und den Explosionsradius zu begrenzen.
+ **leistungsstark** sind: effiziente Nutzung von Rechenressourcen und Erfüllung der Leistungsanforderungen Ihrer Endbenutzer.
+ **kosteneffizient** sind: Entwicklung von Architekturen zur Vermeidung unnötiger Kosten, die ohne Mehrausgaben skaliert und auch ohne nennenswerten Mehraufwand außer Betrieb genommen werden können.
Die folgenden Designprinzipien können Ihnen dabei helfen, Workloads zu erstellen, die diese Ziele erfüllen. Nicht jedes Prinzip lässt sich auf jede Architektur anwenden, aber sie sollten Ihnen bei allgemeinen Architekturentscheidungen als Leitfaden dienen.
**Topics**
+ [
## Verwendung von Diensten anstelle von benutzerdefiniertem Code
](#services-custom-code)
+ [
## Informationen zu Lambda-Abstraktionsebenen
](#level-abstraction)
+ [
## Implementieren der Zustandslosigkeit in Funktionen
](#statelessness-functions)
+ [
## Kopplung minimieren
](#minimize-coupling)
+ [
## Entwickeln für On-Demand-Daten statt Batches
](#on-demand-batches)
+ [
## Wählen Sie eine Orchestrierungsoption für komplexe Workflows
](#orchestration)
+ [
## Implementieren von Idempotenz
](#retries-failures)
+ [
## Verwenden Sie mehrere Konten für die Verwaltung von Kontingenten AWS
](#multiple-accounts)
## Verwendung von Diensten anstelle von benutzerdefiniertem Code
Serverlose Anwendungen bestehen normalerweise aus mehreren AWS Diensten, die mit benutzerdefiniertem Code integriert sind, der in Lambda-Funktionen ausgeführt wird. Lambda kann zwar in die meisten AWS Dienste integriert werden, aber die Dienste, die in serverlosen Anwendungen am häufigsten verwendet werden, sind:
| Kategorie | AWS Dienst |
| --- | --- |
| Datenverarbeitung | AWS Lambda |
| Datenspeicher | Amazon S3 Amazon DynamoDB Amazon RDS |
| API | Amazon API Gateway |
| Integration von Anwendungen | Amazon EventBridge Amazon SNS Amazon SQS |
| Orchestrierung | Langlebige Lambda-Funktionen AWS Step Functions |
| Streaming-Daten und Analysen | Amazon Data Firehose |
**Anmerkung**
Viele Serverless-Dienste bieten Replikation und Support für mehrere Regionen, einschließlich DynamoDB und Amazon S3. Lambda-Funktionen können als Teil einer Bereitstellungspipeline in mehreren Regionen bereitgestellt werden und API Gateway kann so konfiguriert werden, dass es diese Konfiguration unterstützt. Sehen Sie sich diese [Beispielarchitektur](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/serverless-architecture-for-global-applications-ra.pdf?did=wp_card&trk=wp_card) an, die zeigt, wie dies erreicht werden kann.
Es gibt viele etablierte, gängige Muster in verteilten Architekturen, die Sie selbst erstellen oder mithilfe von Diensten implementieren können. AWS Für die meisten Kunden ist es wirtschaftlich nicht sinnvoll, Zeit in die Entwicklung dieser Muster zu investieren. Wenn Ihre Anwendung eines dieser Muster benötigt, verwenden Sie den entsprechenden AWS Dienst:
| Muster | AWS Dienst |
| --- | --- |
| Warteschlange | Amazon SQS |
| Ereignisbus | Amazon EventBridge |
| Veröffentlichen/Abonnieren (Fan-Out) | Amazon SNS |
| Orchestrierung | Langlebige Lambda-Funktionen AWS Step Functions |
| API | Amazon API Gateway |
| Ereignis-Streams | Amazon Kinesis |
Diese Dienste sind für die Integration mit Lambda konzipiert und Sie können Infrastructure as Code (IaC) verwenden, um Ressourcen in den Diensten zu erstellen und zu verwerfen. Sie können jeden dieser Dienste über das [AWS SDK](https://aws.amazon.com/tools/) nutzen, ohne dass Sie Anwendungen installieren oder Server konfigurieren müssen. Der Umgang mit diesen Diensten über den Code in Ihren Lambda-Funktionen ist ein wichtiger Schritt zur Erstellung gut konzipierter Serverless-Anwendungen.
## Informationen zu Lambda-Abstraktionsebenen
Der Lambda-Dienst beschränkt Ihren Zugriff auf die zugrunde liegenden Betriebssysteme, Hypervisoren und Hardware, auf denen Ihre Lambda-Funktionen ausgeführt werden. Der Dienst wird ständig verbessert und die Infrastruktur verändert, um neue Features hinzuzufügen, die Kosten zu senken und den Dienst leistungsfähiger zu machen. Ihr Code sollte kein Wissen darüber voraussetzen, wie Lambda aufgebaut ist und keine Hardware-Affinität voraussetzen.
In ähnlicher Weise werden die Integrationen von Lambda mit anderen Diensten von verwaltet AWS, sodass Ihnen nur eine geringe Anzahl von Konfigurationsoptionen zur Verfügung steht. Bei der Interaktion zwischen API Gateway und Lambda gibt es beispielsweise kein Konzept für den Load Balancer, da dieser vollständig von den Diensten verwaltet wird. Sie haben auch keine direkte Kontrolle darüber, welche [Verfügbarkeitszonen](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/) die Dienste beim Aufrufen von Funktionen zu einem bestimmten Zeitpunkt verwenden oder wie Lambda entscheidet, wann die Anzahl der Ausführungsumgebungen nach oben oder unten skaliert wird.
Diese Abstraktion ermöglicht es Ihnen, sich auf die Integrationsaspekte Ihrer Anwendung, den Datenfluss und die Geschäftslogik zu konzentrieren, bei denen Ihr Workload einen Mehrwert für Ihre Endbenutzer bietet. Wenn Sie den Diensten die Verwaltung der zugrundeliegenden Mechanismen überlassen, können Sie Anwendungen schneller entwickeln und müssen weniger eigenen Code pflegen.
## Implementieren der Zustandslosigkeit in Funktionen
Bei Standard-Lambda-Funktionen sollten Sie davon ausgehen, dass die Umgebung nur für einen einzigen Aufruf existiert. Die Funktion sollte beim ersten Start alle erforderlichen Zustände initialisieren. Beispielsweise kann Ihre Funktion das Abrufen von Daten aus einer DynamoDB-Tabelle erfordern. Sie sollte alle dauerhaften Datenänderungen vor dem Beenden in einem dauerhaften Speicher wie Amazon S3, DynamoDB oder Amazon SQS speichern. Sie sollte sich nicht auf bestehende Datenstrukturen oder temporäre Dateien oder auf interne Zustände stützen, die bei mehreren Aufrufen verwaltet würden.
Bei der Verwendung von Durable Functions wird der Status zwischen Aufrufen automatisch beibehalten, sodass der Status nicht manuell im externen Speicher gespeichert werden muss. Für alle Daten, die nicht explizit über den verwaltet werden, sollten Sie jedoch weiterhin die Prinzipien der Zustandslosigkeit beachten. DurableContext
Um Datenbankverbindungen und Bibliotheken zu initialisieren oder den Status zu laden, können Sie die [statische Initialisierung](lambda-runtime-environment.md#static-initialization) nutzen. Da Ausführungsumgebungen nach Möglichkeit wiederverwendet werden, um die Leistung zu verbessern, können Sie die für die Initialisierung dieser Ressourcen benötigte Zeit über mehrere Aufrufe hinweg amortisieren. Sie sollten jedoch keine Variablen oder Daten, die in der Funktion verwendet werden, in diesem globalen Bereich speichern.
## Kopplung minimieren
Die meisten Architekturen sollten viele, kürzere Funktionen den wenigen, größeren vorziehen. Der Zweck jeder Funktion sollte darin bestehen, das an die Funktion übergebene Ereignis zu verarbeiten, ohne Kenntnisse oder Erwartungen in Bezug auf den gesamten Arbeitsablauf oder das Transaktionsvolumen. Dadurch ist die Funktion unabhängig von der Quelle des Ereignisses und nur minimal mit anderen Diensten verbunden.
Alle Konstanten mit globalem Geltungsbereich, die sich nur selten ändern, sollten als Umgebungsvariablen implementiert werden, um Aktualisierungen ohne Bereitstellungen zu ermöglichen. Alle Geheimnisse oder sensiblen Informationen sollten im [AWS Systems Manager Parameter Store](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) oder [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/) gespeichert und von der Funktion geladen werden. Da diese Ressourcen kontospezifisch sind, können Sie auf diese Weise Build-Pipelines für mehrere Konten erstellen. Die Pipelines laden die entsprechenden Geheimnisse für jede Umgebung, ohne dass diese für Entwickler sichtbar sind oder Codeänderungen erforderlich sind.
## Entwickeln für On-Demand-Daten statt Batches
Viele herkömmliche Systeme sind so konzipiert, dass sie periodisch laufen und Batch von Transaktionen verarbeiten, die sich im Laufe der Zeit angesammelt haben. So kann beispielsweise eine Bankanwendung stündlich laufen, um die Transaktionen von Geldautomaten in einem zentralen Hauptbuch zu verarbeiten. In Lambda-basierten Anwendungen sollte die benutzerdefinierte Verarbeitung durch jedes Ereignis ausgelöst werden, so dass der Dienst bei Bedarf die Gleichzeitigkeit erhöhen kann, um die Verarbeitung von Transaktionen nahezu in Echtzeit zu ermöglichen.
Während Standard-Lambda-Funktionen auf eine Ausführungszeit von 15 Minuten begrenzt sind, können Durable Functions bis zu einem Jahr lang ausgeführt werden, sodass sie für länger andauernde Verarbeitungsanforderungen geeignet sind. Dennoch sollten Sie, wenn möglich, die ereignisgesteuerte Verarbeitung der Stapelverarbeitung vorziehen.
Sie können [Cron-Aufgaben](https://en.wikipedia.org/wiki/Cron) zwar in serverlosen Anwendungen ausführen, [indem Sie geplante Ausdrücke für Regeln in Amazon verwenden](https://docs.aws.amazon.com/eventbridge/latest/userguide/scheduled-events.html) EventBridge, diese sollten jedoch sparsam oder als letztes Mittel verwendet werden. Bei jeder geplanten Aufgabe, die einen Batch verarbeitet, besteht die Möglichkeit, dass das Transaktionsvolumen über das hinausgeht, was innerhalb des 15-minütigen Lambda-Dauerbegrenzung verarbeitet werden kann. Wenn Sie aufgrund der Einschränkungen externer Systeme gezwungen sind, einen Scheduler zu verwenden, sollten Sie in der Regel für den kürzesten sinnvollen wiederkehrenden Zeitraum planen.
So ist es beispielsweise keine optimale Vorgehensweise, einen Batch-Prozess zu verwenden, der eine Lambda-Funktion auslöst, um eine Liste neuer Amazon-S3-Objekte abzurufen. Dies liegt daran, dass der Dienst zwischen den Batches möglicherweise mehr neue Objekte erhält, als innerhalb einer 15-minütigen Lambda-Funktion verarbeitet werden können.
![\[Ereignisgesteuerte Architekturen Abbildung 10\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-10.png)
Stattdessen sollte Amazon S3 die Lambda-Funktion jedes Mal aufrufen, wenn ein neues Objekt in den Bucket gestellt wird. Dieser Ansatz ist deutlich skalierbarer und funktioniert nahezu in Echtzeit.
![\[Ereignisgesteuerte Architekturen Abbildung 11\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/event-driven-architectures-figure-11.png)
## Wählen Sie eine Orchestrierungsoption für komplexe Workflows
Workflows, die Verzweigungslogik, verschiedene Arten von Fehlermodellen und Wiederholungslogik beinhalten, verwenden in der Regel einen Orchestrator, um den Status der Gesamtausführung zu verfolgen. Erstellen Sie keine Ad-hoc-Orchestrierung in Standard-Lambda-Funktionen. Dies führt zu einer engen Kopplung, komplexem Routing-Code und keiner automatischen Statuswiederherstellung.
Verwenden Sie stattdessen eine dieser speziell entwickelten Orchestrierungsoptionen:
+ **[Dauerhafte Lambda-Funktionen](durable-functions.md):** Anwendungsorientierte Orchestrierung mithilfe von Standardprogrammiersprachen mit automatischem Checkpointing, integriertem Wiederholungsversuch und Ausführungswiederherstellung. Ideal für Entwickler, die es vorziehen, die Workflow-Logik im Code neben der Geschäftslogik in Lambda beizubehalten.
+ **[AWS Step Functions](with-step-functions.md):** Visuelle Workflow-Orchestrierung mit nativen Integrationen für mehr als 220 Dienste. AWS Ideal für die Koordination mehrerer Dienste, eine wartungsfreie Infrastruktur und ein visuelles Workflow-Design.
Anleitungen zur Auswahl zwischen diesen Optionen finden Sie unter [Dauerhafte Funktionen oder Step Functions](durable-step-functions.md).
Mit [ Step Functions](https://aws.amazon.com/step-functions/) verwenden Sie Zustandsmaschinen, um die Orchestrierung zu verwalten. Dadurch werden die Fehlerbehandlung, das Routing und die Verzweigungslogik aus Ihrem Code extrahiert und durch Zustandsautomaten ersetzt, die mit JSON deklariert werden. Abgesehen davon, dass es Workflows robuster und beobachtbarer macht, ermöglicht es Ihnen auch, Workflows zu versionieren und den Zustandsautomaten zu einer kodifizierten Ressource zu machen, die Sie zu einem Code-Repository hinzufügen können.
Es ist üblich, dass einfachere Workflows in Lambda-Funktionen mit der Zeit komplexer werden. Beim Betrieb einer serverlosen Produktionsanwendung ist es wichtig, zu ermitteln, wann dies der Fall ist, damit Sie diese Logik auf eine Zustandsmaschine oder eine dauerhafte Funktion migrieren können.
## Implementieren von Idempotenz
AWS Serverlose Dienste, einschließlich Lambda, sind fehlertolerant und für den Umgang mit Ausfällen konzipiert. Wenn beispielsweise ein Dienst eine Lambda-Funktion aufruft und es zu einer Dienstunterbrechung kommt, ruft Lambda Ihre Funktion in einer anderen Verfügbarkeitszone auf. Wenn Ihre Funktion einen Fehler auslöst, wiederholt Lambda den Aufruf.
Da ein und dasselbe Ereignis mehr als einmal eintreten kann, sollten die Funktionen [idempotent](https://en.wikipedia.org/wiki/Idempotence) sein. Dies bedeutet, dass der mehrfache Empfang desselben Ereignisses das Ergebnis nicht über den ersten Empfang hinaus verändert.
Sie können Idempotenz in Lambda-Funktionen implementieren, indem Sie eine DynamoDB-Tabelle verwenden, um kürzlich verarbeitete Bezeichner zu verfolgen und festzustellen, ob die Transaktion bereits zuvor bearbeitet wurde. Die DynamoDB-Tabelle implementiert in der Regel einen [TTL-Wert (Time To Live)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html) für ablaufende Elemente, um den verwendeten Speicherplatz zu begrenzen.
## Verwenden Sie mehrere Konten für die Verwaltung von Kontingenten AWS
Viele [Servicekontingente](gettingstarted-limits.md) AWS werden auf Kontoebene festgelegt. Das bedeutet, dass Sie bei zunehmendem Workload schnell an Ihre Grenzen stoßen können.
Eine effektive Möglichkeit, dieses Problem zu lösen, besteht darin, mehrere AWS Konten zu verwenden und jede Arbeitslast einem eigenen Konto zuzuweisen. Dadurch wird verhindert, dass Kontingente mit anderen Workloads oder Ressourcen außerhalb der Produktion geteilt werden.
Mithilfe von [AWS -Organisationen](https://aws.amazon.com/organizations/) können Sie außerdem die Abrechnung, Compliance und Sicherheit dieser Konten zentral verwalten. Sie können Richtlinien an Gruppen von Konten anhängen, um benutzerdefinierte Skripts und manuelle Prozesse zu vermeiden.
Ein gängiger Ansatz besteht darin, jedem Entwickler ein AWS Konto zur Verfügung zu stellen und dann separate Konten für die Betabereitstellungsphase und die Produktion zu verwenden:
![\[Anwendungsdesign, Abbildung 3\]](http://docs.aws.amazon.com/de_de/lambda/latest/dg/images/application-design-figure-3.png)
In diesem Modell hat jeder Entwickler seine eigenen Beschränkungen für das Konto, sodass sich deren Nutzung nicht auf Ihre Produktionsumgebung auswirkt. Dieser Ansatz ermöglicht es Entwicklern auch, Lambda-Funktionen lokal auf ihren Entwicklungsmaschinen anhand von Live-Cloud-Ressourcen in ihren individuellen Konten zu testen.