AWS Lambda – Häufig gestellte Fragen

Der Code, den Sie auf AWS Lambda ausführen, wird als „Lambda-Funktion“ hochgeladen. Jeder Funktion sind Konfigurationsinformationen zugeordnet, etwa der Name der Funktion, ihre Beschreibung, ihr Einstiegspunkt und ihre Ressourcenanforderungen. Der Code muss in einem „zustandslosen“ Stil geschrieben sein, also davon ausgehen, dass es keine Affinität zur zugrunde liegenden Infrastruktur gibt. Der lokale Zugriff auf das Dateisystem, untergeordnete Prozesse und ähnliche Elemente bestehen möglicherweise nicht über die Laufzeit der Anforderung hinaus. Jeder persistente Zustand sollte in Amazon S3, Amazon DynamoDB, Amazon EFS oder einem anderen im Internet verfügbaren Speicherservice gespeichert werden. Lambda-Funktionen können Bibliotheken enthalten, auch native.

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 jede Lambda-Funktion mit ihrem eigenen flüchtigen Speicher zwischen 512 MB und 10.240 MB in 1-MB-Schritten konfigurieren, indem Sie während der Funktionserstellung oder -aktualisierung die AWS-Lambda-Konsole, die AWS-Lambda-API oder die AWS-CloudFormation-Vorlage verwenden.

Ja. Alle im flüchtigen Speicher gespeicherten Daten werden im Ruhezustand mit einem von AWS verwalteten Schlüssel verschlüsselt.

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 jede Lambda-Funktion mit ihrem eigenen flüchtigen Speicher zwischen 512 MB und 10.240 MB in 1-MB-Schritten konfigurieren, indem Sie während der Funktionserstellung oder -aktualisierung die AWS-Lambda-Konsole, die AWS-Lambda-API oder die AWS-CloudFormation-Vorlage verwenden.

Ja. Alle im flüchtigen Speicher gespeicherten Daten werden im Ruhezustand mit einem von AWS verwalteten Schlüssel verschlüsselt.

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.

Werden Funktionen zustandslos gehalten, so kann AWS Lambda rasch so viele Kopien der Funktionen starten, wie entsprechend der Häufigkeit der eingehenden Ereignisse zum Skalieren benötigt werden. Obwohl das AWS Lambda-Programmiermodell zustandslos ist, kann Ihr Code auf zustandsbehaftete Daten zugreifen, indem er andere Web-Services aufruft, etwa Amazon S3 oder Amazon DynamoDB.

Ja. Mit AWS Lambda können Sie normalsprachliche und Betriebssystem-Funktionen verwenden, etwa zusätzliche Threads und Prozesse erstellen. Der Lambda-Funktion zugewiesene Ressourcen – einschließlich Arbeitsspeicher, Ausführungszeit, Datenträger und Netzwerknutzung – werden von allen Threads/Prozessen gemeinsam genutzt. Sie können Prozesse mit jeder Sprache starten, die durch Amazon Linux unterstützt wird.

Lambda versucht, normalsprachliche und Betriebssystemaktivitäten möglichst geringfügig einzuschränken, einige Aktivitäten sind jedoch deaktiviert: Eingehende Netzwerkverbindungen werden durch AWS Lambda blockiert, es werden für ausgehende Verbindungen nur TCP/IP- und UDP/IP-Sockets unterstützt, und ptrace-Systemaufrufe (Debugging) werden blockiert. Als Maßnahme gegen Spam wird auch Datenverkehr über TCP-Port 25 blockiert.

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.

Sie müssen Ihre Lambda-Funktionen nicht skalieren – AWS Lambda erledigt das automatisch für Sie. Jedes Mal, wenn eine Ereignisbenachrichtigung für Ihre Funktion empfangen wird, lokalisiert AWS Lambda rasch freie Kapazitäten in seiner Datenverarbeitungsflotte und führt Ihren Code aus. Da Ihr Code zustandslos ist, kann AWS Lambda ohne zeitaufwendige Bereitstellung und Konfiguration so viele Kopien Ihrer Funktion starten, wie benötigt werden. Es gibt keine grundsätzliche Beschränkung für die Skalierung einer Funktion. AWS Lambda weist entsprechend der Häufigkeit der eingehenden Ereignisse Kapazitäten dynamisch zu.

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.

Kunden, die speicher- oder rechenintensive Workloads ausführen, können jetzt mehr Speicher für ihre Funktionen verwenden. Größere Speicherfunktionen tragen dazu bei, dass Multithreading-Anwendungen schneller ausgeführt werden, was sie ideal für daten- und rechenintensive Anwendungen wie Machine Learning, Batch- und ETL-Aufgaben, Finanzmodellierung, Genomik, HPC und Medienverarbeitung macht.

