Allgemeines

F: Was ist AWS Lambda?

Mit AWS Lambda können Sie Code ausführen, ohne Server bereitstellen und verwalten zu müssen. Sie bezahlen nur für die Rechenzeit, die Sie verbrauchen – es entstehen keine Kosten, wenn Ihr Code nicht ausgeführt wird. Mit Lambda können Sie Code für fast jede Anwendungsart oder jeden Backend-Service ausführen, und zwar ohne Administration. Laden Sie Ihren Code einfach hoch und Lambda übernimmt alles, was zum Ausführen und Skalieren Ihres Codes für hohe Verfügbarkeit erforderlich ist. Sie können Ihren Code so einrichten, dass er automatisch von anderen AWS-Services ausgelöst wird, oder ihn indirekt von einer beliebigen Web- oder Mobil-App aufrufen.

F: Was ist eine Serverless-Datenverarbeitung?

Mit der Serverless-Datenverarbeitung können Sie Anwendungen und Services erstellen und ausführen, ohne sich über Server Gedanken machen zu müssen. Bei der Serverless-Datenverarbeitung wird Ihre Anwendung zwar weiterhin auf Servern ausgeführt, die Serververwaltung übernimmt jedoch AWS. Im Zentrum der Serverless-Datenverarbeitung steht AWS Lambda. Damit können Sie Ihren Code ausführen, ohne Server bereitstellen oder verwalten zu müssen.

F: Welche Ereignisse können eine AWS Lambda-Funktion auslösen?

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

F: Wann sollte ich AWS Lambda statt Amazon EC2 verwenden?

Amazon Web Services bietet eine Reihe von Datenverarbeitungsservices für verschiedene Anforderungen und Wünsche.

Amazon EC2 bietet Flexibilität mit zahlreichen Instance-Typen und der Option, das Betriebssystem, die Einstellungen für Netzwerk und Sicherheit und den ganzen Software-Stack anzupassen. So können Sie vorhandene Anwendungen leichter in die Cloud verschieben. Bei Amazon EC2 sind Sie zuständig für die Bereitstellung von Kapazität, die Überwachung von Flottenzustand und -leistung sowie das Entwerfen von Fehlertoleranz und Skalierbarkeit. AWS Elastic Beanstalk ist ein benutzerfreundlicher Service für die Bereitstellung und Skalierung von Webanwendungen, bei dem der Besitz der zugrunde liegenden EC2-Instances und die volle Kontrolle darüber bei Ihnen verbleibt. Amazon EC2 Container Service ist ein umfassend skalierbarer, sehr leistungsfähiger Container-Management-Service, der Docker-Container unterstützt. Sie können damit verteilte Anwendungen auf einem verwalteten Cluster von Amazon EC2-Instances betreiben und verwalten.

AWS Lambda vereinfacht die Ausführung von Code beim Eintreten bestimmter Ereignisse, z. B. von Änderungen an Amazon S3-Buckets, Updates von Amazon DynamoDB-Tabellen oder benutzerdefinierten, durch Ihre Geräte oder Anwendungen generierten Ereignissen. Bei Lambda müssen Sie nicht Ihre eigenen Instances bereitstellen. Lambda führt alle Betriebs- und Verwaltungsaktivitäten für Sie durch, einschließlich Kapazitätsbereitstellung, Überwachung des Zustands der Instances, Sicherheitspatches für die zugrunde liegenden Datenverarbeitungsressourcen, Bereitstellung Ihres Codes, Betreiben eines Webservice-Front-End und Überwachung und Protokollierung Ihres Codes. AWS Lambda bietet einfache Skalierung und hohe Verfügbarkeit für Ihren Code, ohne dass Sie sich weiter darum kümmern müssen.

F: Welche Art von Code kann auf AWS Lambda ausgeführt werden?

AWS Lambda bietet eine einfache Methode zum Durchführen vieler Aktivitäten in der Cloud. Sie können AWS Lambda beispielsweise verwenden, um Folgendes zu erstellen: Mobil-Backends, die Daten von Amazon DynamoDB abrufen und transformieren, Handler, die Objekte komprimieren oder transformieren, wenn Sie zu Amazon S3 hochgeladen werden, Prüfungen und Berichte über API-Aufrufe an Amazon Web Service und Serverless-Verarbeitung von Streaming-Daten mit Amazon Kinesis.

F: Welche Sprachen unterstützt AWS Lambda?

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

F: Kann ich auf die Infrastruktur zugreifen, auf der AWS Lambda läuft?

Nein. AWS Lambda betreibt die Datenverarbeitungs-Infrastruktur für Sie und ermöglicht dort Zustandsprüfungen, die Anwendung von Sicherheitspatches und die Durchführung sonstiger Routineaufgaben der Wartung.

F: Wie isoliert AWS Lambda meinen Code?

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

F: Wie sichert AWS Lambda meinen Code?

