AWS Lambda erhält Dateisystem: So nutzt du S3 Files für KI-Agenten

AWS Lambda hat mit S3 Files eine bahnbrechende Neuerung eingeführt: Buckets lassen sich nun als lokales Dateisystem mounten. Das bedeutet, dass Funktionen Dateien direkt über Pfade lesen und schreiben können – ganz ohne manuelle Download- und Upload-Prozesse. Besonders spannend wird es, wenn mehrere KI-Agenten diese Struktur nutzen, um gemeinsam Aufgaben zu bearbeiten. Ein Beispielprojekt zeigt, wie das in der Praxis funktioniert.

Das Problem mit /tmp in Lambda

Jeder, der schon einmal mit AWS Lambda und S3 gearbeitet hat, kennt das wiederkehrende Muster: Ein S3-Ereignis löst eine Lambda-Funktion aus, die zunächst eine Datei von S3 herunterlädt. Nach der Verarbeitung wird das Ergebnis zurück in den Bucket geschrieben, während /tmp als temporärer Speicher dient. Doch dieses Vorgehen hat mehrere Nachteile:

• Wiederholter Code: Für jede Funktion muss der Prozess manuell implementiert werden – von der Authentifizierung bis zur Dateiverwaltung.
• Speichergrenzen: Der /tmp-Bereich ist auf 10 GB begrenzt. Bei großen Dateimengen oder parallelen Prozessen wird dieser schnell ausgeschöpft.
• Ineffizienz: Mehrere Funktionen, die auf dieselben Daten zugreifen, laden jeweils eine eigene Kopie herunter. Das führt zu doppelter Netzwerklast und Verzögerungen.

Tools wie s3fs oder smart_open können die Arbeit zwar erleichtern, doch im Kern handelt es sich weiterhin um API-Aufrufe an S3. Die Dateiverwaltung bleibt umständlich und fehleranfällig.

S3 Files: Buckets als Dateisystem nutzen

Mit S3 Files ändert sich das grundlegend. Die neue Funktion von AWS mountet einen S3-Bucket als lokales Dateisystem direkt in der Lambda-Funktion. Statt über SDK-Aufrufe zu arbeiten, greifen Entwickler einfach auf Dateipfade zu – etwa /mnt/workspace/source/app.py. Die Synchronisation mit S3 erfolgt automatisch im Hintergrund.

from pathlib import Path

WORKSPACE = Path("/mnt/workspace")

def lambda_handler(event, context):
    # Datei direkt lesen
    content = (WORKSPACE / "source" / "app.py").read_text()
    result = process(content)
    # Ergebnis direkt schreiben
    (WORKSPACE / "output" / "result.json").write_text(result)

Die Vorteile liegen auf der Hand:

• Kein `/tmp`-Management mehr: Dateien werden direkt im Bucket bearbeitet, ohne temporäre Kopien.
• Sub-millisekunden-Latenz: Aktuell genutzte Daten werden im Cache gehalten, während große Lesevorgänge direkt aus S3 gestreamt werden.
• Echte Dateisystem-Semantik: Funktionen können Dateien wie lokal vorhandene Ressourcen behandeln – inklusive Berechtigungen und Versionierung.

Allerdings gibt es eine wichtige Voraussetzung: Die Lambda-Funktion muss in einem VPC betrieben werden. Zudem wird ein NAT-Gateway für ausgehende Internetverbindungen benötigt. Obwohl VPCs bei Serverless-Entwicklern oft unbeliebt sind, hat AWS hier nachgebessert: Cold Starts fallen kaum noch ins Gewicht, und die Netzwerkkonfiguration lässt sich standardisieren.

Ein Praxisbeispiel: KI-gestützte Code-Reviews

Um die Möglichkeiten von S3 Files zu demonstrieren, habe ich ein serverloses System für automatisierte Code-Reviews aufgebaut. Die Architektur besteht aus drei Komponenten:

1. Orchestrierung der Pipeline