AWS Lambda-Funktionen können so konfiguriert werden, dass sie pro Ausführung bis zu 15 Minuten ausgeführt werden. Sie können die Terminierung auf einen Wert zwischen 1 Sekunde und 15 Minuten festlegen.

Bei AWS Lambda wird nur die tatsächliche Nutzung berechnet. Einzelheiten finden Sie auf der Seite mit der Preisübersicht zu AWS Lambda.

Ja. Zusätzlich zu Einsparnissen mit Amazon EC2 und AWS Fargate, können Sie mit einem Compute Savings Plans Geld bei AWS Lambda sparen. Compute Savings Plans bieten bis zu 17 % Rabatt auf Dauer und Provisioned Concurrency. Compute Savings Plans beten keinen Rabatt auf Anfragen auf Ihrer Lambda-Rechnung. Aber Ihre Compute Savings Plans können auf Anfragen zu gewöhnlichen Raten angewandt werden.

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.

Die Bereitstellungszeiten können je nach Codegröße variieren, AWS Lambda-Funktionen sind jedoch normalerweise innerhalb von Sekunden nach dem Hochladen bereit.

Ja. Sie können Ihre eigene Bibliothek (einschließlich des AWS SDK) einbeziehen, um eine andere Version als die von AWS Lambda bereitgestellte Standardversion zu verwenden.

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 Ereignisquelle ist eine AWS-Service- oder von Entwicklern erstellte Anwendung, die Ereignisse produziert, die die Ausführung einer AWS Lambda-Funktion auslösen. Manche Services veröffentlichen diese Ereignisse für Lambda, indem sie die Cloud-Funktion direkt aufrufen (beispielsweise Amazon S3). Lambda kann auch Ressourcen in anderen Services abrufen, die keine Ereignisse für Lambda veröffentlichen. Lambda kann beispielsweise Datensätze aus einem Amazon Kinesis-Stream oder einer Amazon-SQS-Warteschlange abrufen und für jede abgerufene Nachricht eine Lambda-Funktion ausführen. Viele andere Services, wie AWS CloudTrail, können als Ereignisquellen fungieren, indem sie sich einfach bei Amazon S3 anmelden und S3-Bucket-Benachrichtigungen verwenden, um AWS-Lambda-Funktionen auszulösen.

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.

In der AWS Lambda-Konsole können Sie eine Funktion auswählen und ihr Benachrichtigungen aus einem Amazon S3-Bucket zuordnen. Alternativ können Sie die Amazon S3-Konsole verwenden und die Bucket-Benachrichtigungen konfigurieren, die an Ihre AWS Lambda-Funktion gesendet werden sollen. Dieselbe Funktionalität ist auch über AWS SDK und die Befehlszeile verfügbar.

Sie können eine Lambda-Funktion auf DynamoDB-Tabellen-Updates auslösen, indem Sie den der Tabelle zugeordneten DynamoDB-Stream für Ihre Lambda-Funktion abonnieren. Sie können einem DynamoDB-Stream über die Amazon DynamoDB-Konsole, die AWS Lambda-Konsole oder die registerEventSource-API eine Lambda-Funktion zuordnen.

Auf der AWS Lambda-Konsole können Sie eine Lambda-Funktion wählen und sie mit einem Amazon Kinesis-Stream verknüpfen, der im Eigentum desselben Kontos ist. Dieselbe Funktionalität ist auch über AWS SDK und die Befehlszeile verfügbar.

Die an Ihre AWS Lambda-Funktion gesendeten Datensätze aus Amazon Kinesis- und DynamoDB-Streams werden nach Shards streng serialisiert. Wenn Sie also zwei Datensätze in demselben Shard ablegen, sorgt Lambda dafür, dass Ihre Lambda-Funktion korrekt beim ersten Datensatz aufgerufen wird, bevor sie beim zweiten Datensatz aufgerufen wird. Tritt beim Aufruf für einen Datensatz eine Zeitüberschreitung, Drosselung oder ein anderer Fehler auf, versucht Lambda den Vorgang so oft zu wiederholen, bis er korrekt ausgeführt wird (oder bis der Datensatz nach 24 Stunden abläuft), bevor die Funktion zum zweiten Datensatz fortschreitet. Die Anordnung von Datensätzen über verschiedene Shards hinweg wird nicht gewährleistet, und die Verarbeitung der einzelnen Shards erfolgt parallel.

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.
 

	AWS Lambda	Amazon KDA