AWS Lambda speichert Code auf Amazon S3 und verschlüsselt ihn bei der Speicherung. AWS Lambda führt zusätzliche Integritätsprüfungen durch, während Ihr Code verwendet wird.

F: Welche AWS-Regionen sind für AWS Lambda verfügbar?

Diese Informationen finden Sie in der Tabelle für globale Infrastrukturregionen von AWS.

Funktionen von AWS Lambda

F: Was ist eine AWS Lambda-Funktion?

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.

F: Wird AWS Lambda Funktions-Instances wiederverwenden?

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.

F: Was ist, wenn ich Scratch-Datenträgerspeicherplatz für meine AWS Lambda-Funktion benötige?

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.

F: Wie konfiguriere ich meine Anwendung für die Verwendung von flüchtigem Speicher 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.

F: Ist der flüchtige Speicher von AWS Lambda verschlüsselt?

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

F: Welche Metriken kann ich verwenden, um die Nutzung meines flüchtigen Speichers von AWS Lambda zu überwachen?

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.

F: Wann sollte ich flüchtigen Speicher von Amazon S3, Amazon EFS oder AWS Lambda für meine Serverless-Anwendungen verwenden?

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.

F: Kann ich flüchtigen Speicher verwenden, während bereitgestellte Nebenläufigkeit für meine Funktion aktiviert ist?

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.

F: Wie konfiguriere ich meine Anwendung für die Verwendung von flüchtigem Speicher 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.

F: Ist der flüchtige Speicher von AWS Lambda verschlüsselt?

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

F: Welche Metriken kann ich verwenden, um die Nutzung meines flüchtigen Speichers von AWS Lambda zu überwachen?

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.

F: Warum müssen AWS-Lambda-Funktionen zustandslos sein?

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.

F: Kann ich in meinem AWS Lambda-Funktionscode Threads und Prozesse verwenden?

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.

F: Welche Beschränkungen gelten für AWS Lambda-Funktionscode?

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.

F: Wie erstelle ich mit der Lambda-Konsole eine AWS Lambda-Funktion?

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.

F: Wie erstelle ich mit der Lambda-Befehlszeile eine AWS Lambda-Funktion?

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.

F: Unterstützt AWS Lambda Umgebungsvariablen?

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: Kann ich sensible Informationen in Umgebungsvariablen speichern?

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 Logik in Ihren AWS Lambda-Funktionscode einbeziehen.

F: Wie kann ich meine AWS Lambda-Funktionen verwalten?

Sie können Ihre Lambda-Funktionen problemlos mit dem Dashboard in der AWS Lambda-Konsole auflisten, löschen, aktualisieren und überwachen. Sie können für die Verwaltung Ihrer Lambda-Funktionen auch die AWS-Befehlszeile und AWS SDK verwenden. Weitere Informationen finden Sie im Lambda-Entwicklerhandbuch.

F: Kann ich Code funktionsübergreifend teilen?

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.

F: Wie überwache ich eine AWS Lambda-Funktion?

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 AWS Lambda berechnet.

F: Wie behebe ich Fehler in einer AWS Lambda-Funktion?

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.

F: Wie skaliere ich eine AWS Lambda-Funktion?

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.

F: Wie werden einer AWS Lambda-Funktion Datenverarbeitungsressourcen zugewiesen?

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.

F: Wann sollte ich AWS-Lambda-Funktionen mit mehr als 3008 MB Speicher verwenden?

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.

F: Wie lange kann das Ausführen einer AWS Lambda-Funktion dauern?

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.

F: Wie wird mir die Nutzung von AWS Lambda-Funktionen in Rechnung gestellt?

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

F: Kann ich mit einem Compute Savings Plan bei AWS Lambda Geld sparen?

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.

F: Unterstützt AWS Lambda Versioning?

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.

F: Wie lange dauert es nach dem Hochladen meines Codes, bis meine AWS Lambda-Funktion bereit ist?

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

F: Kann ich meine eigene Version einer unterstützten Bibliothek verwenden?

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.

F: Wie funktioniert die Preisstaffelung?

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.

F: Kann ich sowohl die Preisstaffelung als auch die Compute Savings Plans nutzen?

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.

Nutzung von AWS Lambda zur Verarbeitung von AWS-Ereignissen

F: Was ist eine Ereignisquelle?

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 extrahieren und für jede abgerufene Nachricht eine Lambda-Funktion ausführen.

Viele andere Services, etwa AWS CloudTrail, können als Ereignisquellen fungieren, einfach indem sie auf Amazon S3 protokollieren und S3-Bucket-Benachrichtigungen für das Auslösen von AWS Lambda-Funktionen verwenden.

F: Welche Ereignisquellen können mit AWS Lambda verwendet werden?

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

F: Wie werden Ereignisse in AWS Lambda dargestellt?

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.

F: Wie gehe ich vor, damit eine AWS Lambda-Funktion auf Änderungen in einem Amazon S3-Bucket reagiert?

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 CLI verfügbar.