Eine übergeordnete Lambda-Funktion (verwendet durable functions) klont ein öffentliches GitHub-Repository in einen gemeinsamen S3-Workspace. Der Bucket ist dabei als Dateisystem gemountet, sodass alle Agenten direkt auf die Dateien zugreifen können.

2. Parallel arbeitende KI-Agenten

Zwei Agenten analysieren den Code gleichzeitig:

• Security Review Agent: Überprüft auf Sicherheitslücken, veraltete Bibliotheken oder unsichere Praktiken.
• Style Review Agent: Bewertet den Code nach Stilrichtlinien, z. B. PEP 8 für Python oder ESLint für JavaScript.

Jeder Agent nutzt das Strands Agents SDK mit Amazon Bedrock. Die Tools der Agenten sind so konfiguriert, dass sie direkt auf die gemounteten Dateipfade zugreifen können. Die KI entscheidet selbstständig, welche Dateien gelesen und analysiert werden müssen.

3. Ergebnisausgabe und Synchronisation

Die Bewertungen der Agenten werden als JSON-Dateien im selben Workspace abgelegt. Durch die automatische Synchronisation mit S3 stehen die Ergebnisse sofort zur Verfügung – ohne manuelle Uploads oder Downloads.

Die Infrastruktur: SAM-Template im Detail

Die Implementierung der Infrastruktur war herausfordernd, da S3 Files eine relativ neue Funktion ist. Die CloudFormation-Ressourcentypen sind noch nicht in allen Linters integriert. Hier die wichtigsten Erkenntnisse:

Benötigte Ressourcen

Um S3 Files mit Lambda zu nutzen, sind fünf Komponenten erforderlich:

• S3-Bucket mit Versionierung: Muss aktiviert sein, um die Dateisynchronisation zu ermöglichen.
• IAM-Rolle: Ermöglicht S3 Files den Zugriff auf den Bucket. Wichtig: Die Rolle muss dem EFS-Dienst vertrauen (elasticfilesystem.amazonaws.com), nicht S3 Files direkt.

S3FilesRole:
  Type: AWS::IAM::Role
  Properties:
    Path: /service-role/
    AssumeRolePolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Sid: AllowS3FilesAssumeRole
          Effect: Allow
          Principal:
            Service: elasticfilesystem.amazonaws.com
          Action: sts:AssumeRole

• S3 Files FileSystem: Verbindet den Bucket mit dem NFS-Dateisystem.
• Mount Targets: Netzwerkendpunkte in jeder Availability Zone.
• Access Point: Steuert die POSIX-Berechtigungen für Lambda.

Typische Fallstricke

1. Falsche Dienstprinzipale: Die IAM-Rolle muss dem EFS-Dienst vertrauen, nicht S3 Files. Dies ist ein häufiger Fehler, der zu Berechtigungsproblemen führt.
2. VPC-Konfiguration: Die Lambda-Funktion benötigt eine private Subnetz-Zuordnung und ein NAT-Gateway für ausgehende Verbindungen.
3. Linter-Warnungen: CloudFormation-Linter erkennen die neuen Ressourcentypen (AWS::S3Files::FileSystem) noch nicht. Warnungen können ignoriert werden.

Fazit: Ein Game-Changer für serverlose Architekturen

S3 Files eliminiert einen der größten Reibungspunkte in serverlosen Architekturen: die manuelle Dateiverwaltung. Durch die direkte Integration von S3 als Dateisystem entfallen nicht nur /tmp-Probleme, sondern auch komplexe Code-Strukturen für Downloads und Uploads.

Die neue Funktion eignet sich besonders für Szenarien mit mehreren vernetzten Funktionen oder KI-Agenten, die gemeinsam an derselben Datenbasis arbeiten. Obwohl die Einrichtung etwas Aufwand in der Infrastruktur erfordert, überwiegen die Vorteile deutlich. Wer bereits mit EFS vertraut ist, wird sich schnell einarbeiten – und profitiert von einer sauberen, skalierbaren Lösung.

Langfristig könnte S3 Files zum Standard für Dateizugriffe in Lambda werden. Bis dahin lohnt es sich, die Funktion in eigenen Projekten zu testen und die Vorteile selbst zu erleben.