Lambda Layers und Deployment-Pakete

Lambda-Bereitstellungspakete müssen eigenständig sein – alle Abhängigkeiten (Bibliotheken, SDKs und Binärdateien) müssen in der ZIP-Datei enthalten sein. Dadurch wächst die Paketgröße schnell: Eine Python-Funktion für Data Science mit NumPy, Pandas und SciPy kann unkomprimiert mehr als 200 MB umfassen. Bei jeder Aktualisierung des Funktionscodes muss das gesamte Paket einschließlich unveränderter Bibliotheken erneut hochgeladen werden. Lambda Layers lösen dieses Problem, indem sie gemeinsam genutzte Abhängigkeiten vom Funktionscode trennen.

Ein Lambda-Layer ist ein ZIP-Archiv, das Bibliotheken, benutzerdefinierte Runtimes, Daten oder Konfigurationsdateien enthält. Layer werden getrennt von Ihrem Funktionscode gespeichert und unter /opt in die Ausführungsumgebung der Funktion eingebunden. Mehrere Funktionen können denselben Layer gemeinsam nutzen – aktualisieren Sie den Layer einmal, profitieren alle Funktionen, die ihn verwenden. Jede Lambda-Funktion kann bis zu 5 Layer haben, und die kombinierte entpackte Größe darf 250 MB nicht überschreiten.

Um einen Layer zu erstellen, packen Sie Ihre Abhängigkeiten in die für Ihre Runtime korrekte Verzeichnisstruktur (z. B. python/lib/python3.12/site-packages/ für Python), komprimieren Sie sie als ZIP-Datei und veröffentlichen Sie diese. Nach der Veröffentlichung erhält der Layer eine Versions-ARN. Verwenden Sie diese ARN, wenn Sie den Layer an eine Funktion anhängen. Bei jeder Aktualisierung des Layers wird eine neue Version erstellt. Funktionen verwenden weiterhin die Version, mit der sie konfiguriert wurden, bis Sie sie ausdrücklich aktualisieren.

Fügen Sie einer Funktion Layer hinzu, indem Sie beim Erstellen oder Aktualisieren einer Funktion den Parameter --layers verwenden. Lambda bindet alle angehängten Layer ein, bevor die Funktion gestartet wird, und stellt sie unter /opt bereit. Python-Pakete unter /opt/python befinden sich automatisch im Python-Pfad; Node.js-Module unter /opt/nodejs/node_modules werden automatisch gefunden. Ihr Funktionscode kann Layer-Pakete mit import oder require verwenden, als wären sie lokal installiert.

AWS veröffentlicht offizielle Layer, die Sie verwenden können, ohne eigene zu erstellen. Beispiele sind der Layer AWS Lambda Powertools (strukturiertes Logging, Tracing, Feature-Flags), Layer mit Datenbanktreibern und der Layer AWS Parameters and Secrets Lambda Extension zum lokalen Caching von SSM-/Secrets-Manager-Werten. Drittanbieter wie Datadog und New Relic veröffentlichen ebenfalls öffentliche Layer für ihre Monitoring-Agenten. Prüfen Sie das Serverless Application Repository und die Lambda-Konsole auf verfügbare öffentliche Layer.

Lambda-Extensions werden als separate Prozesse neben Ihrem Funktionscode innerhalb derselben Ausführungsumgebung ausgeführt. Sie greifen in Lambda-Lebenszyklusereignisse (init, invoke, shutdown) ein, um beispielsweise Telemetriedaten zu erfassen, Sicherheitsprüfungen durchzuführen oder Konfigurationen zwischenzuspeichern. Extensions werden als Lambda-Layer verteilt. AWS stellt die Extension CloudWatch Lambda Insights und die Extension AWS AppConfig bereit; Anbieter stellen eigene Monitoring-Agenten als Extensions zur Verfügung.

Lambda unterstützt zwei Deployment-Formate:

• ZIP (bis zu 50 MB komprimiert, 250 MB entpackt): schneller Upload, unterstützt Layer und funktioniert mit allen Runtimes.
• Container Image (bis zu 10 GB): wird in Amazon ECR gespeichert, verwendet standardmäßige Docker-Tools, unterstützt keine Layer und eignet sich ideal für sehr große Abhängigkeiten (ML-Modelle, große Binärdateien).

Container Images müssen die Lambda Runtime Interface implementieren (unter Verwendung der von AWS bereitgestellten Basis-Images), damit Lambda weiß, wie Ihr Handler aufgerufen wird.

Das Erstellen und Bereitstellen eines Lambda-Container-Images folgt einem standardmäßigen Container-Workflow: Erstellen Sie das Image mit docker build, pushen Sie es nach Amazon ECR und geben Sie beim Erstellen oder Aktualisieren der Lambda-Funktion die Image-URI an. Container Images sind unveränderlich – jedes Image-Tag entspricht einer bestimmten Funktionsversion. Lambda cached Container Images in seiner Infrastruktur, sodass nachfolgende Cold Starts nach dem ersten schneller sind.

Lambda-Versionen sind unveränderliche Snapshots Ihres Funktionscodes und Ihrer Konfiguration. Jedes Mal, wenn Sie eine Version veröffentlichen, friert Lambda das Deployment-Paket, die Umgebungsvariablen und die Layer ein. Aliase sind benannte Verweise auf bestimmte Versionen – prod kann beispielsweise auf Version 5 und staging auf Version 6 zeigen. Sie können außerdem gewichtete Aliase verwenden, um für Canary-Deployments einen Prozentsatz des Datenverkehrs an eine neue Version weiterzuleiten (z. B. 10 % an v6 und 90 % an v5).

Auch Layer werden versioniert. Wenn Sie eine neue Layer-Version veröffentlichen, verwenden vorhandene Funktionen weiterhin ihre festgelegte Version, bis Sie sie aktualisieren. Dadurch können Sie einen gemeinsam genutzten Layer sicher aktualisieren, ohne alle Funktionen gleichzeitig zu beeinträchtigen – führen Sie die neue Version schrittweise ein. Stellen Sie alte Layer-Versionen schließlich ein, um Speicher- und Wartungsaufwand zu reduzieren. Lambda behält Layer-Versionen auch dann bei, wenn Sie sie in der Konsole löschen, solange keine Funktionen auf sie verweisen.

Verwenden Sie Layer, wenn die gesamte entpackte Größe unter 250 MB liegt, Sie Abhängigkeiten auf mehrere Funktionen verteilen möchten und schnelle Iterationen benötigen (Layer einmal aktualisieren, alle Funktionen profitieren). Verwenden Sie Container Images, wenn Abhängigkeiten größer als 250 MB sind, Sie benutzerdefinierte Pakete des Basisbetriebssystems benötigen, bereits Docker-Workflows nutzen oder große Ressourcen bündeln möchten (ML-Modelle, Referenzdatenbanken). Container Images sind nicht mit Lambda-Layern kompatibel, bieten aber mehr Flexibilität.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: Lambda-Layer verpacken gemeinsam genutzte Abhängigkeiten getrennt vom Funktionscode, wodurch die Paketgröße reduziert und die Wiederverwendung über mehrere Funktionen ermöglicht wird; Container Images (bis zu 10 GB über ECR) sind die richtige Wahl, wenn Abhängigkeiten das 250-MB-Limit von ZIP-Dateien überschreiten oder bereits Docker-Workflows verwendet werden; und Versionierung und Aliase ermöglichen unveränderliche Releases und Canary-Deployments mit gewichteter Aufteilung des Datenverkehrs. Als Nächstes sehen wir uns Lambda@Edge und ereignisgesteuerte Muster an.