F: Wie gehe ich vor, damit eine AWS Lambda-Funktion auf Aktualisierungen in einer Amazon DynamoDB-Tabelle reagiert?

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.

F: Wie kann ich eine AWS Lambda-Funktion verwenden, um Datensätze in einem Amazon Kinesis-Stream zu verarbeiten?

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 CLI verfügbar.

F: Wie verarbeitet AWS Lambda Daten aus Amazon Kinesis-Streams und aus Amazon DynamoDB-Streams?

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.

F: Wie sollte ich für meine Analyseanforderungen zwischen AWS Lambda und Amazon Managed Service für Apache Flink wählen?

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 Managed Service für Apache Flink 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

F: Wie kann ich eine AWS Lambda-Funktion verwenden, um auf Benachrichtigungen zu antworten, die vom Amazon Simple Notification Service (SNS) gesendet wurde?

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 CLI verfügbar.

F: Wie kann ich eine AWS Lambda-Funktion verwenden, um auf E-Mails zu antworten, die vom Amazon Simple Email Service (SES) gesendet wurden?

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.

F: Wie kann ich eine AWS Lambda-Funktion verwenden, um auf Amazon CloudWatch-Alarme zu reagieren?

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.

F: Wie kann ich eine AWS Lambda-Funktion verwenden, um auf Änderungen bei Benutzer- oder Gerätedaten, die von Amazon Cognito verwaltet werden, zu reagieren?

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

F: Wie kann meine Anwendung direkt eine AWS Lambda-Funktion auslösen?

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.

F: Welche Latenz hat der Aufruf einer AWS Lambda-Funktion bei einem Ereignis?

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.

F: Wie erstelle ich ein Mobile-Backend mit AWS Lambda?

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.

F: Wie rufe ich eine AWS Lambda-Funktion über HTTPS ab?

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.

F: Wie kann meine AWS Lambda-Funktion ihr Verhalten gegenüber dem Gerät und der App anpassen, von denen die Anforderung kommt?

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.

F: Wie kann meine AWS Lambda-Funktion ihr Verhalten aufgrund der Identität des Benutzers einer Anwendung personalisieren?

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.

F: Wie erstelle ich eine Alexa Skill mit AWS Lambda?

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.

F: Was geschieht, wenn meine Funktion ausfällt, während Sie ein Ereignis verarbeitet?

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.

Anwendungserstellung mit AWS Lambda

F: Was ist eine serverlose Anwendung?

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 grundlegendste Serverless-Anwendung ist einfach eine Funktion.

F: Wie kann ich Serverless-Anwendungen bereitstellen und verwalten?

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.

F: Wie finde ich bestehende Serverless-Anwendungen, die von der AWS-Community entwickelt wurden?

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.

F: Wie automatisiere ich die Bereitstellung einer Serverless-Anwendung?

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 wie Canary und linearen Bereitstellungen planen und die Schutzmechanismen einrichten, um zu überprüfen, ob der neu bereitgestellte Code sicher und stabil ist und vollständig für die Produktion freigegeben werden kann.

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

F: Wie erstelle ich eine Serverless-Anwendung?

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.

F: Wie koordiniere ich Aufrufe zwischen mehreren AWS Lambda-Funktionen?

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.

F: Wie kann ich Probleme mit einer Serverless-Anwendung beheben?

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.

F: Kann ich serverlose Anwendungen erstellen, die sich mit relationalen Datenbanken verbinden?

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.

F: Wie wird AWS SAM lizenziert?

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.

Container-Image-Unterstützung

F: Was ist die Container-Image-Unterstützung für AWS Lambda?

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.

F: Wie kann ich die Container-Image-Unterstützung für AWS Lambda nutzen?

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.

F: Welche Container-Image-Typen werden unterstützt?

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.

F: Welche Basis-Images kann ich verwenden?

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.

F: Welche Container-Tools kann ich verwenden, um Funktionen als Container-Images zu verpacken und bereitzustellen?

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.

F: Welche AWS-Lambda-Funktionen sind für Funktionen verfügbar, die als Container-Images bereitgestellt werden?

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.

F: Wird AWS Lambda mein bereitgestelltes Container-Image patchen und aktualisieren?

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.

F: Was sind die Unterschiede zwischen Funktionen, die mit ZIP-Archiven erstellt wurden, und Container-Images?

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: Gibt es einen Leistungsunterschied zwischen Funktionen, die als Zip- bzw. Container-Images definiert sind?

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: Wie wird mir die Bereitstellung von Lambda-Funktionen als Container-Images in Rechnung gestellt?

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.

F: Was ist der Lambda Runtime Interface Emulator (RIE)?

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.

F: Warum benötige ich den Lambda Runtime Interface Emulator (RIE) beim lokalen Testen?

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.

F: Welches Funktionsverhalten kann ich lokal mit dem Emulator 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.