Tumbling Window	Ja	Ja
Stagger Window	Nein	Ja
Sliding Window	Nein	Ja
Session Window	Nein	Ja
Datenanreicherung	Nein	Ja
Gemeinsame Eingabe- und Referenztabellen	Nein	Ja
Geteilter Eingabe-Stream	Nein	Ja
Exactly-once-Verarbeitung	Nein	Ja
Maximales Zeitfenster	15 Min.	Kein Limit
Aggregationsumfang	Partition/Shard	Stream
Zeitsemantik	Ereigniszeit	Ereigniszeit, Verarbeitungszeit

In der AWS Lambda-Konsole können Sie eine Lambda-Funktion auswählen und sie mit einem Amazon SNS-Thema verknüpfen. Dieselbe Funktionalität ist auch über AWS SDK und die Befehlszeile verfügbar.

Von der Amazon SES-Konsole aus können Sie Ihre Empfangsregel einrichten, damit Amazon SES Ihre Nachrichten an eine AWS Lambda-Funktion liefert. Derselbe Funktionsumfang ist auch über AWS SDK und CLI verfügbar.

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.

AWS Lambda ist so konzipiert, dass es Ereignisse in Millisekunden verarbeitet. Gleich nachdem eine Lambda-Funktion erstellt oder aktualisiert wurde, und wenn sie in letzter Zeit nicht verwendet wurde, ist die Latenz größer.

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.

Sie können eine Lambda-Funktion über HTTPS abrufen, indem Sie mit Amazon API Gateway eine benutzerdefinierte RESTful API definieren. So erhalten Sie einen Endpunkt für Ihre Funktion, der REST-Aufrufe wie GET, PUT und POST beantworten kann. Erfahren Sie mehr über AWS Lambda mit Amazon API Gateway.

Wenn AWS Lambda-Funktionen über das AWS Mobile SDK aufgerufen werden, erhalten sie über das „context“-Objekt automatisch Einblick in das Gerät und die Anwendung, von denen der Aufruf stammt.

Wenn Ihre App Amazon Cognito-Identitäten verwendet, können Benutzer sich authentifizieren, indem sie einen öffentlichen Anmeldungsanbieter wie Amazon, Facebook, Google oder einen anderen mit OpenID Connect kompatiblen Service verwenden. Die Benutzeridentität wird Ihrer Lambda-Funktion dann automatisch und sicher in Form einer Amazon Cognito-ID präsentiert und erlaubt es der Funktion, aus Amazon Cognito auf Benutzerdaten zuzugreifen oder die ID als Schlüssel zum Speichern und Abrufen von Daten aus Amazon DynamoDB oder anderen Web-Services zu verwenden.

AWS Lambda ist in das Alexa Skills Kit integriert, eine Sammlung von Selbstbedienungs-APIs, Tools, Dokumentationen und Codebeispielen, die Ihnen die Erstellung von Funktionen mit Sprachsteuerung (sogenannte "Skills") für Alexa erleichtern. Sie laden einfach den Lambda-Funktionscode für die neue Alexa-Skill hoch, die Sie erstellen möchten, und AWS Lambda übernimmt den Rest. Der Code wird als Antwort auf Interaktionen mit Alexa-Sprachsteuerung ausgeführt und die Computerressourcen werden automatisch für Sie verwaltet. Weitere Informationen finden Sie in der Alexa Skills Kit-Dokumentation.

Bei Amazon S3-Bucket-Benachrichtigungen und benutzerdefinierten Ereignissen versucht AWS Lambda bei einer Fehlerbedingung in Ihrem Code, oder wenn Sie eine Service- oder Ressourcenbeschränkung überschreiten, dreimal, Ihre Funktion auszuführen. Bei bestellten Ereignisquellen, die AWS Lambda für Sie abruft – etwa Amazon DynamoDB Streams und Amazon Kinesis Streams –, versucht Lambda bei einem Entwickler-Codefehler so lange die Ausführung, bis die Daten ablaufen. Sie können den Fortschritt über die Konsolen von Amazon Kinesis und Amazon DynamoDB, sowie die Amazon CloudWatch-Metriken überwachen, die AWS Lambda für Ihre Funktion erstellt. Sie können auch auf Fehlerraten oder auf der Ausführungsdrosselung basierende Amazon CloudWatch-Warnungen erstellen.

Lambda-basierte Anwendungen (die auch als serverlose Anwendungen bezeichnet werden) bestehen aus Funktionen, die durch Ereignisse ausgelöst werden. Eine typische serverlose Anwendung besteht aus einer oder mehreren Funktionen, deren Auslösung durch Ereignisse wie Objekt-Uploads in Amazon S3, Amazon SNS-Benachrichtigungen oder API-Aktionen erfolgt. Die Funktionen können eigenständig verwendet werden oder andere Ressourcen wie DynamoDB-Tabellen oder Amazon S3-Buckets nutzen. Die grundlegendeste serverlose Anwendung ist einfach eine Funktion.

