AWS Lambda – Häufig gestellte Fragen

AWS Lambda kann zur Verbesserung der Leistung, anstatt eine neue Instance zu erstellen, eine Instance Ihrer Funktion beibehalten und zur Verarbeitung der nächsten Anforderung einsetzen. Weitere Informationen zur Wiederverwendung von Funktions-Instances durch Lambda finden Sie in der Dokumentation. Bei Ihrem Code sollte nicht davon ausgegangen werden, dass das immer passiert.

Sie können jede Lambda-Funktion mit ihrem eigenen flüchtigen Speicher zwischen 512 MB und 10.240 MB in 1-MB-Schritten konfigurieren. Der flüchtige Speicher ist im /tmp-Verzeichnis jeder Funktion verfügbar.

Jede Funktion hat ohne zusätzliche Kosten Zugriff auf 512 MB Speicherplatz. Wenn Sie Ihre Funktionen mit mehr als 512 MB flüchtigem Speicher konfigurieren, werden Ihnen Gebühren basierend auf der von Ihnen konfigurierten Speichermenge und der Ausführungsdauer Ihrer Funktion in 1-ms-Schritten berechnet. Zum Vergleich: In der Region USA Ost (Ohio) beträgt der Preis für flüchtigen Speicher von AWS Fargate 0,000111 USD pro GB-Stunde oder 0,08 USD pro GB-Monat. Die Preise für Amazon-EBS-gp3-Speichervolumen in USA Ost (Ohio) betragen 0,08 USD pro GB und Monat. Die Preise für flüchtigen Speicher von AWS Lambda betragen 0,0000000309 USD pro GB-Sekunde oder 0,000111 USD pro GB-Stunde und 0,08 USD pro GB-Monat. Weitere Informationen finden Sie unter Preise von AWS Lambda.

Sie können Erkenntnismetriken von AWS CloudWatch Lambda verwenden, um die Nutzung Ihres flüchtigen Speichers zu überwachen. Weitere Informationen finden Sie in der Dokumentation zu AWS CloudWatch Lambda Insights.

Wenn Ihre Anwendung dauerhaften, persistenten Speicher benötigt, sollten Sie die Verwendung von Amazon S3 oder Amazon EFS in Erwägung ziehen. Wenn Ihre Anwendung das Speichern von Daten erfordert, die von Code in einem einzigen Funktionsaufruf benötigt werden, sollten Sie die Verwendung von flüchtigem Speicher von AWS Lambda als vorübergehenden Cache in Betracht ziehen. Weitere Informationen finden Sie unter Auswählen von AWS-Lambda-Datenspeicheroptionen in Web-Apps.

Ja. Wenn Ihre Anwendung jedoch persistenten Speicher benötigt, sollten Sie die Verwendung von Amazon EFS oder Amazon S3 in Betracht ziehen. Wenn Sie bereitgestellte Nebenläufigkeit für Ihre Funktion aktivieren, wird der Initialisierungscode Ihrer Funktion während der Zuordnung und alle paar Stunden ausgeführt, da laufende Instances Ihrer Funktion wiederverwendet werden. Sie können die Initialisierungszeit in Protokollen und Traces sehen, nachdem eine Instance eine Anfrage verarbeitet hat. Die Initialisierung wird jedoch auch dann in Rechnung gestellt, wenn die Instance niemals eine Anfrage verarbeitet. Dieses Initialisierungsverhalten der bereitgestellten Nebenläufigkeit kann sich darauf auswirken, wie Ihre Funktion mit Daten interagiert, die Sie im flüchtigen Speicher speichern, selbst wenn Ihre Funktion keine Anforderungen verarbeitet. Um mehr über bereitgestellte Nebenläufigkeit zu erfahren, lesen Sie die entsprechende Dokumentation.

Sie können Erkenntnismetriken von AWS CloudWatch Lambda verwenden, um die Nutzung Ihres flüchtigen Speichers zu überwachen. Weitere Informationen finden Sie in der Dokumentation zu AWS CloudWatch Lambda Insights.

Wenn Sie Node.js oder Python verwenden, können Sie den Code mit dem Code-Editor in der AWS Lambda-Konsole selbst schreiben. Dort schreiben und testen Sie Ihre Funktionen und sehen die Ergebnisse der Funktionsausführung in einer robusten, IDE-ähnlichen Umgebung. Zum Starten die Konsole öffnen.