F: Wie hilft mir der Runtime Interface Emulator (RIE), mein Lambda-kompatibles Image auf zusätzlichen Rechendiensten auszuführen?

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.

F: Wie kann ich meine vorhandene containerisierte Anwendung in AWS Lambda bereitstellen?

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. Was ist AWS Lambda SnapStart?
 
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.
 
F. Wie konfiguriere ich meine Lambda-Funktion für die Verwendung von Lambda SnapStart?
 
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.
 
F. Wie kann ich zwischen Lambda SnapStart und Provisioned Concurrency (PC) wählen?

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.

F. Welche Laufzeiten werden von Lambda SnapStart unterstützt?
 
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.
 
F. Kann ich sowohl Lambda SnapStart als auch PC für dieselbe Funktion aktivieren?

Nein. Lambda SnapStart und PC können nicht gleichzeitig für dieselbe Funktion aktiviert werden.
 
F: Kann ich eine Lambda-SnapStart-Funktion mit einer Virtual Private Cloud (VPC) konfigurieren?
 
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.
 
F: Kann ich Lambda SnapStart sowohl auf x86- als auch auf Arm-Architekturen konfigurieren?

Nein. Sie können Lambda SnapStart derzeit nur für Funktionen konfigurieren, die auf der x86-Architektur laufen.
 
F. Kann ich Lambda SnapStart mit Amazon Elastic File System (EFS) aktivieren?

Nein. Sie können Lambda SnapStart derzeit nicht mit Amazon EFS aktivieren.
 
F. Kann ich Lambda SnapStart mit einem größeren ephemeren Speicher (/tmp) als 512 MB aktivieren?
 
Nein. Sie können Lambda SnapStart derzeit nicht mit einem größeren ephemeren Speicher (/tmp) als 512 MB aktivieren.
 
F. Gibt es beim Zwischenspeichern und Fortsetzen von Snapshots Probleme mit der Softwarekompatibilität?

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.

F. Kann ich meinen eigenen Code ausführen, bevor ein Snapshot erstellt wird oder wenn die Funktion aus dem Snapshot wieder aufgenommen wird?

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.

F. Werden mir für Lambda SnapStart Gebühren in Rechnung gestellt?

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.

F. Wie lange bleiben die Snapshots für die veröffentlichte Funktionsversion mit Lambda SnapStart im Cache?

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.

F. Wie kann ich die von Lambda SnapStart erstellten Snapshots der initialisierten Ausführungsumgebung verschlüsseln?

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.

F. Gibt es ein Zeitlimit dafür, wie lange meine Code-Initialisierung mit Lambda SnapStart laufen kann?

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

Was ist AWS Lambda Provisioned Concurrency?

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.

F: Wie richte ich die Provisioned Concurrency ein und verwalte sie?

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.

F: Muss ich meinen Code ändern, wenn ich Provisioned Concurrency verwenden möchte?

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.

F: Wie wird mir die Provisioned Concurrency berechnet?

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.

F: Wann sollte ich Provisioned Concurrency verwenden?

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.

F: Was passiert, wenn eine Funktion Aufrufe erhält, die über der konfigurierten Ebene von Provisioned Concurrency liegen?

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.

AWS-Lambda-Funktionen, die von Graviton2-Prozessoren unterstützt werden

F: Was sind AWS-Lambda-Funktionen, die von Graviton2-Prozessoren unterstützt werden?

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.

F: Warum sollte ich AWS Lambda-Funktionen verwenden, die von Graviton2-Prozessoren unterstützt werden?

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.

F: Wie konfiguriere ich meine Funktionen für die Ausführung auf Graviton2-Prozessoren?

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.

F: Wie stelle ich meine Anwendung bereit, die mit Funktionen auf Basis von Graviton2-Prozessoren erstellt wurde?

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.

F: Kann eine Anwendung sowohl Funktionen nutzen, die von Graviton2-Prozessoren als auch von x86-Prozessoren betrieben werden?

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.

F: Unterstützt AWS Lambda Container-Images mit mehreren Architekturen?

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

F: Kann ich AWS-Lambda-Ebenen erstellen, die auf Funktionen abzielen, die powered by AWS-Graviton2-Prozessoren sind?

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

F: Welche Sprachen und Laufzeiten werden von Lambda-Funktionen unterstützt, die auf Graviton2-Prozessoren ausgeführt werden?

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.

F: Wie sind die Preise für AWS Lambda-Funktionen, die powered by AWS-Graviton2-Prozessoren sind? Gilt das kostenlose AWS Lambda-Kontingent für Funktionen, die von Graviton2 betrieben werden?

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.

F: Wie kann ich wählen, ob ich meine Funktionen auf Graviton2-Prozessoren oder x86-Prozessoren ausführe?

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.

F: Benötige ich eine Arm-basierte Entwicklungsmaschine, um Funktionen, die von Graviton2-Prozessoren angetrieben werden, lokal zu entwickeln, zu erstellen und zu testen?

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.

