Lambda-Ausführungen

Wenn Lambda eine Funktion in Ihrem Namen ausführt, verwaltet es sowohl die Bereitstellung als auch die Konfiguration der zugrunde liegenden Systeme, die zur Ausführung Ihres Codes erforderlich sind. Auf diese Weise können sich Ihre Entwickler auf die Geschäftslogik und das Schreiben von Code konzentrieren, ohne die zugrunde liegenden Systeme verwalten zu müssen.

Der Lambda-Service ist in die Steuerungsebene und die Datenebene aufgeteilt. Jede Ebene dient einem bestimmten Zweck im Service. Die Steuerungsebene stellt die Verwaltungs-APIs bereit (z. B. CreateFunction, UpdateFunctionCode, PublishLayerVersion usw.) und verwaltet Integrationen mit allen AWS-Services. Die Kommunikation mit der Steuerebene von Lambda ist während der Übertragung durch TLS geschützt. Alle Kundendaten, die in der Steuerebene von Lambda gespeichert sind, werden im Ruhezustand mithilfe von AWS KMS verschlüsselt, um sie vor unbefugter Offenlegung oder Manipulation zu schützen.

Die Datenebene ist Lambdas Invoke-API, die den Aufruf von Lambda-Funktionen auslöst. Wenn eine Lambda-Funktion aufgerufen wird, weist die Datenebene dieser Funktionsversion eine Ausführungsumgebung auf einem AWS-Lambda-Worker (oder einfach Worker – eine Art Amazon-EC2-Instance) zu oder wählt eine vorhandene Ausführungsumgebung aus, die bereits für diese Funktionsversion eingerichtet wurde, die es dann verwendet, um den Aufruf abzuschließen. Weitere Informationen finden Sie im Abschnitt „AWS Lambda MicroVMS and Workers“ in diesem Dokument.

Lambda-Ausführungsumgebungen

Jeder Aufruf wird vom Aufrufdienst von Lambda an eine Ausführungsumgebung auf einem Worker weitergeleitet, der die Anforderung bearbeiten kann. Außer über die Datenebene können Kunden und andere Benutzer keine eingehende Netzwerkkommunikation mit einer Ausführungsumgebung direkt initiieren. Auf diese Weise können Sie sicherstellen, dass die Kommunikation mit Ihrer Ausführungsumgebung authentifiziert und autorisiert ist.

Ausführungsumgebungen sind für eine bestimmte Funktionsversion reserviert und können nicht über Funktionsversionen, Funktionen oder AWS-Konten hinweg wiederverwendet werden. Das bedeutet, dass eine einzelne Funktion, die zwei verschiedene Versionen haben kann, zu mindestens zwei eindeutigen Ausführungsumgebungen führen würde.

Jede Ausführungsumgebung kann jeweils nur für einen gleichzeitigen Aufruf verwendet werden, und sie können aus Leistungsgründen für mehrere Aufrufe derselben Funktionsversion wiederverwendet werden. Abhängig von einer Reihe von Faktoren (z. B. Aufrufrate, Funktionskonfiguration usw.) können eine oder mehrere Ausführungsumgebungen für eine bestimmte Funktionsversion existieren. Mit diesem Ansatz ist Lambda in der Lage, seinen Kunden eine Isolierung auf Funktionsversionsebene bereitzustellen.

Lambda isoliert derzeit keine Aufrufe innerhalb der Ausführungsumgebung einer Funktionsversion. Dies bedeutet, dass ein Aufruf einen Zustand hinterlassen kann, der sich auf den nächsten Aufruf auswirken kann (z. B. in /tmp geschriebene Dateien oder In-Memory-Daten). Wenn Sie sicherstellen möchten, dass ein Aufruf keinen anderen Aufruf beeinflussen kann, empfiehlt Lambda, dass Sie zusätzliche andere Funktionen erstellen. Sie könnten beispielsweise unterschiedliche Funktionen für komplexe Analysevorgänge erstellen, die fehleranfälliger sind, und Funktionen wiederverwenden, die keine sicherheitsempfindlichen Vorgänge ausführen. Lambda begrenzt derzeit nicht die Anzahl der Funktionen, die Kunden erstellen können. Weitere Informationen zu Grenzwerten finden Sie auf der Seite Lambda-Kontingente.

Ausführungsumgebungen werden kontinuierlich von Lambda überwacht und verwaltet und können aus einer Reihe von Gründen erstellt oder zerstört werden, einschließlich, aber nicht beschränkt auf:

Kunden können die Anzahl der vorab bereitgestellten Ausführungsumgebungen verwalten, die für eine Funktionsversion vorhanden sind, indem sie die bereitgestellte Parallelität in ihrer Funktionskonfiguration konfigurieren. Bei entsprechender Konfiguration erstellt, verwaltet und stellt Lambda sicher, dass die konfigurierte Anzahl von Ausführungsumgebungen immer vorhanden ist. Auf diese Weise haben Kunden eine bessere Kontrolle über die Startleistung ihrer Serverless-Anwendungen beliebiger Größe.

Abgesehen von einer bereitgestellten Parallelitätskonfiguration können Kunden die Anzahl der Ausführungsumgebungen, die von Lambda als Reaktion auf Aufrufe erstellt oder verwaltet werden, nicht deterministisch steuern.

Ausführungsrolle

