AWS Lambda – Häufig gestellte Fragen

Eine vollständige Liste von Ereignisquellen finden Sie in unserer Dokumentation.

AWS Lambda unterstützt nativ Java, Go, PowerShell, Node.js, C#, Python und Ruby-Code. Es bietet außerdem eine Runtime API, mit der zusätzliche Programmiersprachen zum Erstellen von Funktionen genutzt werden können. Lesen Sie unsere Dokumentation über die Nutzung von Node.js, Python, Java, Ruby, C#, Go und PowerShell.

Jede AWS-Lambda-Funktion führt ihre eigene isolierte Umgebung aus, mit eigenen Ressourcen und eigener Dateisystemansicht. AWS Lambda verwendet für die Sicherheit und die Trennung auf Infrastruktur- und Ausführungsebene dieselben Methoden wie Amazon EC2. Weitere Informationen finden Sie in der Dokumentation.

AWS Lambda speichert Code auf Amazon S3 und verschlüsselt ihn bei der Speicherung. AWS Lambda führt zusätzliche Integritätsprüfungen durch, während Ihr Code verwendet wird. Für sensible Informationen wie Datenbankpasswörter empfehlen wir die clientseitige Verschlüsselung mit AWS Key Management Service. Speichern Sie die daraus resultierenden Werte anschließend als Geheimtext in Ihrer Umgebungsvariable. Zum Verschlüsseln dieser Werte müssen Sie Logik in Ihren AWS-Lambda-Funktionscode einbeziehen. Weitere Informationen finden Sie in der Dokumentation.

Ja. Sie können über die AWS Lambda-Konsole, CLI oder SDKs auf einfach Weise Umgebungsvariablen erstellen und ändern. Weitere Informationen zu Umgebungsvariablen finden Sie in der Dokumentation.

Für sensible Informationen wie Datenbankpasswörter empfehlen wir die clientseitige Verschlüsselung mit AWS Key Management Service. Speichern Sie die daraus resultierenden Werte anschließend als Geheimtext in Ihrer Umgebungsvariable. Zum Verschlüsseln dieser Werte müssen Sie Logik in Ihren AWS Lambda-Funktionscode einbeziehen.

Ja, Sie können jeden Code (Frameworks, SDKs, Bibliotheken und mehr) als Lambda Layer verpacken und dies dann über mehrere Funktionen hinweg verwalten und teilen.

AWS Lambda überwacht automatisch Lambda-Funktionen für Sie und berichtet in Echtzeit über Metriken in Amazon CloudWatch, einschließlich Gesamtanforderungen, gleichzeitiger Nutzung auf Konto- und Funktionsebene, Latenz, Fehlerraten und gedrosselter Anforderungen. Kennzahlen über die einzelnen Lambda-Funktionen können Sie über die Amazon CloudWatch-Konsole oder die AWS Lambda-Konsole anzeigen. Sie können in Ihrer Lambda-Funktion auch Überwachungs-APIs anderer Anbieter aufrufen.
 

Weitere Informationen finden Sie in Fehlerbehebung von CloudWatch-Metriken. Für die in Lambda integrierten Kennzahlen werden die Standardgebühren für AWS Lambda berechnet.

Beim AWS-Lambda-Ressourcenmodell wählen Sie die Größe des Arbeitsspeichers, die Sie für Ihre Funktion möchten, und bekommen Rechenleistung und andere Ressourcen proportional zugewiesen. Bei Auswahl von 256 MB Arbeitsspeicher beispielsweise wird Ihrer Lambda-Funktion ungefähr doppelt so viel Rechenleistung zugewiesen als bei Anforderung von 128 MB Arbeitsspeicher, und halb so viel Rechenleistung als bei Auswahl von 512 MB Arbeitsspeicher. Mehr erfahren Sie in unserer Funktionskonfigurations-Dokumentation.

Sie können Ihren Speicher von 128 MB bis 10 240 MB einstellen.

Bei AWS Lambda wird nur die tatsächliche Nutzung berechnet. Weitere Informationen finden Sie auf der Seite mit den Preisen für AWS Lambda.

Ja. Standardmäßig hat jede AWS Lambda-Funktion eine einzige, aktuelle Code-Version. Clients Ihrer Lambda-Funktion können eine spezifische Version aufrufen oder die letzte Implementierung erhalten. Bitte lesen Sie die Dokumentation über Versionsverwaltung von Lambda-Funktionen.