Sie können auch den Code (und alle abhängigen Bibliotheken) als ZIP-Datei packen und über die AWS Lambda-Konsole aus Ihrer lokalen Umgebung hochladen; oder Sie können einen Amazon S3-Ort angeben, an dem sich die ZIP-Datei befindet. Uploads dürfen höchstens 50 MB groß sein (komprimiert). Sie können das AWS Eclipse-Plug-in verwenden, um Lambda-Funktionen in Java zu schreiben und bereitzustellen. Sie können das Visual Studio-Plug-in verwenden, um Lambda-Funktionen in C# und Node.js zu schreiben und bereitzustellen.

Sie können den Code (und alle abhängigen Bibliotheken) als ZIP-Datei packen und über die AWS-Befehlszeilenschnittstelle aus Ihrer lokalen Umgebung hochladen; oder Sie können einen Amazon S3-Ort angeben, an dem sich die ZIP-Datei befindet. Uploads dürfen höchstens 50 MB groß sein (komprimiert). Informationen zum Einstieg finden Sie im Handbuch Erste Schritte mit Lambda.

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 Client-seitige Verschlüsselung mit AWS Key Management Service. Speichern Sie die daraus resultierenden Werte anschließend als Chiffriertext in Ihrer Umgebungsvariable. Zum Verschlüsseln dieser Werte müssen Sie in Ihren AWS Lambda-Funktionscode Logik einbeziehen.

Sie können die mit Ihrer Lambda-Funktion verknüpften Ressourcen mithilfe der Lambda-API oder -Konsole anpassen und sichern. Weitere Informationen dazu finden Sie in der Dokumentation.

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 Troubleshooting CloudWatch metrics. Für die in Lambda integrierten Kennzahlen werden die Standardgebühren für Lambda berechnet.

AWS Lambda wird automatisch in Amazon CloudWatch Logs integriert und erstellt eine Protokollgruppe für jede Lambda-Funktion. Außerdem werden grundlegende Protokolleinträge für Ereignisse des Anwendungslebenszyklus bereitgestellt, einschließlich Protokollierung der Ressourcen, die für die einzelnen Benutzungen dieser Funktion verbraucht wurden. Sie können auf einfache Art zusätzliche Protokollierungsanweisungen in Ihren Code einfügen. Sie können in Ihrer Lambda-Funktion auch Protokollierungs-APIs anderer Anbieter aufrufen. Weitere Informationen finden Sie in Troubleshooting Lambda functions. Es gelten die Gebühren für Amazon CloudWatch Logs.

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. Einzelheiten finden Sie auf der Seite mit der Preisübersicht zu 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 vergünstigte Preisstufen für die monatliche Dauer von On-Demand-Funktionen oberhalb bestimmter Schwellenwerte. Die Preisstaffelung gilt für Funktionen, die sowohl auf x86- als auch auf Arm-Architekturen laufen. Die Lambda-Preisstufen werden auf die kumulierte monatliche On-Demand-Dauer Ihrer Funktionen angewendet, die auf der gleichen Architektur (x86 bzw. Arm) in der gleichen Region innerhalb des Kontos ausgeführt werden. Wenn Sie die konsolidierte Abrechnung in AWS Organizations verwenden, werden die Preisstufen auf die gesamte monatliche Dauer Ihrer Funktionen angewendet, die auf derselben Architektur in derselben Region über die Konten in der Organisation laufen. Wenn Sie zum Beispiel x86-Lambda-Funktionen in der Region US-Ost (Ohio) ausführen, zahlen Sie für jede GB-Sekunde in den ersten 6 Milliarden GB-Sekunden pro Monat 0,0000166667 USD, für jede GB-Sekunde in den nächsten 9 Milliarden GB-Sekunden pro Monat 0,0000150000 USD und für jede GB-Sekunde über 15 Milliarden GB-Sekunden pro Monat 0,0000133334 USD in dieser Region. Die Preise für Anforderungen, bereitgestellte Gleichzeitigkeit und bereitgestellte Gleichzeitigkeitsdauer bleiben unverändert. Weitere Informationen finden Sie unter Preise für AWS Lambda.

Ja. Die Nutzung von Lambda, die durch Ihre Verpflichtung zu einem Stundensparplan abgedeckt ist, wird mit dem entsprechenden CSP-Tarif und Rabatt abgerechnet. Die verbleibende Nutzung, die nicht durch diese Verpflichtung abgedeckt ist, wird zu dem Tarif abgerechnet, der der Stufe entspricht, in die Ihre monatliche Gesamtnutzungsdauer fällt.

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

