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 Back-End-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 temporären Datenträgerspeicherplatz für meine AWS Lambda-Funktion benötige?

Jede Lambda-Funktion erhält 500 MB nicht persistenten Speicherplatz in seinem eigenen /tmp-Verzeichnis.

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.

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 zwischen AWS Lambda und Amazon Kinesis Data Analytics für meine Analyseanforderungen 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 Kinesis Data Analytics können Sie komplexere Analyseanwendungen erstellen, die flexible Verarbeitungsoptionen und robuste Fehlertoleranz mit Exact-once-Verarbeitung ohne Duplikate sowie Analysen, die über einen gesamten Datenstrom über mehrere logische Partitionen hinweg durchgeführt werden können, unterstützen. Mit KDA können Sie Daten über mehrere Arten von Aggregationsfenstern (Tumbling Window, Stagger Window, Sliding Window, Session Window) analysieren, wobei entweder die Ereigniszeit oder die Verarbeitungszeit verwendet wird.

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

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 planen, etwa lineare Bereitstellungen und solche für einzelne Nutzer- oder Servergruppen. Außerdem können Sie die erforderlichen Schutzmechanismen einrichten, um zu bestätigen, dass der neu bereitgestellte Code sicher, stabil und bereit für die Produktion ist.

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

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.

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.

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 Web-Inhalten oder die Entwicklung von internen Build-Systemen. Kunden können auch EFS for Lambda verwenden, um den Status zwischen Zeitverzögerungen innerhalb einer 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 Runtime Logs API?

Die AWS Lambda Runtime Logs API ermöglicht die Verwendung von Erweiterungen, um Protokolle von AWS Lambda-Funktionen direkt an ein Ziel Ihrer Wahl senden. Erweiterungen nutzen diese API, um die gleichen Protokolle zu abonnieren, die auch an Amazon CloudWatch Logs gestreamt werden, und können diese dann verarbeiten, filtern und an das gewünschte Ziel senden.

F: Wie funktioniert die Runtime Logs API?

Der Lambda-Service erfasst automatisch Protokolle und streamt sie an Amazon CloudWatch. Dieser Datenstream enthält die Protokolle, die im Rahmen Ihres Funktionscodes generiert werden, sowie die Protokolle, die vom Lambda-Service im Rahmen des Aufrufs generiert werden.

Mithilfe der Runtime Logs API können Erweiterungsersteller die gleichen Protokollstreams direkt in der Lambda-Ausführungsumgebung abonnieren. Nach Empfang der Abonnementanforderung werden Protokolle vom Lambda-Service sowohl an CloudWatch gesendet als auch per HTTP oder TCP an die Erweiterung gestreamt.

F: Wie sehen die ersten Schritte mit der Runtime Logs API aus?

Erweiterungen, die die Runtime Logs API nutzen, 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.

Sie können Erweiterungen mit Ihren bevorzugten Überwachungs-, Beobachtungs-, Sicherheits- und Governance-Tools von AWS sowie mit Tools von folgenden Partnern nutzen: Coralogix, Datadog, Honeycomb, Lumigo, New Relic, Sumo Logic und Amazon CloudWatch. Weitere Informationen über diese Erweiterungen finden Sie im Blog-Beitrag zur Einführung.

F: Hat die Nutzung der Runtime Logs API Auswirkungen auf die Leistung?

Die Runtime Logs 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 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. Jedes weitere Abonnement für die Runtime Logs API kann zudem weiteren Arbeitsspeicher für die Protokollspeicherung beanspruchen (zusätzlich zum Bedarf der enthaltenden Erweiterung).

F: Wie wird mir die Nutzung der Runtime Logs API in Rechnung gestellt?

Für die Nutzung der AWS Lambda Runtime Logs API fallen keine zusätzlichen Gebühren an. Für Erweiterungen, die die Runtime Logs 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 in den häufig gestellten Fragen.

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

Nein. Von der Lambda-Plattform werden standardmäßig alle Protokolle an CloudWatch Logs gesendet. Die Nutzung der Runtime Logs API führt nicht dazu, dass ausgehender Datenverkehr für CloudWatch Logs deaktiviert wird.

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 Anforderung zum Erhöhen der Standarddrosselung einreichen möchten, können Sie unser Support-Center besuchen, auf "Neuen Fall öffnen" klicken und eine Erhöhung der Kapazitätsgrenzen beantragen.

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

Beim Überschreiten der Drosselungsgrenze geben die synchron aufgerufenen AWS Lambda-Funktionen einen Drosselfehler (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: Wird die Standardgrenze pro Funktionsebene angewendet?

Nein, die Standardgrenze wird nur auf Kontoebene angewendet.

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: Kann ich mit der AWS Lambda-Funktion auf Ressourcen hinter Amazon VPC zugreifen?

Ja. Sie können auf Ressourcen hinter Amazon VPC zugreifen.

F: Wie aktiviere und deaktiviere ich den VPC-Support für meine Lambda-Funktion?

Zum Aktivieren des VPC-Supports müssen Sie ein oder mehrere Subnetze in einer einzelnen VPC sowie eine Sicherheitsgruppe im Rahmen Ihrer Funktionskonfiguration festlegen. Zum Deaktivieren des VPC-Supports aktualisieren Sie die Funktionskonfiguration und legen eine leere Liste für das Subnetze und die Sicherheitsgruppe an. Sie können diese Einstellungen über die AWS APIs, die Benutzerschnittstelle (CLI) oder die AWS Lambda-Verwaltungskonsole ändern.

F: Kann eine einzelne Lambda-Funktion Zugriff auf mehrere VPCs haben?

Lambda-Funktionen bieten jeweils nur Zugriff auf eine VPC. Sind mehrere Subnetze angegeben, müssen sich diese alle in derselben VPC befinden. Sie können mittels Peering eine Verbindung zu anderen VPCs herstellen.

F: Können Lambda-Funktionen in einer VPC auch auf das Internet und AWS-Service-Endpunkte zugreifen?

Lambda-Funktionen, die für den Zugriff auf Ressourcen in einer bestimmten VPC konfiguriert wurden, haben standardmäßig keinen Zugriff auf das Internet. Für den Zugriff auf externe Endpunkte müssen Sie in Ihrer VPC eine NAT erstellen, um den Datenverkehr weiterzuleiten, und die Sicherheitsgruppe so konfigurieren, dass sie den ausgehenden Datenverkehr zulässt.

F: Was ist Code Signing 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.

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?  Eine 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?  Eine 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

Zur Seite mit den Preisen
Sind Sie startbereit?
Registrieren
Haben Sie Fragen?
Kontakt