AWS Lambda bietet flexible Bereitstellungsoptionen: Verpacken und Bereitstellen von Funktionen als.zip-Dateiarchive, die Sie direkt über die Konsole, CLI oder SDKs hochladen können, oder als Container-Images. Beide Methoden bieten dieselbe Ausführungsumgebung, Skalierung und Bedienungsfreundlichkeit, sodass Sie flexibel den Ansatz wählen können, der am besten zu Ihrem Workflow passt.

Sie können eine AWS-Lambda-Funktion mittels eines benutzerdefinierten Ereignisses über die invoke-API von Lambda aufrufen. Die Funktion kann nur vom Eigentümer der Funktion oder von einem anderen AWS-Konto mit Genehmigung des Eigentümers aufgerufen werden. Weitere Informationen finden Sie im Lambda-Entwicklerhandbuch.

AWS Lamba SnapStart kann die Startleistung für latenzempfindliche Anwendungen von einigen Sekunden auf nur wenige Sekunden verbessern. SnapStart erstellt einen Snapshot des initialisierten Speichers (und des Festplattenstatus) Ihrer Funktion und speichert diesen Snapshot für den Zugriff mit niedriger Latenz im Cache. Wenn Ihre Funktion anschließend aufgerufen wird, nimmt Lambda die Ausführungsumgebungen aus diesem vorinitialisierten Snapshot wieder auf, anstatt sie von Grund auf neu zu initialisieren, wodurch die Startlatenz verbessert wird. Aus Gründen der Ausfallsicherheit verwaltet Lambda zwischengespeicherte Kopien Ihres Snapshots und wendet automatisch Software-Updates wie Laufzeit-Upgrades und Sicherheitspatches darauf an. Weitere Informationen finden Sie in der Dokumentation.

Lambda SnapStart ist eine einfache Konfiguration auf Funktionsebene, die für neue und bestehende Funktionen mithilfe der Lambda-API, der AWS-Managementkonsole, der AWS-Befehlszeilenschnittstelle (CLI), dem AWS SDK, dem AWS Cloud Development Kit (CDK), AWS CloudFormation und dem AWS Serverless Application Model (SAM) konfiguriert werden kann. Wenn Sie Lambda SnapStart konfigurieren, profitiert jede Funktionsversion, die danach veröffentlicht wird, von der verbesserten Startleistung von Lambda SnapStart. Um mehr über Lambda SnapStart zu erfahren, lesen Sie die Dokumentation.

Lambda SnapStart ist eine Leistungsoptimierung, die Ihren Funktionen zu einer schnelleren Startzeit verhilft, indem sie die variable Latenz, die bei der Ausführung von einmaligem Initialisierungscode entsteht, reduziert. Lambda SnapStart reduziert zwar die Startlatenz, arbeitet aber als bestmögliche Optimierung und garantiert nicht die Beseitigung von Kaltstarts. Wenn Ihre Anwendung strenge Anforderungen an die Latenzzeit stellt und Startzeiten im zweistelligen Millisekundenbereich erfordert, empfehlen wir Ihnen die Verwendung von PC.

Lambda SnapStart unterstützt mehrere Laufzeiten, darunter Java 11 (und neuer), Python 3.12 (und neuer) und .NET 8 (und neuer). Zukünftige Versionen von Laufzeiten werden unterstützt, sobald sie veröffentlicht werden. Alle von Lambda unterstützten Laufzeiten finden Sie in der Dokumentation der Lambda-Laufzeiten.

Ja. Sie können eine Lambda SnapStart-Funktion für den Zugriff auf Ressourcen in einer Virtual Private Cloud (VPC) konfigurieren. Weitere Informationen darüber, wie Sie Ihre Funktion mit einer VPC konfigurieren, finden Sie in der Lambda-Dokumentation.

Ja, das Zwischenspeichern eines Snapshots über den Zeitraum, in dem Ihre Funktionsversion aktiv ist, wird Ihnen für mindestens 3 Stunden und danach pro Millisekunde in Rechnung gestellt. Der Preis ist abhängig von der Arbeitsspeichergröße, die Sie Ihrer Funktion zuweisen. Außerdem wird Ihnen jedes Mal berechnet, wenn Lambda eine Ausführungsumgebung durch die Wiederherstellung Ihres Snapshots wieder aufnimmt. Der Preis hängt von der Menge an Arbeitsspeicher ab, die Sie Ihrer Funktion zuweisen. Um mehr über die Preise für SnapStart zu erfahren, besuchen Sie bitte Preise für AWS Lambda.