Zum Bereitstellen und Verwalten Ihrer serverlosen Anwendungen können Sie das AWS Serverless Application Model (AWS SAM) verwenden. AWS SAM ist eine Spezifikation, welche die Regeln für serverlose Anwendungen in AWS vorschreibt. Diese Spezifikation ist auf die aktuell von AWS CloudFormation verwendete Syntax ausgerichtet und wird in AWS CloudFormation nativ als ein Satz von Ressourcentypen unterstützt (die als „serverlose Ressourcen“ bezeichnet werden). Diese Ressourcen erleichtern AWS-Kunden die Verwendung von CloudFormation, um Serverless-Anwendungen mithilfe von bestehenden CloudFormation-APIs zu konfigurieren und bereitzustellen.

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.

Mit AWS Lambda können Sie jetzt Funktionen als Container-Images verpacken und bereitstellen. Kunden können die Flexibilität und Vertrautheit von Container-Tools sowie die Agilität und betriebliche Einfachheit von AWS Lambda nutzen, um Anwendungen zu erstellen.

Sie können entweder mit einem von AWS bereitgestellten Basis-Image für Lambda beginnen oder eines Ihrer bevorzugten Community- oder privaten Enterprise-Images verwenden. Verwenden Sie dann einfach Docker CLI, um das Image zu erstellen, laden Sie es in Amazon ECR hoch und erstellen Sie dann die Funktion mit allen bekannten Lambda-Schnittstellen und -Tools, wie der AWS-Managementkonsole, der AWS CLI, dem AWS SDK, AWS SAM und AWS CloudFormation.

Sie können Linux-Basis-Images von Drittanbietern (z. B. Alpine oder Debian) zusätzlich zu den von Lambda bereitgestellten Images auf Lambda bereitstellen. AWS Lambda unterstützt alle Bilder, die auf den folgenden Bildmanifest-Formaten basieren: Docker Image Manifest V2 Schema 2 (verwendet mit Docker Version 1.10 und neuer) oder Open Container Initiative (OCI) Spec (v1.0 und höher). Lambda unterstützt Images mit einer Größe von bis zu 10 GB.

AWS Lambda bietet eine Vielzahl von Basis-Images, die Kunden erweitern können. Kunden können auch ihre bevorzugten Linux-basierten Images mit einer Größe von bis zu 10 GB verwenden.

Sie können jedes Container-Tooling verwenden, solange es eines der folgenden Container-Image-Manifestformate unterstützt: Docker Image Manifest V2 Schema 2 (verwendet mit Docker Version 1.10 und neuer) oder Open Container Initiative (OCI) Specifications (v1.0 und höher). Sie können zum Beispiel native Container-Tools (d. h. Docker Run, Docker Compose, Buildah und Packer) verwenden, um Ihre Funktionen als Container-Image zu definieren und an Lambda zu verteilen.

Alle bestehenden AWS-Lambda-Funktionen, mit Ausnahme von Lambda-Ebenen und Code Signing, können mit Funktionen verwendet werden, die als Container-Images bereitgestellt werden. Nach der Bereitstellung wird ein Image von AWS Lambda als unveränderlich behandelt. Kunden können Containerschichten während ihres Build-Prozesses verwenden, um Abhängigkeiten einzubinden.

Nein, derzeit nicht. Ihr Image ist nach der Bereitstellung in AWS Lambda unveränderlich. Der Dienst wird das Image nicht patchen oder aktualisieren. AWS Lambda veröffentlicht jedoch kuratierte Basis-Images für alle unterstützten Runtimes, die auf der verwalteten Lambda-Umgebung basieren. Diese veröffentlichten Images werden zusammen mit den Updates für die verwalteten AWS-Lambda-Laufzeiten gepatcht und aktualisiert. Sie können das neueste Basis-Image von DockerHub oder Amazon ECR Public ziehen und verwenden, Ihr Container-Image neu erstellen und über Amazon ECR in AWS Lambda bereitstellen. So können Sie die aktualisierten Images und Laufzeiten erstellen und testen, bevor Sie das Image in der Produktion einsetzen.

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.

Nein – AWS Lambda stellt sicher, dass die Leistungsprofile für Funktionen, die als Container-Images verpackt sind, die gleichen sind wie für solche, die als ZIP-Archive verpackt sind, einschließlich typischer Startzeiten von weniger als einer Sekunde.

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.