Amazon EFS for AWS Lambda

F: Was ist Amazon EFS for AWS Lambda?

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.

F: Wie richte ich Amazon EFS for Lambda ein?

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: Muss ich meine Funktion mit VPC-Einstellungen einstellen, bevor ich mein Amazon EFS-Dateisystem verwenden kann?

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.

F: An wen richtet sich Amazon EFS for Lambda?

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.

F: Werden meine Daten bei der Übertragung verschlüsselt

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.

F: Werden meine Daten im Ruhezustand verschlüsselt?

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: Wie wird mir die Nutzung von Amazon EFS for AWS Lambda in Rechnung gestellt?

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.

F: Kann ich mehr als ein Amazon EFS-Dateisystem mit meiner AWS Lambda-Funktion verknüpfen?

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

F: Kann ich dasselbe Amazon EFS-Dateisystem funktions-, container-und instance-übergreifend verwenden?

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.  

Lambda-Erweiterungen

F: Was ist AWS Lambda Extensions?

Mit AWS Lambda Extensions können Sie Lambda mit Ihren bevorzugten Tools für die Zwecke der Überwachung, Beobachtung, Sicherheit und Governance integrieren. Mit Erweiterungen können Sie und Ihre bevorzugten Tooling-Anbieter den Lebenszyklus von Lambda nutzen und tiefer in die Lambda-Ausführungsumgebung integrieren.

F: Wie funktionieren Lambda-Erweiterungen?

Erweiterungen sind begleitende Prozesse, die in der Ausführungsumgebung von Lambda ablaufen, in der Ihr Funktionscode ausgeführt wird. Zudem können sie außerhalb des Funktionsaufrufes laufen. Dies bedeutet, dass sie vor Initialisierung der Funktion starten, parallel mit der Funktion laufen, nach Abschluss der Ausführung der Funktion laufen können und zudem laufen können, bevor der Lambda-Dienst die Ausführungsumgebung herunterfährt.

F: Zu welchen Zwecken können Lambda Extensions verwendet werden?

Sie können Erweiterungen mit Ihren bevorzugten Tools für die Zwecke der Überwachung, Beobachtung, Sicherheit und Governance von AWS sowie von den folgenden Partnern nutzen: AppDynamics, Coralogix, Datadog, Dynatrace, Epsagon, HashiCorp, Honeycomb, Imperva, Lumigo, Check Point CloudGuard, New Relic, Thundra, Splunk, Sentry, Site24x7, Sumo Logic, AWS AppConfig, Amazon CodeGuru Profiler, Amazon CloudWatch Lambda Insights, AWS Distro for OpenTelemetry. Weitere Informationen über diese Erweiterungen finden Sie im Blog-Beitrag zur Einführung.

F: Wie werden Lambda-Erweiterungen eingerichtet und verwaltet?

Erweiterungen können mit Layers in einer oder mehreren Lambda-Funktionen bereitgestellt werden. Verwenden Sie zu diesem Zweck Tools der Typen Konsole, CLI oder Infrastructure as Code wie CloudFormation, AWS Serverless Application Model oder Terraform. Informationen zum Einstieg finden Sie in der Dokumentation.

F: Mit welchen Laufzeiten können AWS-Lambda-Erweiterungen genutzt werden?

Hier finden Sie die Liste der Laufzeiten, die Erweiterungen unterstützen.

F: Zählen Erweiterungen hinsichtlich des Limits für Bereitstellungspakete?

Ja. Die entpackte Gesamtgröße der Funktion und sämtlicher Erweiterungen darf das Limit des entpackten Bereitstellungspakets von 250 MB nicht überschreiten.

F: Hat die Nutzung einer Erweiterung Auswirkungen auf die Leistung?

Erweiterungen können sich auf die Leistung Ihrer Funktion auswirken, da sie Ressourcen wie CPU, Arbeitsspeicher und Speicher mit der Funktion teilen und da Erweiterungen vor dem Funktionscode initialisiert werden. Wenn eine Erweiterung also beispielsweise rechenintensive Vorgänge ausführt, dauert die Ausführung Ihrer Funktion ggf. länger, da sich die Erweiterung und die Funktion die gleichen CPU-Ressourcen teilen. Da Lambda die CPU anteilig auf Basis der gewählten Speichereinstellung zuweist, kann es bei niedrigeren Speichereinstellungen zu einer längeren Ausführungs- und Initialisierungsdauer kommen, da mehr Prozesse um die gleichen CPU-Ressourcen konkurrieren.