Die SnapStart-Preise gelten nicht für unterstützte, von Java verwaltete Laufzeiten, bei denen ein Snapshot nur bis zu 14 Tage zwischengespeichert werden kann.

Die bereitgestellte Nebenläufigkeit gibt Ihnen mehr Kontrolle über die Leistung Ihrer Serverless-Anwendungen. Wenn aktiviert, hält bereitgestellte Nebenläufigkeit die Funktionen initialisiert und hyperbereit, um in zweistelligen Millisekunden zu reagieren.

Sie können die Nebenläufigkeit Ihrer Funktion über die AWS-Managementkonsole, die Lambda API, die AWS CLI und AWS CloudFormation konfigurieren. Die einfachste Möglichkeit, von Provisioned Concurrency zu profitieren, ist die Verwendung von AWS Auto Scaling. Sie können Auto Scaling von Anwendungen verwenden, um Zeitpläne zu konfigurieren, oder die automatische Skalierung automatisch die Höhe der Provisioned Concurrency in Echtzeit anpassen lassen, wenn sich die Nachfrage ändert. Um mehr über bereitgestellte Nebenläufigkeit zu erfahren, lesen Sie die Dokumentation.

Bereitgestellte Nebenläufigkeit fügt eine Preisdimension der „bereitgestellten Nebenläufigkeit“ hinzu, um die Funktionen initialisiert zu halten. Sie bezahlen bei Aktivierung für den Betrag der Parallelität, den Sie konfigurieren, und für den Zeitraum, den Sie konfigurieren. Wenn Ihre Funktion ausgeführt wird, während Provisioned Concurrency auf ihr konfiguriert ist, bezahlen Sie auch für Anfragen und Ausführungsdauer. Weitere Informationen über die Preisgestaltung von der bereitgestellten Nebenläufigkeit finden Sie unter AWS-Lambda-Preise.

Mit Lambda@Edge können Sie Code global über AWS-Standorte ausführen, ohne Server bereitstellen oder verwalten zu müssen, wobei sich die minimale Netzwerklatenz in den Reaktionszeiten für die Endbenutzer kaum bemerkbar macht. Sie laden einfach Ihren Node.js- oder Python-Code auf AWS Lambda hoch und konfigurieren Ihre Funktion so, dass sie als Antwort auf Amazon CloudFront-Anforderungen ausgelöst wird (d. h., wenn eine Viewer-Anfrage landet, wenn eine Anfrage an den Ursprung weitergeleitet oder von diesem empfangen wird bevor Sie dem Endbenutzer antworten). Der Code ist dann bei Eintreffen einer Inhaltsanforderung bereit zur globalen Ausführung über alle AWS-Standorte, wobei er sich dem globalen Volumen der CloudFront-Anforderungen entsprechend skaliert. Weitere Informationen finden Sie in unserer Dokumentation.

Zur Verwendung von Lambda@Edge ist lediglich Folgendes erforderlich: Sie laden Ihren Code in AWS Lambda hoch und verknüpfen eine Funktionsversion, die als Reaktion auf Amazon-CloudFront-Anforderungen ausgelöst werden soll. Ihr Code muss dabei den Service Limits von Lambda@Edge entsprechen. Lambda@Edge unterstützt derzeit Node.js und Python für den globalen Aufruf durch CloudFront-Ereignisse. Weitere Informationen finden Sie in unserer Dokumentation.

Lambda@Edge ist für latenzkritische Anwendungsfälle mit global verteilten Endbetrachtern optimiert. Alle Informationen, die für Ihre Entscheidung erforderlich sind, sollten am CloudFront-Edge innerhalb der Funktion und der Anforderung verfügbar sein. Das bedeutet, dass Anwendungsfälle, in denen Sie die Entscheidung treffen müssen, wie der Inhalt auf Basis von Benutzermerkmalen behandelt werden muss (z. B. am Standort, auf dem Clientgerät usw.), nun in Benutzernähe ausgeführt und behandelt werden können, ohne an einen zentralen Server zurückgeleitet zu werden.