Jede Lambda-Funktion muss auch mit einer Ausführungsrolle konfiguriert werden, bei der es sich um eine IAM-Rolle handelt, die vom Lambda-Service bei der Ausführung von Steuerungs- und Datenebenenoperationen in Bezug auf die Funktion übernommen wird. Der Lambda-Service übernimmt diese Rolle, um temporäre Sicherheitsanmeldeinformationen abzurufen, die dann während des Aufrufs einer Funktion als Umgebungsvariablen verfügbar sind. Aus Leistungsgründen speichert der Lambda-Service diese Anmeldeinformationen im Cache und kann sie in verschiedenen Ausführungsumgebungen wiederverwenden, die dieselbe Ausführungsrolle verwenden.

Um sicherzustellen, dass das Prinzip der geringsten Berechtigung eingehalten wird, empfiehlt Lambda, dass jede Funktion ihre eigene Rolle hat und dass sie mit dem Mindestsatz an Berechtigungen konfiguriert ist, die sie benötigt.

Der Lambda-Service kann auch die Ausführungsrolle übernehmen, um bestimmte Steuerungsebenenoperationen durchzuführen, z. B. solche im Zusammenhang mit dem Erstellen und Konfigurieren von Elastic Network Interfaces (ENI) für VPC-Funktionen und dem Senden von Protokollen an Amazon CloudWatch Application Insights, Senden von Traces an AWS X-Ray oder anderen nicht aufrufbezogenen Vorgängen. Kunden können diese Anwendungsfälle jederzeit ansehen und prüfen, indem sie die Überwachungsprotokolle in AWS CloudTrail ansehen.

Weitere Informationen zu diesem Thema finden Sie auf der Dokumentationsseite der AWS-Lambda-Ausführungsrolle.

Lambda-MicroVMS und Worker

Lambda wird seine Ausführungsumgebungen auf einer Flotte von Amazon-EC2-Instances namens AWS-Lambda-Worker erstellen. Worker sind Bare-Metal-EC2-Nitro-Instances, die von Lambda in einem separaten, isolierten AWS-Konto gestartet und verwaltet werden, das für Kunden nicht sichtbar ist. Worker haben eine oder mehrere Hardware-virtualisierte Micro Virtual Machines (MVM), die von Firecracker erstellt wurden. Firecracker ist ein Open-Source-Virtual-Machine-Monitor (VMM), der die Kernel-basierte virtuelle Maschine (KVM) von Linux zum Erstellen und Verwalten von MVMs verwendet. Es wurde speziell für die Erstellung und Verwaltung sicherer, mehrmandantenfähiger Container und funktionsbasierter Dienste entwickelt, die Serverless-Betriebsmodelle bereitstellen. Weitere Informationen zum Sicherheitsmodell von Firecracker finden Sie auf der Firecracker-Projekt-Website.

Als Teil des Modells der geteilten Verantwortung ist Lambda für die Aufrechterhaltung der Sicherheitskonfiguration, Kontrollen und Patch-Levels der Worker verantwortlich. Das Lambda-Team verwendet Amazon Inspector, um bekannte potenzielle Sicherheitsprobleme sowie andere benutzerdefinierte Mechanismen zur Benachrichtigung über Sicherheitsprobleme und Listen zur Vorabveröffentlichung zu ermitteln, sodass Kunden den zugrunde liegenden Sicherheitsstatus ihrer Ausführungsumgebung nicht verwalten müssen.

Abbildung 3 – Isolationsmodell für AWS Lambda Worker

Worker haben eine maximale Lease-Lebensdauer von 14 Stunden. Wenn sich ein Worker der maximalen Lease-Zeit nähert, werden keine weiteren Aufrufe an ihn weitergeleitet, MVMs werden ordnungsgemäß beendet und die zugrunde liegende Worker-Instance wird beendet. Lambda überwacht und alarmiert kontinuierlich die Lebenszyklusaktivitäten seiner Flotte.

Die gesamte Datenebenenkommunikation mit den Workern wird mit Advanced Encryption Standard mit Galois/Counter Mode (AES-GCM) verschlüsselt. Abgesehen von Operationen auf Datenebene können Kunden nicht direkt mit einem Worker interagieren, da dieser in einer netzwerkisolierten Amazon-VPC gehostet wird, die von Lambda in den Servicekonten von Lambda verwaltet wird.

Wenn ein Worker eine neue Ausführungsumgebung erstellen muss, erhält er eine zeitlich begrenzte Berechtigung, auf Artefakte der Kundenfunktion zuzugreifen. Diese Artefakte sind speziell für die Ausführungsumgebung und die Worker von Lambda optimiert. Funktionscode, der im ZIP-Format hochgeladen wird, wird einmal optimiert und dann in einem verschlüsselten Format mit einem von AWS verwalteten Schlüssel und AES-GCM gespeichert.

Funktionen, die mit dem Container-Image-Format auf Lambda hochgeladen wurden, werden ebenfalls optimiert. Das Container-Image wird zuerst von seiner ursprünglichen Quelle heruntergeladen, in verschiedene Chunks optimiert und dann mit einer authentifizierten konvergenten Verschlüsselungsmethode, die eine Kombination aus AES-CTR, AES-GCM und SHA-256 MAC verwendet, als verschlüsselte Chunks gespeichert. Mit der konvergenten Verschlüsselungsmethode kann Lambda verschlüsselte Chunks sicher deduplizieren. Alle Schlüssel, die zur Entschlüsselung von Kundendaten erforderlich sind, werden durch vom Kunden verwaltete AWS KMS Customer Master Key (CMK) geschützt. Die CMK-Nutzung durch den Lambda-Service steht Kunden in AWS CloudTrail-Protokollen zur Nachverfolgung und Prüfung zur Verfügung.