Die Lambda-Runtime-API im laufenden Lambda-Dienst nimmt JSON-Ereignisse an und gibt Antworten zurück. Der Lambda Runtime Interface Emulator ermöglicht es der als Container-Image verpackten Funktion, beim lokalen Testen mit Werkzeugen wie cURL HTTP-Anfragen anzunehmen und diese über die gleiche Schnittstelle lokal an die Funktion zu stellen. Er ermöglicht Ihnen, den Befehl „docker run“ oder „docker-compose up“ zu verwenden, um Ihre Lambda-Anwendung lokal zu testen.

Sie können den Emulator verwenden, um zu testen, ob Ihr Funktionscode mit der Lambda-Umgebung kompatibel ist, erfolgreich ausgeführt wird und die erwartete Ausgabe liefert. Zum Beispiel können Sie Test-Ereignisse aus verschiedenen Ereignisquellen nachbilden. Sie können ihn auch verwenden, um in das Container-Image eingebaute Erweiterungen und Agenten gegen die Lambda Extensions API zu testen.

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 Lambda SnapStart für Java liefert bis zu zehnmal schnellere Startzeiten für Funktionen. Bei On-Demand-Funktionen trägt die Initialisierungsphase (in der AWS Lambda den Code der Funktion lädt und externe Abhängigkeiten initialisiert) am meisten zur Startlatenz bei und erfolgt beim ersten Aufruf. Mit Lambda SnapStart initialisiert Lambda den Funktionscode für die einmalige Initialisierung bereits im Voraus, wenn Sie eine Funktionsversion veröffentlichen, anstatt erst, wenn Sie die Funktion zum ersten Mal aufrufen. Anschließend erstellt Lambda einen Snapshot und speichert den Speicher- und Festplattenstatus der initialisierten Ausführungsumgebung. Wenn Sie die Funktion aufrufen – und wenn sie sich vergrößert – setzt Lambda die Funktion aus dem zwischengespeicherten Snapshot fort, anstatt die Funktion von Grund auf neu zu initialisieren.

Lambda SnapStart ist eine einfache Konfiguration auf Funktionsebene, die für neue und bestehende Java-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 Java-Funktionen zu einer bis zu 10-fach schnelleren Startzeit verhilft, indem sie die variable Latenz, die bei der Ausführung von einmaligem Initialisierungscode entsteht, reduziert. Lambda SnapStart funktioniert im Großen und Ganzen für alle Funktionen in Ihrer Anwendung oder Ihrem Konto, ohne zusätzliche Kosten. Wenn ein Kunde eine Funktionsversion mit Lambda SnapStart veröffentlicht, wird der Code der Funktion im Voraus initialisiert, anstatt erst beim ersten Aufruf initialisiert zu werden. Lambda erstellt dann einen Schnappschuss der initialisierten Ausführungsumgebung und speichert ihn in einem mehrstufigen Cache für den Zugriff mit geringer Latenz. Wenn die Funktion zum ersten Mal aufgerufen und dann skaliert wird, setzt Lambda die Funktion aus dem zwischengespeicherten Snapshot fort, anstatt sie von Grund auf neu zu initialisieren, was zu einer geringeren Startlatenz führt. 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 die Java-11-Laufzeit. Zukünftige Versionen von Java werden unterstützt, sobald sie veröffentlicht werden. Alle von Lambda unterstützten Laufzeiten finden Sie in der Dokumentation der Lambda-Laufzeiten.

Nein. Lambda SnapStart und PC können nicht gleichzeitig für dieselbe Funktion aktiviert werden.

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.

Nein. Sie können Lambda SnapStart derzeit nur für Funktionen konfigurieren, die auf der x86-Architektur laufen.

Nein. Sie können Lambda SnapStart derzeit nicht mit Amazon EFS aktivieren.

Nein. Sie können Lambda SnapStart derzeit nicht mit einem größeren ephemeren Speicher (/tmp) als 512 MB aktivieren.

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.

Nein. Es fallen keine zusätzlichen Kosten für die Aktivierung von Lambda SnapStart an. Die Kosten richten sich nach der Anzahl der Anfragen für Ihre Funktionen und der Dauer der Ausführung Ihres Codes, basierend auf den aktuellen Lambda-Preisen. Gebühren für die Dauer gelten sowohl für Code, der im Handler einer Funktion und eines Laufzeit-Hooks läuft, als auch für Initialisierungscode, der außerhalb des Handlers deklariert wird. Bitte beachten Sie, dass AWS Lambda in regelmäßigen Abständen Ausführungsumgebungen mit Sicherheitspatches recycelt und Ihren Initialisierungscode erneut ausführt. Weitere Informationen finden Sie in der Dokumentation zum Lambda-Programmiermodell.