Bestehende Lambda-Funktionen aus können Sie für den globalen Aufruf mit CloudFront-Ereignissen verknüpfen, sofern die Funktion die Service-Anforderungen und -Einschränkungen von Lambda@Edge erfüllt. Informationen zur Änderung von Funktionseigenschaften erhalten Sie hier.

AWS Lambda ist für die parallele Ausführung vieler Instances Ihrer Funktionen konzipiert. AWS Lambda verfügt jedoch über eine standardmäßige Sicherheitsdrosselung für die Anzahl der gleichzeitigen Ausführungen pro Konto und Region (Informationen zu den Beschränkungen für die standardmäßige Sicherheitsdrosselung finden Sie hier). Sie können für einzelne AWS-Lambda-Funktionen auch kontrollieren, wie viele von ihnen gleichzeitig ausgeführt werden können. So haben Sie einen Teil der beschränkten gleichzeitigen Nutzung für kritische Funktionen übrig oder können den Datenverkehr auf nachgeschaltete Ressourcen begrenzen.

Wenn Sie eine Anfrage zur Erhöhung des Limits für die gleichzeitige Ausführung einreichen möchten, können Sie Service Quotas verwenden, um eine Anfrage zur Erhöhung des Limits zu beantragen.

Bei Überschreitung des Limits für gleichzeitige Ausführungen geben AWS-Lambda-Funktionen, die synchron aufgerufen werden, einen Drosselungsfehler (Fehlercode 429) zurück. Synchron aufgerufene Lambda-Funktionen können Verkehrsspitzen in gewissem Rahmen für 15 bis 30 Minuten absorbieren. Danach werden eingehende Ereignisse als gedrosselt zurückgewiesen. Falls die Lambda-Funktion als Reaktion auf Amazon S3-Ereignisse aufgerufen wird, können Ereignisse, die durch AWS Lambda zurückgewiesen wurden, bis zu 24 Stunden aufbewahrt und durch S3 erneut eingereicht werden. Ereignisse aus Amazon Kinesis Streams und Amazon DynamoDB Streams werden so lange erneut versucht, bis die Lambda-Funktion erfolgreich ist oder die Zeit abläuft. Amazon Kinesis- und Amazon DynamoDB-Streams bewahren Daten bis zu 24 Stunden auf.

Das standardmäßige maximale Limit für gleichzeitige Ausführung wird auf Kontoebene angewendet. Sie können jedoch auch Grenzen für einzelne Funktionen festlegen (Informationen zu Reservierter Nebenläufigkeit finden Sie hier).

Jede synchron aufgerufene Lambda-Funktion kann mit einer Geschwindigkeit von bis zu 1 000 gleichzeitigen Ausführungen alle 10 Sekunden skaliert werden. Die Skalierungsrate von Lambda ist zwar für die meisten Anwendungsfälle geeignet, eignet sich jedoch besonders für Anwendungen mit vorhersehbaren oder unvorhersehbaren Datenverkehrsspitzen. Beispielsweise würde eine SLA-gebundene Datenverarbeitung eine vorhersehbare und dennoch schnelle Skalierung erfordern, um den Verarbeitungsanforderungen gerecht zu werden. In ähnlicher Weise könnte das Ausliefern von aktuellen Nachrichtenartikeln oder Blitzverkäufen in kurzer Zeit zu einem unvorhersehbaren Besucheraufkommen führen. Die Skalierungsrate von Lambda kann solche Anwendungsfälle ohne zusätzliche Konfigurationen oder Tools ermöglichen. Darüber hinaus ist das Limit für die Nebenläufigkeitsskalierung ein Limit auf Funktionsebene, was bedeutet, dass jede Funktion in Ihrem Konto unabhängig von anderen Funktionen skaliert wird.

Für den Fall, dass die Wiederholungsrichtlinie für asynchrone Aufrufe überschritten wird, können Sie eine Warteschlange für unzustellbare Nachrichten (Dead-Letter-Queue (DLQ)) einrichten, in die das Ereignis eingereiht wird. Wenn keine DLQ konfiguriert ist, wird das Ereignis vermutlich abgelehnt. Falls ein Stream-basierter Aufruf die Wiederholungsrichtlinie überschreitet, sind die Daten vermutlich abgelaufen und wurden daher bereits abgelehnt.