Ereignisse werden als Ereignis-Eingabeparameter an eine Lambda-Funktion weitergeleitet. Bei Ereignisquellen, wo Ereignisse in Stapeln ankommen, etwa Amazon SQS, Amazon Kinesis und Amazon DynamoDB Streams, kann der Ereignisparameter mehrere Ereignisse in einem einzigen Aufruf enthalten. Das ist abhängig von der Stapelgröße, die Sie anfordern. Mehr über Amazon-S3-Ereignis-Benachrichtigungen erfahren Sie unter Benachrichtigungen für Amazon-S3-Events konfigurieren. Weitere Informationen über Amazon DynamoDB Streams finden Sie im Entwicklerhandbuch zu DynamoDB Stream. Weitere Informationen über den Aufruf von Lambda-Funktionen mit Amazon SNS finden Sie im Entwicklerhandbuch zu Amazon SNS. Weitere Informationen zu Amazon Cognito-Ereignissen finden Sie unter Amazon Cognito. Weitere Informationen über AWS CloudTrail-Protokolle und die Prüfung von API-Aufrufen in AWS-Services finden Sie unter AWS CloudTrail.

Mit AWS Lambda können Sie zeitbasierte Aggregationen (z. B. count, max, sum, average usw.) über ein kurzes Fenster von bis zu 15 Minuten für Ihre Daten in Amazon Kinesis oder Amazon DynamoDB Streams durchführen, und zwar über eine einzelne logische Partition wie einen Shard. Dies gibt Ihnen die Möglichkeit, einfache Analysen für Ihre ereignisbasierte Anwendung einzurichten, ohne die Architektur zu verkomplizieren, da sich Ihre Geschäfts- und Analyselogik in derselben Funktion befinden kann. Lambda erlaubt Aggregationen über ein maximal 15-minütiges Tumbling-Fenster, basierend auf dem Zeitstempel des Ereignisses. Mit Amazon Kinesis Data Analytics können Sie komplexere Analyseanwendungen erstellen, die flexible Verarbeitungsoptionen und robuste Fehlertoleranz mit Exact-once-Verarbeitung ohne Duplikate sowie Analysen, die über einen gesamten Datenstrom über mehrere logische Partitionen hinweg durchgeführt werden können, unterstützen. Mit KDA können Sie Daten über mehrere Arten von Aggregationsfenstern (Tumbling Window, Stagger Window, Sliding Window, Session Window) analysieren, wobei entweder die Ereigniszeit oder die Verarbeitungszeit verwendet wird.
 

Konfigurieren Sie den Alarm zuerst so, dass er Amazon SNS-Benachrichtigungen versendet. Wählen Sie dann in der AWS Lambda-Konsole eine Lambda-Funktion und verknüpfen Sie sie mit einem Amazon SNS-Thema. Nähere Informationen zum Einrichten von Amazon CloudWatch-Alarmen finden Sie im Amazon CloudWatch-Entwicklerhandbuch.

In der AWS Lambda-Konsole können Sie eine Funktion auswählen, die ausgelöst wird, wenn ein Datensatz, der mit einem Identitäten-Pool von Amazon Cognito verknüpft ist, synchronisiert wird. Dieselbe Funktionalität ist auch über AWS SDK und die Befehlszeile verfügbar. Unter Amazon Cognito finden Sie weitere Informationen zum Verwenden von Amazon Cognito für das Freigeben und Synchronisieren von Daten auf Geräten der Benutzer.

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.

Laden Sie den Code hoch, den AWS Lambda ausführen soll, und rufen Sie ihn dann aus Ihrer mobilen App unter Verwendung des AWS Lambda SDK auf, das im AWS Mobile SDK enthalten ist. Sie können sowohl direkte (synchrone) Aufrufe zum Abrufen oder Prüfen von Daten machen als auch asynchrone Aufrufe. Sie können über Amazon API Gateway auch eine benutzerdefinierte API festlegen und Ihre Lambda-Funktionen über jeden mit REST kompatiblen Client aufrufen. Weitere Informationen zu AWS Mobile SDK finden Sie auf der Seite AWS Mobile SDK. Weitere Informationen zu Amazon API Gateway finden Sie auf der Seite Amazon API Gateway.

Mit AWS Serverless Application Repository können Sie aus verschiedenen serverlosen Anwendungen auswählen, die von Entwicklern, Unternehmen und Partnern in der AWS-Community veröffentlicht wurden. Wenn Sie die gewünschte Anwendung gefunden haben, können Sie sie direkt in der Lambda-Konsole konfigurieren und bereitstellen.