Mit Lambda SnapStart behält Lambda einen Snapshot der initialisierten Ausführungsumgebung für die letzten drei veröffentlichten Funktionsversionen, solange die veröffentlichten Versionen weiterhin Aufrufe erhalten. Der mit einer veröffentlichten Funktionsversion verbundene Snapshot läuft 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.

Die maximal zulässige Initialisierungsdauer für Lambda SnapStart entspricht der Ausführungszeitdauer, die Sie für Ihre Funktion konfiguriert haben. Das maximal konfigurierbare Zeitlimit für die Ausführung einer Funktion beträgt 15 Minuten.

Provisioned Concurrency gibt Ihnen mehr Kontrolle über die Leistung Ihrer serverlosen Anwendungen. Wenn aktiviert, hält Provisioned Concurrency die Funktionen initialisiert und hyperbereit, um in zweistelligen Millisekunden zu reagieren.

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.

Sie müssen keine Änderungen an Ihrem Code vornehmen, um Provisioned Concurrency zu verwenden. Es arbeitet nahtlos mit allen vorhandenen Funktionen und Laufzeiten zusammen. Es gibt keine Änderung am Aufruf- und Ausführungsmodell von Lambda bei der Verwendung von Provisioned Concurrency.

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.

Provisioned Concurrency ist ideal für die Entwicklung latenzempfindlicher Anwendungen, wie Web- oder mobile Backends, synchron aufgerufene APIs und interaktive Mikroservices. Sie können die entsprechende Menge an Parallelität einfach konfigurieren, basierend auf den individuellen Anforderungen Ihrer Anwendung. Sie können den Betrag der Parallelität in Zeiten hoher Nachfrage erhöhen und senken oder bei sinkender Nachfrage ganz abschalten.

Wenn die Parallelität einer Funktion die konfigurierte Ebene erreicht, haben nachfolgende Aufrufe der Funktion die Latenz- und Skaleneigenschaften regulärer Lambda-Funktionen. Sie können Ihre Funktion darauf beschränken, nur bis zur konfigurierten Ebene zu skalieren. Dadurch wird verhindert, dass die Funktion die konfigurierte Ebene der Provisioned Concurrency überschreitet. Dies ist ein Mechanismus, um unerwünschte Schwankungen in Ihrer Anwendung zu vermeiden, wenn die Nachfrage den erwarteten Betrag übersteigt.

Mit AWS Lambda können Sie Ihre Funktionen entweder auf x86-basierten oder Arm-basierten Prozessoren ausführen. AWS Graviton2-Prozessoren werden von Amazon Web Services unter Verwendung von 64-Bit-Arm-Neoverse-Kernen entwickelt, um eine höhere Preisleistung für Ihre Cloud-Workloads zu erzielen. Kunden erhalten die gleichen Vorteile von AWS Lambda: Ausführung von Code ohne Bereitstellung oder Verwaltung von Servern, automatische Skalierung, hohe Verfügbarkeit und Bezahlung nur für die verbrauchten Ressourcen.

AWS-Lambda-Funktionen, die von Graviton2 unterstützt werden und eine von AWS entwickelte Arm-basierte Prozessorarchitektur verwenden, sollen eine bis zu 34 % bessere Preisleistung im Vergleich zu Funktionen bieten, die auf x86-Prozessoren ausgeführt werden, und zwar für eine Vielzahl von serverlosen Arbeitslasten wie Web- und mobile Backends, Daten und Stream-Verarbeitung. Mit geringerer Latenz, bis zu 19 % besserer Leistung, 20 % niedrigeren Kosten und der höchsten derzeit bei AWS verfügbaren Energieeffizienz können Graviton2-Funktionen geschäftskritische serverlose Anwendungen betreiben. Kunden können sowohl bestehende als auch neue Funktionen für den Graviton2-Prozessor konfigurieren. Sie können Funktionen, die auf Graviton2 laufen, entweder als Zip-Dateien oder Container-Images bereitstellen.

Sie können Funktionen für die Ausführung auf Graviton2 über die AWS Management Console, die AWS Lambda API, die AWS CLI und AWS CloudFormation konfigurieren, indem Sie das Architektur-Flag für Ihre Funktion auf "arm64" setzen.

Es gibt keinen Unterschied zwischen x86-basierten und Arm-basierten Funktionen. Laden Sie Ihren Code einfach über die AWS Management Console, eine Zip-Datei oder ein Container-Image hoch und AWS Lambda führt Ihren Code bei Auslösung automatisch aus, ohne dass Sie die Infrastruktur bereitstellen oder verwalten müssen.

Eine Anwendung kann Funktionen enthalten, die auf beiden Architekturen laufen. Mit AWS Lambda können Sie die Architektur ("x86_64" oder "arm64") der aktuellen Version Ihrer Funktion ändern. Sobald Sie eine bestimmte Version Ihrer Funktion erstellt haben, kann die Architektur nicht mehr geändert werden.

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.