Sie erteilen Ihrer Lambda-Funktion mithilfe der IAM-Rolle Berechtigungen zum Zugriff auf andere Ressourcen. AWS Lambda übernimmt bei der Ausführung Ihrer Lambda-Funktion die Ausführungsrolle. Sie können also immer vollständig und sicher kontrollieren, welche AWS-Ressourcen dabei verwendet werden dürfen. Weitere Informationen zu Rollen finden Sie in AWS Lambda einrichten.

Wenn Sie einen Amazon-S3-Bucket für das Senden von Nachrichten an eine AWS-Lambda-Funktion konfigurieren, wird eine Regel zu Ressourcenrichtlinien erstellt, die Zugriff gewährt. Im Lambda-Entwicklerhandbuch finden Sie weitere Informationen zu Ressourcenrichtlinien und Zugriffskontrollen für Lambda-Funktionen.

Zugriffskontrollen werden über die Lambda-Funktionsrolle verwaltet. Die Rolle, die Sie Ihrer Lambda-Funktion zuweisen, bestimmt auch, welche Ressourcen AWS Lambda im eigenen Namen abfragen kann. Weitere Informationen finden Sie im Lambda-Entwicklerhandbuch.

Sie können Lambda-Funktionen für den Zugriff auf Ressourcen in Ihrer VPC aktivieren, indem Sie das Subnetz und die Sicherheitsgruppe als Teil Ihrer Funktionskonfiguration angeben. Lambda-Funktionen, die für den Zugriff auf Ressourcen in einer bestimmten VPC konfiguriert wurden, haben standardmäßig keinen Zugriff auf das Internet. Verwenden Sie Internet-Gateways, um diesen Funktionen Internet zu gewähren. Standardmäßig kommunizieren Lambda-Funktionen mit Ressourcen in einer Dual-Stack-VPC über IPv4. Sie können Ihre Funktionen so konfigurieren, dass sie über IPv6 auf Ressourcen in einer Dual-Stack-VPC zugreifen. Weitere Informationen zu Lambda-Funktionen, die mit VPC konfiguriert wurden, finden Sie unter Lambda Private Networking with VPC.

Codesignatur für AWS Lambda bietet Vertrauens- und Integritätskontrollen, mit denen Sie überprüfen können, dass nur unveränderter Code von zugelassenen Entwicklern in Ihren Lambda-Funktionen bereitgestellt wird. Sie können AWS Signer, einen vollständig verwalteten Code-Signing-Service, verwenden, um Code-Artefakte digital zu signieren und Ihre Lambda-Funktionen so zu konfigurieren, dass die Signaturen bei der Bereitstellung verifiziert werden. Codesignatur für AWS Lambda ist derzeit nur für Funktionen verfügbar, die als ZIP-Archive verpackt sind.

Sie können digital signierte Code-Artefakte mit einem Signierprofil über die AWS-Signer-Konsole, die Signer-API, SAM CLI oder AWS CLI erstellen. Weitere Informationen finden Sie in der AWS-Signer-Dokumentation.

AWS Lambda kann bei der Bereitstellung folgende Signaturprüfungen durchführen:

• Korrupte Signatur – Dies tritt auf, wenn das Code-Artefakt seit dem Signieren verändert wurde.
• Nicht übereinstimmende Signatur – Dies tritt auf, wenn das Code-Artefakt von einem Signierprofil signiert wird, das nicht zugelassen ist.
• Abgelaufene Signatur – Dies tritt auf, wenn die Signatur das konfigurierte Ablaufdatum überschritten hat.
• Widerrufene Signatur – Dies tritt auf, wenn der Besitzer des Signierprofils die Signieraufträge widerruft.

Weitere Informationen finden Sie in der AWS-Lambda-Dokumentation.

Es fallen keine zusätzlichen Kosten an, wenn Sie Codesignatur für AWS Lambda verwenden. Sie zahlen den Standardpreis für AWS Lambda. Weitere Informationen finden Sie unter Preise.

Um Ihnen standardmäßig eine vereinfachte und verbesserte Protokollierungserfahrung zu bieten, bietet AWS Lambda erweiterte Protokollierungskontrollen wie die Möglichkeit, Lambda-Funktionsprotokolle nativ im strukturierten JSON-Format zu erfassen, die Filterung von Lambda-Funktionsprotokollen auf Protokollebene zu steuern, ohne Codeänderungen vorzunehmen, und die Amazon-CloudWatch-Protokollgruppe anzupassen, an die Lambda Protokolle sendet.