Der Veröffentlichungsprozess Ihrer serverlosen Anwendung wird mit AWS CodePipeline und AWS CodeDeploy automatisiert. CodePipeline ist ein Continuous Delivery-Service, mit dem Sie die verschiedenen Phasen der Veröffentlichung einer serverlosen Anwendung modellieren, visuell darstellen und automatisieren können. CodeDeploy ist eine Automatisierungs-Engine zur Bereitstellung Ihrer Anwendungen, die auf Lambda basieren. Mit CodeDeploy können Sie Bereitstellungen nach bewährten Methoden planen, etwa lineare Bereitstellungen und solche für einzelne Nutzer- oder Servergruppen. Außerdem können Sie die erforderlichen Schutzmechanismen einrichten, um zu bestätigen, dass der neu bereitgestellte Code sicher, stabil und bereit für die Produktion ist.
 

Weitere Informationen zu Serverless-CI/CD finden Sie in unserer Dokumentation.

Rufen Sie zunächst die AWS Lambda-Konsole auf, und laden Sie unsere Entwürfe herunter. Die heruntergeladene Datei enthält eine AWS SAM-Datei mit Definitionen der in Ihrer Anwendung enthaltenen AWS-Ressourcen und eine ZIP-Datei mit Ihrem Funktionscode. Sie können die soeben heruntergeladene serverlose Anwendung anschließend mithilfe von AWS CloudFormation-Befehlen verpacken und bereitstellen. Weitere Informationen finden Sie in unserer Dokumentation.

Sie können AWS Step Functions verwenden, um eine Serie von AWS Lambda-Funktionen in einer bestimmten Reihenfolge zu koordinieren. Dabei können Sie mehrere Lambda-Funktionen sequentiell aufrufen, sodass die Ausgabe von einer zur nächsten Funktion weitergegeben wird. Der Aufruf der Lambda-Funktionen ist auch parallel möglich, wobei Step Functions den Zustand während der Ausführungen für Sie beibehält.

Sie können die Lambda-Funktion für die Nachverfolgung mit AWS X-Ray aktivieren, indem Sie X-Ray-Berechtigungen zur Ausführungsrolle Ihrer Lambda-Funktion hinzufügen und den Nachverfolgungsmodus Ihrer Funktion auf "Active" festlegen. Wenn X-Ray für Ihre Lambda-Funktion aktiviert ist, sendet AWS Lambda Nachverfolgungsinformationen bezüglich des Aufwands des Lambda-Service, der beim Aufrufen Ihrer Funktion aufgetreten ist, an X-Ray. Auf diese Weise erhalten Sie Informationen, zum Beispiel zum Aufwand des Lambda-Service, zur Startzeit der Funktion und zur Ausführungszeit der Funktion. Außerdem können Sie das X-Ray-SDK in Ihr Lambda-Entwicklungspaket einschließen, um eigene Nachverfolgungssegmente zu erstellen, Ihre Nachverfolgungen zu kommentieren oder Nachverfolgungssegmente für Downstream-Aufrufe, die von Ihrer Lambda-Funktion aus erfolgt sind, anzuzeigen. X-Ray-SDKs sind derzeit für Node.js und Java verfügbar. Weitere Informationen finden Sie unter Problembehandlung für Lambda-basierte Anwendungen. Es gelten die Preise für AWS X-Ray.

Ja. Sie können hochskalierbare, sichere, Lambda-basierte, serverlose Anwendungen erstellen, die sich mit relationalen Datenbanken verbinden, indem Sie Amazon RDS Proxy verwenden, einen hochverfügbaren Datenbank-Proxy, der Tausende von gleichzeitigen Verbindungen zu relationalen Datenbanken verwaltet. Derzeit unterstützt RDS Proxy MySQL- und Aurora-Datenbanken. Sie können mit der Verwendung von RDS Proxy über die Amazon RDS-Konsole oder die AWS Lambda-Konsole beginnen. Serverlose Anwendungen, die vollständig verwaltete Verbindungspools von RDS Proxy verwenden, werden gemäß den RDS Proxy-Preisen berechnet.

Es handelt sich hierbei um eine Open-Source-Spezifikation unter Apache 2.0. Dies ermöglicht es Benutzern, AWS SAM mit einer gewerbefreundlichen Lizenz in Erstellungs-, Bereitstellungs-, Überwachungs- und Verwaltungstools zu integrieren. Das AWS SAM-Repository in GitHub können Sie hier aufrufen.

Es gibt drei Hauptunterschiede zwischen Funktionen, die mit ZIP-Archiven erstellt werden, und Container-Images:

1. Funktionen, die mit ZIP-Archiven erstellt werden, haben eine maximale Größe des Codepakets von 250 MB (ungezippt), und solche, die mit Container-Images erstellt werden, haben eine maximale Image-Größe von 10 GB. 
2. Lambda verwendet Amazon ECR als zugrundeliegenden Codespeicher für Funktionen, die als Container-Images definiert sind, so dass eine Funktion möglicherweise nicht mehr aufrufbar ist, wenn das zugrundeliegende Image aus ECR gelöscht wird. 
3. ZIP-Funktionen werden automatisch mit den neuesten Runtime-Sicherheits- und Fehlerbehebungen gepatcht. Als Container-Images definierte Funktionen sind unveränderlich und der Kunde ist für die in seiner Funktion verpackten Komponenten verantwortlich. Kunden können die von AWS bereitgestellten Basis-Images nutzen, die regelmäßig von AWS für Sicherheits- und Fehlerbehebungen aktualisiert werden, wobei die neuesten verfügbaren Patches verwendet werden.

Für die Paketierung und Bereitstellung von Funktionen als Container-Images für AWS Lambda fallen keine zusätzlichen Kosten an. Wenn Sie Ihre Funktion, die als Container-Image bereitgestellt wird, aufrufen, zahlen Sie den regulären Preis für Anfragen und Ausführungsdauer. Weitere Informationen finden Sie unter Preise von AWS Lambda. Die Speicherung Ihrer Container-Images in Amazon ECR wird Ihnen zu den üblichen ECR-Preisen berechnet. Weitere Informationen finden Sie unter Preise von Amazon ECR.

Der Lambda Runtime Interface Emulator ist ein Proxy für die Runtime-API von Lambda, der es Kunden ermöglicht, ihre als Container-Image verpackte Lambda-Funktion lokal zu testen. Es ist ein schlanker Web-Server, der HTTP-Anfragen in JSON-Ereignisse umwandelt und die Lambda-Runtime-API emuliert. Er ermöglicht Ihnen, Ihre Funktionen lokal zu testen, indem Sie vertraute Werkzeuge wie cURL und das Docker CLI (beim Testen von Funktionen, die als Container-Images verpackt sind) verwenden. Es vereinfacht auch die Ausführung Ihrer Anwendung auf zusätzlichen Rechendiensten. Sie können den Lambda Runtime Interface Emulator in Ihr Container-Image einbinden, damit er HTTP-Anfragen nativ anstelle der JSON-Ereignisse akzeptiert, die für die Bereitstellung an Lambda erforderlich sind. Diese Komponente emuliert weder den Lambda-Orchestrator noch die Sicherheits- und Authentifizierungskonfigurationen. Der Runtime Interface Emulator ist als Open Source auf GitHub verfügbar. Sie können damit beginnen, indem Sie ihn herunterladen und auf Ihrem lokalen Rechner installieren.

Kunden können den Runtime Interface Emulator als Einstiegspunkt in das Container-Image hinzufügen oder als Sidecar paketieren, um sicherzustellen, dass das Container-Image nun HTTP-Anfragen anstelle von JSON-Events annimmt. Dies vereinfacht die Änderungen, die erforderlich sind, um ihr Container-Image auf zusätzlichen Rechendiensten auszuführen. Kunden sind selbst dafür verantwortlich, dass sie alle Best Practices für Sicherheit, Leistung und Gleichzeitigkeit für ihre gewählte Umgebung befolgen. RIE ist in den bereitgestellten AWS-Lambda-Images vorinstalliert und standardmäßig in AWS SAM CLI verfügbar. Anbieter von Basis-Images können die Dokumentation verwenden, um die gleiche Erfahrung für ihre Basis-Images zu bieten.

Sie können eine containerisierte Anwendung in AWS Lambda bereitstellen, wenn sie die folgenden Anforderungen erfüllt:

1. Das Container-Image muss die Lambda-Runtime-API implementieren. Wir haben einen Satz Open-Source-Softwarepakete, Runtime Interface Clients (RIC), die die Lambda-Runtime-API implementieren, was es Ihnen ermöglicht, Ihre bevorzugten Basis-Images nahtlos so zu erweitern, dass Sie Lambda-kompatibel sind.
2. Das Container-Image muss auf einem schreibgeschützten Dateisystem laufen können. Ihr Funktionscode kann auf einen beschreibbaren /tmp-Verzeichnisspeicher von 512 MB zugreifen. Wenn Sie ein Image verwenden, das ein beschreibbares Stammverzeichnis erfordert, konfigurieren Sie es so, dass es in das Verzeichnis /tmp schreibt.
3. Die für die Ausführung von Funktionscode erforderlichen Dateien können vom Standard-Lambda-Benutzer gelesen werden. Lambda definiert einen Standard-Linux-Benutzer mit den geringsten Berechtigungen, der den bewährten Sicherheitsverfahren folgt. Sie müssen sicherstellen, dass Ihr Anwendungscode zur Ausführung nicht auf Dateien angewiesen ist, die von anderen Linux-Benutzern eingeschränkt werden.
4. Es handelt sich um ein Linux-basiertes Container-Image.