Nein. Jede Funktionsversion kann nur ein einziges Container-Image verwenden.

Ja. Schichten und Erweiterungen können auf "x86_64"- oder "arm64"-kompatible Architekturen ausgerichtet werden. Die Standardarchitektur für Funktionen und Schichten ist "x86_64".

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.

AWS-Lambda-Funktionen, die powered by AWS-Graviton2-Prozessoren sind, sind im Vergleich zu x86-basierten Lambda-Funktionen 20 % günstiger. Das kostenlose Lambda-Kontingent für AWS-Lambda-Funktionen, die von x86- und Arm-basierten Architekturen betrieben werden.

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.

Mit Amazon Elastic File System (Amazon EFS) for AWS Lambda können Kunden große Mengen an Daten bei praktisch beliebiger Skalierung mithilfe von einem vollständig verwalteten und elastischen NFS-Dateisystem sicher lesen, schreiben und dauerhaft speichern. Dieses Dateisystem lässt sich nach Bedarf und ohne Bereitstellung oder Kapazitätsmanagement skalieren. Bisher haben Entwickler Code zu den Funktionen hinzugefügt, um Daten von S3 oder Datenbanken auf einen lokalen, temporären Speicher auf 512 MB begrenzt herunterzuladen. Mit EFS for Lambda müssen Entwickler keinen Code schreiben, um Daten in den temporären Speicher herunterzuladen, um sie zu verarbeiten.

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.

Ja. Mount-Ziele für Amazon EFS werden mit einem Subnetz in einer VPC verbunden. Die AWS Lambda-Funktion muss für den Zugriff auf diese VPC konfiguriert werden.

Die Nutzung von EFS for Lambda eignet sich ideal für die Entwicklung von Machine-Learning-Anwendungen oder zum Laden von großen Referenzdateien oder -modellen, zum Verarbeiten oder sichern großer Mengen an Daten, zum Hosten von Webinhalten oder zur Weiterentwicklung von internen Build-Systemen. Kunden können auch EFS for Lambda verwenden, um den Zustand zwischen Aufrufen innerhalb einer zustandsbehafteten Microservice-Architektur oder in einem StepFunctions-Workflow beizubehalten oder Dateien zwischen serverlosen Anwendungen und instance- oder containerbasierten Anwendungen freizugeben.

Ja. Für die Verschlüsselung der Daten während der Übertragung wird der Branchenstandard Transport Layer Security (TLS) 1.2 für die zwischen AWS Lambda-Funktionen und Amazon EFS-Dateisystemen übertragenen Daten verwendet.

Kunden können Amazon EFS bereitstellen, um Daten im Ruhestand zu verschlüsseln. Im Speicher verschlüsselte Daten werden während des Schreibens transparent verschlüsselt und während des Lesens transparent entschlüsselt. Ein Anpassen Ihrer Anwendungen erübrigt sich dadurch. Verschlüsselungsschlüssel werden vom AWS Key Management Service (KMS) verwaltet, sodass Sie sich nicht mit dem Erstellen und Verwalten einer sicheren Schlüsselverwaltungsinfrastruktur befassen müssen.

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.

Nein, jede Lambda-Funktion kann auf ein EFS-Dateisystem zugreifen.

Ja. Amazon EFS unterstützt Lambda-Funktionen, ECS- und Fargate-Container und EC2-Instances. Sie können ein Dateisystem teilen und IAM-Richtlinien und Access Points verwenden, um zu steuern, worauf die einzelnen Funktionen, Container und Instances zugreifen können.  

Ja. Sie können Lambda-Funktionen mit einer Funktions-URL konfigurieren – einem integrierten HTTPS-Endpunkt, den Sie über den Browser, curl und jeden HTTP-Client aufrufen können. Funktions-URLs bieten eine einfache Möglichkeit, mit der Entwicklung von Funktionen zu beginnen, die über HTTPS zugänglich sind.

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.

Lambda-Funktions-URLs sind standardmäßig mit der IAM-Autorisierung gesichert. Sie haben die Wahl, die IAM-Autorisierung zu deaktivieren, um einen öffentlichen Endpunkt zu erstellen, oder eine benutzerdefinierte Autorisierung als Teil der Geschäftslogik der Funktion zu implementieren.

Sie können Ihre Funktion leicht von Ihrem Webbrowser aus aufrufen, indem Sie aus dem Code Ihrer Client-Anwendung mit einer HTTP-Bibliothek oder von der Befehlszeile aus mit curl zur Lambda-URL navigieren.

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.