Sie können Lambda-Funktionsprotokolle im strukturierten JSON-Format erfassen, ohne Ihre eigenen Protokollierungs-Bibliotheken verwenden zu müssen. Strukturierte JSON-Logs erleichtern das Suchen, Filtern und Analysieren großer Mengen von Protokolleinträgen. Sie können die Filterung von Lambda-Funktionsprotokollen auf Protokollebene steuern, ohne Codeänderungen vorzunehmen. Auf diese Weise können Sie die erforderliche Protokollierungsgranularitätsstufe für Lambda-Funktionen auswählen, ohne beim Debuggen und Beheben von Fehlern große Mengen an Protokollen durchsuchen zu müssen. Sie können auch festlegen, an welche Amazon-CloudWatch-Protokollgruppe Lambda Protokolle sendet, wodurch es einfacher wird, Protokolle von mehreren Funktionen innerhalb einer Anwendung an einem Ort zu aggregieren. Sie können dann Sicherheits-, Governance- und Aufbewahrungsrichtlinien auf Protokolle auf Anwendungsebene anwenden, anstatt sie einzeln auf jede Funktion anzuwenden.

Mithilfe der AWS-Lambda-API, der AWS-Lambda-Konsole, der AWS CLI, des AWS Serverless Application Model (SAM) und AWS CloudFormation können Sie erweiterte Protokollierungskontrollen für Ihre Lambda-Funktionen angeben. Weitere Informationen finden Sie im Blogbeitrag zur Markteinführung mit erweiterten Protokollierungs-Steuerelementen oder im Lambda-Entwicklerhandbuch.

Ja, Sie können Ihre eigenen Protokollierungs-Bibliotheken verwenden, um Lambda-Protokolle im strukturierten JSON-Format zu generieren. Um sicherzustellen, dass Ihre Protokollierungs-Bibliotheken nahtlos mit der systemeigenen JSON-Protokollierungsfunktion von Lambda zusammenarbeiten, codiert Lambda keine von Ihrer Funktion generierten Protokolle, die bereits JSON-kodiert sind, doppelt. Sie können auch die Powertools für AWS-Lambda-Bibliothek verwenden, um Lambda-Protokolle im strukturierten JSON-Format zu erfassen.

Für die Verwendung erweiterter Protokollierungs-Steuerelemente auf Lambda fallen keine zusätzlichen Gebühren an. Die Erfassung und Speicherung Ihrer Lambda-Protokolle durch Amazon CloudWatch Logs wird Ihnen weiterhin in Rechnung gestellt. Preisinformationen finden Sie auf der Seite mit CloudWatch-Preisen.

CloudWatch Application Signals ist eine APM-Lösung (Application Performance Monitoring), mit der Entwickler und Betreiber auf einfache Weise den Zustand und die Leistung von Serverless-Anwendungen überwachen können, die mit Lambda erstellt wurden. Application Signals bietet vorgefertigte, standardisierte Dashboards für wichtige Anwendungsmetriken, korrelierte Traces und Interaktionen zwischen Lambda-Funktionen und ihren Abhängigkeiten – und das alles ohne manuelle Instrumentierung oder Codeänderungen durch Entwickler.

CloudWatch Logs Live Tail ist eine interaktive Funktion zum Streamen und zur Analytik von Protokollen in Echtzeit, was die Entwicklung und Fehlerbehebung von Lambda-Funktionen erleichtert. Dies ermöglicht es Entwicklern, Code- oder Konfigurationsänderungen schnell in Echtzeit zu testen und zu validieren, wodurch der Entwickeln-Testen-Bereitstellen-Zyklus (auch bekannt als „innere Entwicklungsschleife“) beim Erstellen von Anwendungen mit Lambda beschleunigt wird. Das Live-Tail-Erlebnis ermöglicht Betreibern und DevOps-Teams außerdem, Ausfälle und kritische Fehler im Lambda-Funktionscode effizienter zu erkennen und zu debuggen, wodurch die mittlere Wiederherstellungszeit (MTTR) bei der Behebung von Lambda-Funktionsfehlern reduziert wird.

Verwenden Sie durable Function von Lambda, wenn Sie Logik innerhalb des vertrauten Programmiermodells von Lambda mit lokalen Tests, IDE-Integration und Ihrer bevorzugten Programmiersprache erstellen möchten. Verwenden Sie AWS Step Functions, wenn Sie ein visuelles Workflow-Design, teamübergreifende Sichtbarkeit, über 220 native Service-Integrationen oder eine wartungsfreie Infrastruktur benötigen. Viele Anwendungen profitieren davon, beide zusammen zu verwenden.