AWS 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 Softwareupdates wie Runtime-Upgrades und Sicherheitspatches darauf an.

Lambda SnapStart ist eine einfache Konfiguration auf Funktionsebene, die für neue und bestehende Funktionen mithilfe der Lambda-API, der AWS-Managementkonsole, der AWS Command Line Interface (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. Sie können Lambda SnapStart für Funktionen konfigurieren, die sowohl auf x86- und Arm-Architekturen ausgeführt werden.

Ja. Wenn Ihr Code von der Eindeutigkeit des Zustands ausgeht, müssen Sie die Widerstandsfähigkeit Ihres Codes gegenüber Snapshot-Operationen (wie z.B. Klonen und Wiederaufnehmen) bewerten. Wenn Sie mehr über Einzigartigkeitserwägungen mit Lambda SnapStart erfahren möchten, lesen Sie die Dokumentation und den Blog zum Verständnis von Einzigartigkeit in VM-Snapshots mit Lambda SnapStart.

Ja. Sie können Ihre eigene Softwarelogik vor der Erstellung (Checkpointing) eines Snapshots und nach der Wiederherstellung eines Snapshots mithilfe von Laufzeit-Hooks implementieren. Um mehr zu erfahren, lesen Sie die Lambda-SnapStart-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.

Wie bei allen Lambda-Funktionen fallen für SnapStart-Funktionen Dauergebühren an. Bei Funktionen, die SnapStart verwenden, umfasst die Dauer die Zeit, die zum Laden der Laufzeit benötigt wird, jeglichen Code, der in einem Runtime-Hook ausgeführt wird, und den Initialisierungscode, der beim Erstellen von Snapshot-Kopien aus Stabilitätsgründen ausgeführt wird.

Mit Lambda SnapStart für Python und .NET bleiben Ihre Funktions-Snapshots aktiv, solange Ihre Funktion aktiv ist. Bei Java-Funktionen läuft der mit einer veröffentlichten Funktionsversion verbundene Snapshot ab, wenn er länger als 14 Tage inaktiv bleibt.

Snapshots werden standardmäßig mit kundenindividuellen AWS-Key-Management-Service-Schlüsseln (KMS) verschlüsselt, die dem Lambda-Service gehören und von ihm verwaltet werden. Kunden können Snapshots auch mit einem KMS-Schlüssel verschlüsseln, der dem Kunden gehört und von ihm verwaltet wird.

Sie können die Parallelität 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 Provisioned Concurrency zu erfahren, lesen Sie die Dokumentation.

Provisioned Concurrency fügt eine Preisdimension der „bereitgestellten Parallelität“ 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 Provisioned Concurrency finden Sie unter AWS Lambda Preise.

Bei interpretierten Sprachen wie Python, Java und Node ist im Allgemeinen keine Neukompilierung erforderlich, es sei denn, Ihr Code verweist auf Bibliotheken, die architekturspezifische Komponenten verwenden. In diesen Fällen müssen Sie die Bibliotheken für arm64 bereitstellen. Weitere Informationen finden Sie auf der Seite Erste Schritte mit AWS Graviton. Bei nicht-interpretierten Sprachen muss der Code für arm64 kompiliert werden. Während modernere Compiler kompilierten Code für arm64 erzeugen, müssen Sie ihn zum Testen in einer arm-basierten Umgebung einsetzen. Um mehr über die Verwendung von Lambda-Funktionen mit Graviton2 zu erfahren, lesen Sie bitte die Dokumentation.

Zum Start können Kunden Python, Node.js, Java, Ruby, .Net Core, Custom Runtime (provided.al2) und OCI Base Images verwenden. Weitere Informationen finden Sie in den AWS-Lambda-Laufzeit.

Jede Workload ist einzigartig und wir empfehlen unseren Kunden, ihre Funktionen zu testen, um die mögliche Leistungsverbesserung zu ermitteln. Dazu empfehlen wir die Verwendung des AWS-Lambda-Power-Tuning-Tools. Wir empfehlen, mit Web- und Mobil-Backends, Daten und Stream Processing zu beginnen, wenn Sie Ihre Workloads auf potenzielle Leistungsverbesserungen testen.

Entwickler können ein bestehendes EFS-Dateisystem einfach mit einer Lambda-Funktion über einen EFS Access Point verbinden, indem Sie die Konsole, CLI oder SDK verwenden. Wenn die Funktion zum ersten Mal aufgerufen wird, wird das Dateisystem automatisch zugewiesen und für Funktionscode verfügbar gemacht. Weitere Informationen finden Sie in der Dokumentation.

Für die Nutzung von Amazon EFS for AWS Lambda fallen keine zusätzlichen Gebühren an. Kunden zahlen den Standardpreis für AWS Lambda und für Amazon EFS. Bei der Verwendung von Lambda und EFS in derselben Availability Zone wird Kunden die Datenübertragung nicht in Rechnung gestellt. Wenn VPC-Peering für kontenübergreifenden Zugriff genutzt wird, fallen Datenübertragungskosten an. Weitere Informationen finden Sie unter Preise.

Sie können eine Funktions-URL für Ihre Funktion über die AWS-Managementkonsole, die AWS-Lambda-API, die AWS CLI, AWS CloudFormation und das AWS Serverless Application Model konfigurieren. Funktions-URLs können auf die $LATEST unqualifizierte Version Ihrer Funktion oder auf jeden Funktionsalias aktiviert werden. Weitere Informationen zum Konfigurieren einer Funktions-URL finden Sie in der Dokumentation.

Ja. Sie können Lambda-Funktions-URLs auf einer Funktion oder einem Funktionsalias aktivieren. Wenn kein Alias angegeben wird, verweist die URL standardmäßig auf $LATEST. Funktions-URLs können nicht auf eine einzelne Funktionsversion abzielen.

Für die Nutzung von Funktions-URLs fallen keine zusätzlichen Gebühren an. Sie zahlen den Standardpreis für AWS Lambda. Weitere Informationen finden Sie unter Preise von AWS Lambda.

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 Einschränkungen des Lambda@Edge-Service 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 latenz-kritische 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.

Ihre Funktionen werden automatisch als Reaktion auf die folgenden Amazon CloudFront-Ereignisse ausgelöst:

• Viewer-Anforderung – Dieses Ereignis tritt ein, wenn ein Endbenutzer oder ein Gerät im Internet eine HTTP(S)-Anforderung an CloudFront richtet und die Anforderung am zum Benutzer nächstgelegenen Edge-Standort eintrifft.
• Viewer Response – Dieses Ereignis tritt ein, wenn der CloudFront-Server bei der Edge zur Antwort an den Endbenutzer oder das Gerät bereit ist, der bzw. das die Anforderung gesendet hat.
• Ursprungsanforderung – Dieses Ereignis tritt ein, wenn der CloudFront-Edge-Server das angeforderte Objekt noch nicht in seinem Cache abgelegt hat und die Viewer-Anforderung zum Versenden an Ihren Ursprungs-Webserver im Backend (z. B. Amazon EC2, Application Load Balancer oder Amazon S3) bereit ist.
• Ursprungsantwort – Dieses Ereignis tritt ein, wenn der CloudFront-Server an der Edge eine Antwort von Ihrem Ursprungs-Webserver im Backend erhält.

Der Unterschied besteht darin, dass API Gateway und Lambda regionale Services darstellen. Mit Lambda@Edge und Amazon CloudFront können Sie, je nachdem, an welchem Standort sich Ihre Viewer befinden, Ihre Logik über mehrere AWS-Standorte hinweg ausführen.

AWS Lambda ist für die parallele Ausführung vieler Instanzen 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 steuern, 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 Traffic 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 der Höchstgrenze 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 Gleichzeitigkeit 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 Parallelitätsskalierung 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 Setting up AWS Lambda.

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.

Code Signing 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. Code Signing 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 Code Signing 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 Developer Guide.

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 for 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.

Sie können Application Signals für Ihre Funktion mit einem einzigen Klick im Abschnitt „Überwachungs- und Betriebstools“ auf der Registerkarte Konfiguration in der Lambda-Konsole aktivieren. Nachdem Sie Application Signals aktiviert haben, können Sie in der CloudWatch-Konsole vorgefertigte Dashboards, Service Maps und mehr anzeigen und die Leistung und den Zustand Ihrer Serverless-Anwendungen analysieren. Weitere Informationen finden Sie im Lambda-Entwicklerhandbuch und im Entwicklerhandbuch für Application Signals. Besuchen Sie die CloudWatch-Preisseite, um mehr darüber zu erfahren, wie Ihnen die Nutzung von Application Signals mit Ihren Lambda-Funktionen in Rechnung gestellt wird.

CloudWatch Logs Live Tail ist eine interaktive Funktion zum Streamen und Analysieren 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.

Um Live Tail für Ihre Lambda-Funktion zu verwenden, besuchen Sie die Lambda-Konsole und klicken Sie im Code-Editor auf die Schaltfläche „CloudWatch Live Tail öffnen“. Weitere Informationen finden Sie im Lambda-Entwicklerhandbuch. Besuchen Sie die CloudWatch-Preisseite, um mehr darüber zu erfahren, wie Ihnen die Nutzung von Live Tail mit Ihren Lambda-Funktionen in Rechnung gestellt wird.

Sie können Standard-Tools wie Maven oder Gradle verwenden, um Ihre Lambda-Funktion zu kompilieren. Der Kompilierungsprozess muss denselben Kompilierungsprozess nachahmen, den Sie verwenden würden, um einen Java-Code zu kompilieren, der vom AWS SDK abhängt. Führen Sie Ihr Java-Kompilierungstool mit Ihren Quelldateien aus und schließen Sie das AWS SDK 1.9 oder höher mit transitiven Anhängigkeiten in Ihren Klassenpfad ein. Weitere Details finden Sie in unserer Dokumentation.

Ja. Sie können NPM-Pakete und benutzerdefinierte Pakete nutzen. Weitere Informationen hier.

Ja. In der in Lambda integrierten Sandbox können Sie Batch- oder Shell-Skripte, ausführbare Dateien in anderen Sprachen, Dienstprogrammroutinen und ausführbare Dateien ausführen. Weitere Informationen hier.

Ja. Der ZIP-Datei, die Sie hochladen, können sowohl statisch verknüpfte native Module als auch dynamisch verknüpfte Module hinzugefügt werden, die mit einem auf das Stammverzeichnis Ihrer Lambda-Funktion zeigenden "rpath" kompiliert werden. Weitere Informationen hier.

Ja. Sie können den Node.js-Befehl child_process verwenden, um eine Binärdatei auszuführen, die Sie in Ihre Funktion oder in eine ausführbare Datei aus Amazon Linux, die für Ihre Funktion sichtbar ist, einbezogen haben. Alternativ gibt es mehrere NPM-Pakete, die Binärdateien in der Befehlszeile mit einem Wrapper versehen, wie z. B. node-ffmpeg. Weitere Informationen hier.

Um eine Lambda-Funktion bereitzustellen, die in Node.js geschrieben wurde, packen Sie einfach Ihren Javascript-Code und die abhängigen Bibliotheken in eine ZIP-Datei. Sie können die ZIP-Datei aus Ihrer lokalen Umgebung hochladen oder einen Ort in Amazon S3 angeben, an dem sich die ZIP-Datei befindet. Weitere Details finden Sie in unserer Dokumentation.

Ein PowerShell Lambda-Bereitstellungspaket ist eine ZIP-Datei, die Ihr PowerShell-Skript, die für dieses Skript erforderlichen PowerShell-Module und die Komponenten beinhaltet, die für das Hosting von PowerShell Core erforderlich sind. Verwenden Sie dann das AWSLambdaPSCore PowerShell-Modul, das Sie aus dem PowerShell-Katalog installieren können, zum Erstellen Ihres PowerShell Lambda-Bereitstellungspakets.

Dazu laden Sie das ausführbare Go-Artefakt als ZIP-Datei über die AWS CLI oder die Lambda-Konsole hoch und wählen die Laufzeit go1.x aus. Mit Lambda können Sie die nativen Tools von Go zum Erstellen und Verpacken Ihres Codes verwenden. Weitere Informationen finden Sie in unserer Dokumentation. 

Sie können die Liste unterstützter Versionen hier einsehen.

Nein. AWS Lambda bietet eine Betriebssystem- und Managed Language Runtime-Version für alle Benutzer des Service. Sie können Ihre eigene Language Runtime mitbringen und in Lambda verwenden.

Zur Koordination des Aufrufs mehrerer Lambda-Funktionen können Sie Amazon Step Functions verwenden. Der Aufruf der Lambda-Funktionen kann dabei seriell erfolgen, sodass die Ausgabe einer Funktion an die nächste weitergegeben wird, oder er kann parallel erfolgen. Weitere Informationen finden Sie in unserer Dokumentation.