Funktions-URLs unterstützen zurzeit keine benutzerdefinierten Domänennamen. Erstellen Sie zur Verwendung einer benutzerdefinierten Domäne mit Ihrer Funktions-URL eine Amazon-CloudFront-Verteilung und einen CNAME, um Ihre benutzerdefinierte Domäne dem Namen Ihrer CloudFront-Distribution zuzuordnen. Anschließend ordnen Sie den Domänennamen Ihrer CloudFront-Verteilung so zu, dass er zu Ihrer Funktions-URL als Ursprung weitergeleitet wird.

Ja. Lambda-Funktions-URLs können verwendet werden, um eine Funktion in einer VPC aufzurufen.

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 Replikation und Redunanz konzipiert, um hohe Verfügbarkeit sowohl für den Service selbst als auch für die Lambda-Funktionen zu bieten, die er ausführt. Es gibt keine Wartungsfenster und keine geplanten Ausfallzeiten.

Ja. Wenn Sie eine Lambda-Funktion aktualisieren, gibt es eine kurze Zeitspanne von normalerweise unter einer Minute, während der Anforderungen von der alten oder der neuen Version Ihrer Funktion ausgeführt werden können.

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.

Bei einem Ausfall antwortet die synchron aufgerufene Lambda-Funktion mit einer Ausnahme. Asynchron aufgerufene Lambda-Funktionen werden bei Bedarf mindestens drei Mal wiederholt. 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. Die Daten von Kinesis- und DynamoDB-Streams werden mindestens 24 Stunden aufbewahrt.

Als Dead-Letter-Queue können Sie eine Amazon SQS-Warteschlange oder ein Amazon SNS-Thema konfigurieren.

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.

Zugriffskontrollen können über die Lambda-Funktionsrolle oder über eine Einstellung der Ressourcenrichtlinie für die Warteschlange selbst verwaltet werden. Wenn beide Richtlinien festgelegt sind, wird die restriktivere der beiden Berechtigungen angewandt.

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.

Sie können Code Signing aktivieren, indem Sie eine Code-Signing-Konfiguration über die AWS-Managementkonsole, die Lambda-API, die AWS CLI, AWS CloudFormation und AWS SAM erstellen. Mit der Code-Signing-Konfiguration können Sie die zugelassenen Signierprofile angeben und konfigurieren, ob Bereitstellungen gewarnt oder zurückgewiesen werden sollen, wenn Signaturprüfungen fehlschlagen. Code-Signing-Konfigurationen können an einzelne Lambda-Funktionen angehängt werden, um die Code-Signing-Funktion zu aktivieren. Solche Funktionen beginnen nun mit der Überprüfung von Signaturen bei der Bereitstellung.

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.

Ja, Sie können Code Signing für bestehende Funktionen aktivieren, indem Sie eine Code-Signing-Konfiguration an die Funktion anhängen. Sie können dies über die AWS-Lambda-Konsole, die Lambda-API, die AWS CLI, AWS CloudFormation und AWS SAM tun.

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.

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.

Lambda stellt den Amazon Linux-Build openjdk 1.8 bereit.

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.

Ja. Sie können Pip verwenden, um beliebige erforderliche Python-Pakete zu installieren.

Sie können eine C#-Lambda-Funktion mithilfe der Visual Studio-IDE durch Auswählen von "Publish to AWS Lambda" im Projektmappen-Explorer erstellen. Sie können aber auch den Befehl "dotnet lambda publish" in der .Net-CLI ausführen, in der der [# Lambda-CLI-Tools-Patch] installiert ist. Auf diese Weise wird eine ZIP-Datei Ihres C#-Quellcodes zusammen mit allen NuGet-Abhängigkeiten sowie eigenen veröffentlichten DLL-Assemblys erstellt und automatisch mithilfe des Laufzeitparameters "dotnetcore1.0" zu AWS Lambda hochgeladen.

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. 

Verpacken Sie zur Bereitstellung von in Ruby geschriebenen Lambda-Funktionen Ihren Ruby-Code und die Gems als 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.

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.

AWS Lambda wird in AWS CloudTrail integriert. AWS CloudTrail kann Protokolldateien aufzeichnen und an Ihren Amazon S3-Bucket liefern, in denen die API-Verwendung Ihres Kontos beschrieben wird.

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.

Ja, AWS Lambda unterstützt den Befehlssatz Advanced Vector Extensions 2 (AVX2). Wenn Sie mehr darüber erfahren möchten, wie Sie Ihren Anwendungscode kompilieren, um diesen Befehlssatz für eine verbesserte Leistung anzusteuern, besuchen Sie die AWS-Lambda-Entwicklerdokumentation.