Die AWS Lambda Durable Functions unterstützen derzeit JavaScript, TypeScript, Python und Java. Weitere Informationen zu unterstützten Laufzeiten.

Die aktuelle Verfügbarkeit in den Regionen finden Sie auf der Seite AWS-Funktionen nach Region.

Ja. Während das Timeout pro Aufruf 15 Minuten beträgt, können durable Functions von Lambda mithilfe von Wartefunktionen wie Timern, Rückrufe und Abfragebedingungen über mehrere Aufrufe hinweg unterbrochen und wieder aufgenommen werden. Wenn Sie durable functions asynchron aufrufen, kann sich das dauerhafte Ausführungs-Timeout auf bis zu einem Jahr erstrecken. Dies ermöglicht Anwendungsfälle wie Workflows zur Genehmigung durch Mitarbeiter, geplante Erinnerungen und mehrtägige Verarbeitungspipelines. Für On-Demand-Funktionen fallen während der Sperrung keine Rechengebühren an.

Das Ausführungs-Timeout (bis zu 1 Jahr) bestimmt, wie lange eine Ausführung ausgeführt werden kann. Die Aufbewahrungsfrist (bis zu 90 Tage) legt fest, wie lange Verlaufs- und Checkpoint-Daten aufbewahrt werden, nachdem die Ausführung einen Endzustand erreicht hat. Die Aufbewahrung wirkt sich nicht auf laufende Ausführungen aus. Siehe Konfiguration der durable Functions.

Nein. Bei On-Demand-Funktionen fallen bei Nutzung der Wartefunktionen des Durable Execution SDK während der Sperrung keine Rechenkosten an. Weitere Informationen finden Sie auf der Preisseite und im Entwicklerhandbuch.

Sie können jede Arbeitseinheit in einen Schritt mit automatischen Wiederholungsversuchen unterteilen. Wenn ein Schritt nach einem erneuten Versuch fehlschlägt, kann Ihr Handler-Code den Fehler abfangen und Ausgleichsschritte ausführen, z. B. die Rückerstattung einer Zahlung oder die Freigabe einer Reservierung. Da jeder abgeschlossene Schritt überprüft wird, einschließlich der Vergütungen, wird erfolgreich abgeschlossene Arbeit bei einem erneuten Versuch nicht wiederholt. Dieses Muster hilft Ihnen dabei, zuverlässige mehrstufige Prozesse wie Auftragsabwicklung oder Zahlungsabläufe zu erstellen, ohne benutzerdefinierte Wiederholungs- und Statusverfolgungslogik schreiben zu müssen.

Der Ausführungsstatus wird in einem vollständig verwalteten internen Statusspeicher gespeichert. Jeder Checkpoint-Ablauf, z. B. ein Schritt oder ein Rückruf, kann bis zu 256 KB an Daten speichern. Dieses Limit gilt für die vom Ablauf zurückgegebenen Daten. Daten, die innerhalb eines Ablaufs bearbeitet werden, wie z. B. das Lesen und Schreiben großer S3-Objekte, zählen nicht zu diesem Limit. Wenn ein Ablauf ein großes Ergebnis zurückgeben muss, können Sie benutzerdefinierte Serializer im SDK so konfigurieren, dass Nutzlasten an Amazon S3 oder Amazon DynamoDB ausgelagert werden und nur eine Referenz durch den Checkpoint geleitet wird.

Durable Functions von Lambda verwenden denselben Nebeläufigkeits-Pool auf Kontoebene wie Standard-Lambda-Funktionen. Während der Wartezeiten werden Nebenläufigkeits-Slots freigegeben, sodass Tausende von Ausführungen warten können, ohne die Nebenläufigkeit in Anspruch zu nehmen. Weitere Informationen zu AWS-Lambda-Quotas.

Sie können durable Functions lokal ohne AWS-Anmeldeinformationen testen, indem Sie das Durable Execution SDK für Ihre unterstützte Programmiersprache verwenden. AWS SAM CLI unterstützt auch lokale Aufrufe, Rückrufe und ein dauerhaftes Ausführungsmanagement, sodass die Entwicklung und das Debuggen vor der Bereitstellung unkompliziert sind. Weitere Informationen zum Testen von durable Functions.