Sie können PostRuntimeExecutionDuration heranziehen, um die zusätzliche Zeit zu messen, welche die Erweiterung nach Ausführung der Funktion benötigt. Zudem können Sie MaxMemoryUsed verwenden, um die höhere Nutzung des Arbeitsspeichers zu messen. Um zu erfahren, welche Auswirkungen eine bestimmte Erweiterung hat, können Sie zudem auf die Metrik "Duration" zurückgreifen. Derzeit wird die Antwort „Funktionsausführung“ ausgegeben, wenn die Ausführung von Funktion und Erweiterung abgeschlossen wurde. Weitere Informationen finden Sie in der Dokumentation für Lambda-Entwickler.

F: Wie wird mir die Nutzung von Lambda Extensions in Rechnung gestellt?

Erweiterungen haben dasselbe Abrechnungsmodell wie Lambda-Funktionen. Bei der Nutzung von Lambda-Funktionen mit Erweiterungen zahlen Sie für bereitgestellte Anfragen und die gesamte Rechenzeit zur Ausführung Ihres Codes und sämtlicher Erweiterungen (in Abstufungen von 1 ms). Ihnen wird Rechenzeit gemäß Lambda-Preisen für die Dauer in Rechnung gestellt. Weitere Informationen finden Sie unter Preise von AWS Lambda.

Der Lambda-Zyklus besteht aus drei klar unterschiedenen Phasen. "init": AWS Lambda initialisiert die Funktion, Abhängigkeiten und Erweiterungen; "invoke": Lambda führt als Reaktion auf Auslöser Funktions- und Erweiterungscode aus; "shut down": Die Durchführung der Funktion ist abgeschlossen, aber Erweiterungscode könnte noch laufen und das kann bis zu zwei Sekunden dauern. Es wird Ihnen die Berechnungszeit verrechnet, die für die Ausführung Ihres Erweiterungscodes während aller drei Phasen des Lambda-Lebenszyklus verwendet wird. Weitere Informationen über den Lambda-Lebenszyklus finden Sie in der Dokumentation zur Lambda-Ausführungsumgebung.

Für die Installation von Erweiterungen fallen keine zusätzlichen Kosten an. Angebote von Partnern allerdings können gebührenpflichtig sein. Um mehr darüber zu erfahren, ziehen Sie bitte die einschlägige Partner-Website heran.

F: Kann ich meine eigenen Lambda-Erweiterungen erzeugen?

Ja. Nutzen Sie dazu die AWS Lambda Runtime Extensions API. Weitere Informationen finden Sie in der Dokumentation.

F: Wie funktionieren Erweiterungen, wenn Provisioned Concurrency (bereitgestellte Nebenläufigkeit) aktiviert ist?

Provisioned Concurrency hält die Funktionen initialisiert und bereit, um in zweistelligen Millisekunden zu reagieren. Wenn aktiviert initialisiert Provisioned Concurrency zudem Erweiterungen und hält sie neben Funktionscode zur Ausführung bereit.

F: Welche Berechtigungen haben Erweiterungen?

Sie haben Zugriff auf dieselben Ressourcen wie die Funktion und Berechtigungen werden zwischen Funktion und Erweiterung geteilt, weil Erweiterungen in der gleichen Umgebung wie die Lambda-Funktion ausgeführt werden. Damit teilen Sie Anmeldeinformationen, Rolle und Umgebungsvariablen. Erweiterungen haben reinen Lesezugriff auf Funktionscode und können in „/tmp“ lesen und schreiben.

F: Was ist die AWS-Lambda-Telemetry-API?

Die AWS-Lambda-Telemetry-API ermöglicht es Ihnen, Erweiterungen zur Erfassung von erweiterten Überwachungs- und Beobachtbarkeits-Daten direkt aus Lambda zu verwenden, und diese an ein Ziel Ihrer Wahl zu senden.

F: Wie funktioniert die Telemetry-API?

Der Lambda-Service erfasst und streamt automatisch Telemetrie-Daten an Amazon CloudWatch und AWS X-Ray. Die Telemetry-API bietet eine einfache HTTP- oder TCP-Schnittstelle, damit Erweiterungen die selben Telemetrie-Daten gemeinsam mit Lebenszyklus-Ereignissen der Lambda-Ausführungsumgebung und Metriken auf der Funktions-Aufrufs-Ebene erhalten. Erweiterungen können die Telemetry-API verwenden, um diese Telemetrie-Streams direkt von Lambda zu verbrauchen und sie dann zu verarbeiten, zu filtern und an ein beliebiges Ziel zu senden.

F: Wie sehen die ersten Schritte mit der Telemetry-API aus?

Sie können Telemetry-API-aktivierte Erweiterungen für Ihre Lambda-Funktionen mithilfe der AWS-Lambda-Konsole, der AWS-CLI oder Infrastructure-as-Code-Tools wie AWS CloudFormation, AWS Serverless Application Model (SAM) und Terraform bereitstellen. Sie müssen keine Codeänderungen vornehmen, um eine Telemetry-API-aktivierte Erweiterung mit Ihrer Lambda-Funktion zu verwenden. Fügen Sie Ihrer Lambda-Funktion einfach eine Erweiterung aus dem Tool-Anbieter Ihrer Wahl hinzu.  Um mit den Erweiterungen von APN-Partnern zu beginnen, folgen Sie den Links im Launch-Blogbeitrag. Sie können auch Ihre eigenen Erweiterungen entwickeln, die Telemetry-API verwenden. Weitere Informationen finden Sie im AWS-Lambda-Entwicklerhandbuch.

F: Hat die Nutzung der Telemetry-API Auswirkungen auf die Leistung?

Die Telemetry-API kann nur innerhalb von AWS-Lambda-Erweiterungen verwendet werden. Erweiterungen können sich auf die Leistung Ihrer Funktion auswirken, da sie Ressourcen wie CPU, Arbeitsspeicher und Speicher mit der Funktion teilen. Die Nutzung des Arbeitsspeichers nimmt linear mit der Anzahl an Telemetry-API-Abonnements zu, weil jedes Abonnement einen neuen Arbeitsspeicher-Puffer zur Speicherung der Telemetrie-Daten eröffnet. Sie können jedoch die Arbeitsspeicher-Nutzung optimieren, indem Sie die Puffer-Konfiguration in der Abonnement-Anforderung der Telemetry-API anpassen. Wir empfehlen Anbietern von Erweiterungen, den erwarteten Ressourcenverbrauch zu veröffentlichen, damit Funktionsentwickler einfacher eine passende Erweiterung auswählen können. Bitte beziehen Sie sich auf die Dokumentation Ihres Erweiterungs-Anbieters, um den potenziellen Leistungsaufwand bei der Verwendung der Erweiterung zu verstehen.

F: Wie wird mir die Nutzung der Telemetry-API in Rechnung gestellt?

Für die Nutzung der AWS-Lambda-Telemetry-API fallen keine zusätzlichen Gebühren an. Für Erweiterungen, die Telemetry-API nutzen, wird das gleiche Abrechnungsmodell verwendet wie für andere Erweiterungen und Lambda-Funktionen. Weitere Informationen zu den Preisen für Erweiterungen finden Sie auf der Lambda-Preisseite.

F: Wird das Senden von Protokollen an Amazon CloudWatch Logs durch die Nutzung der Telemetry-API deaktiviert?

Nein, die Lambda-Plattform sendet standardmäßig alle Telemetrie-Daten an CloudWatch Logs, und die Verwendung der Telemetry-API deaktiviert nicht den Ausgang zu CloudWatch Logs.

Lambda-Funktions-URLs

F: Unterstützen AWS-Lambda-Funktionen HTTP(S)-Endpunkte?

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.

F: Wie konfiguriere ich eine Lambda-Funktions-URL für meine Funktion?

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.

F: Wie kann ich die URL meiner Lambda-Funktion sichern?

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.

F: Wie rufe ich meine Funktion mit einer Lambda-Funktions-URL auf?

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.

F: Funktionieren Lambda-Funktions-URLs mit Funktionsversionen und Aliasnamen?

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: Kann ich benutzerdefinierte Domänen für meine Lambda-Funktions-URL aktivieren?

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.

F: Kann ich Lambda-Funktions-URLs verwenden, um eine Funktion in einer VPC aufzurufen?

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

F: Was sind die Preise für Lambda-Funktions-URLs?

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.

Lambda@Edge

F: Was ist Lambda@Edge?

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.

F: Wie nutze ich Lambda@Edge?

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

F: Wann sollte ich Lambda@Edge verwenden?

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.

F: Kann ich meine bestehenden Lambda-Funktionen für den globalen Aufruf bereitstellen?

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.

F: Welche Amazon CloudFront-Ereignisse können zum Auslösen meiner Funktionen verwendet werden?

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.

F: Inwiefern unterscheidet sich AWS Lambda@Edge von der Nutzung von AWS Lambda-Ressourcen hinter Amazon API Gateway?

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.

Skalierbarkeit und Verfügbarkeit

F: Wie verfügbar sind AWS Lambda-Funktionen?

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.

F: Bleiben meine AWS Lambda-Funktionen verfügbar, wenn ich meinen Code oder seine Konfiguration ändere?

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.

F: Gibt es eine Begrenzung für die Anzahl der AWS Lambda-Anforderungen, die ich gleichzeitig ausführen kann?

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

F: Was passiert, wenn mein Konto die Standarddrosselung für gleichzeitige Ausführungen überschreitet?

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.

F: Werden die standardmäßigen Höchstgrenzen für die gleichzeitige Ausführung auf einer Ebene pro Funktion angewendet?

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 Reserved Concurrency finden Sie hier).

F: Wie schnell skalieren meine AWS-Lambda-Funktionen?

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: Was geschieht, wenn meine Lambda-Funktion ausfällt, während Sie ein Ereignis verarbeitet?

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.

F: Was passiert, wenn meine Lambda-Funktionsaufrufe die festgelegte Richtlinie überschreiten?

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.

F: Welche Ressourcen kann ich als Dead-Letter-Queue für eine Lambda-Funktion konfigurieren?

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

Sicherheits- und Zugriffskontrolle

F: Wie kann ich für meine AWS Lambda-Funktion den Zugriff auf andere AWS-Ressourcen freigeben?

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.

F: Wie kontrolliere ich, welche Amazon S3-Buckets welche AWS Lambda-Funktionen aufrufen können?

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.

F: Wie kontrolliere ich, welche Amazon DynamoDB-Tabelle bzw. welchen Amazon Kinesis-Stream eine AWS Lambda-Funktion abrufen kann?

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.

F: Wie kontrolliere ich, welche Amazon SQS-Warteschlange eine AWS Lambda-Funktion abrufen kann?

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.

F: Wie greife ich von meiner AWS-Lambda-Funktion aus auf Ressourcen in Amazon VPC zu?

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.

F: Was ist eine Codesignatur für AWS Lambda?

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.

F: Wie kann ich digital signierte Code-Artefakte erstellen?

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.

F: Wie konfiguriere ich meine Lambda-Funktionen, um Code Signing zu aktivieren?

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.

F: Welche Signaturprüfungen führt AWS Lambda bei der Bereitstellung durch?

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.

F: Kann ich Code Signing für bestehende Funktionen aktivieren?

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.

F: Entstehen zusätzliche Kosten für die Verwendung von Code Signing für AWS Lambda?

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.

Erweiterte Protokollierungs-Steuerelemente

F: Welche erweiterten Protokollierungs-Steuerelemente werden auf Lambda unterstützt?

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.

F: Wofür kann ich erweiterte Protokollierungs-Steuerelemente verwenden?

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.

F: Wie verwende ich erweiterte Protokollierungs-Steuerelemente?

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.

F: Kann ich meine eigenen Protokollierunngs-Bibliotheken verwenden, um strukturierte JSON-Protokolle für meine Lambda-Funktion zu generieren?

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: Wie wird mir die Nutzung der erweiterte Protokollierungs-Steuerelemente in Rechnung gestellt?

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.

AWS Lambda-Funktionen in Java

F: Wie kompiliere ich den Java-Code meiner AWS Lambda-Funktion?

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.

F: Welche JVM-Umgebung verwendet Lambda für das Ausführen meiner Funktion?

Lambda stellt den Amazon Linux-Build openjdk 1.8 bereit.

AWS Lambda-Funktionen in Node.js

F: Kann ich Pakete mit AWS Lambda verwenden?

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

F: Kann ich in meiner AWS Lambda-Funktion andere Programme ausführen, die in Node.js geschrieben wurden?

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 finden Sie hier.

F: Ist es möglich, native Module mit AWS Lambda-Funktionen zu verwenden, die in Node.js geschrieben wurden?

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 finden Sie hier.

F: Kann ich mit AWS Lambda Binärdateien ausführen, die in Node.js geschrieben wurden?

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 finden Sie hier.

F: Wie stelle ich AWS Lambda-Funktionscode bereit, der in Node.js geschrieben wurde?

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.

AWS Lambda-Funktionen in Python

F: Kann ich Python-Pakete mit AWS Lambda verwenden?

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

AWS Lambda-Funktionen in C#

F: Wie kann ich eine AWS Lambda-Funktion in C# packen und bereitstellen?

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.

AWS Lambda-Funktionen in PowerShell

F: Wie stelle ich AWS Lambda-Funktionscode bereit, der in PowerShell geschrieben wurde?

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.

F: Wie stelle ich AWS Lambda-Funktionscode bereit, der in PowerShell geschrieben wurde?  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.
F: Wie stelle ich AWS Lambda-Funktionscode bereit, der in PowerShell geschrieben wurde?  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.

AWS Lambda-Funktionen in Go

F: Wie kann ich eine AWS Lambda-Funktion in Go packen und bereitstellen? 

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

AWS Lambda-Funktionen in Ruby

F: Wie stelle ich AWS Lambda-Funktionscode bereit, der in Ruby geschrieben wurde? 

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.

Andere Themen

F: Welche Versionen von Amazon Linux, Node.js, Python, JDK, .NET Core, SDKs und sonstigen Bibliotheken unterstützt AWS Lambda?

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

F: Kann ich die Version von Amazon Linux oder einer anderen Language Runtime ändern?

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.

F: Wie kann ich Aufrufe der AWS Lambda-API aufzeichnen und prüfen?

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.

F: Wie koordiniere ich Aufrufe zwischen mehreren Lambda-Funktionen?

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.

F: Unterstützt AWS Lambda Advanced Vector Extensions 2 (AVX2)?

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.

Weitere Informationen zur Preisgestaltung von AWS Lambda finden Sie hier

Preisübersicht
Sind Sie startbereit?
Registrieren
Haben Sie noch Fragen?
Kontakt