6 Min. Lesezeit
Amazon S3 Files ist seit dem 7. April 2026 generell verfügbar. Die Funktion erlaubt es, S3-Buckets direkt als NFS-kompatibles Dateisystem in EC2, EKS und Lambda zu mounten – ohne Code-Änderungen an bestehenden Applikationen. Für DACH-Teams mit Legacy-Workloads, ML-Pipelines und Shared-Storage-Anforderungen ändert das die Architektur-Optionen grundlegend.
Das Wichtigste in Kürze
- NFS-Mount ohne Applikationsänderung: S3 Files stellt einen POSIX-kompatiblen Mount-Point bereit. Bestehende Applikationen die mit open(), read() und write() arbeiten, können ohne Refactoring auf S3 zugreifen.
- 34 Regionen, Preisunterschied zu EFS signifikant: S3-Storage kostet 0,023 USD/GB/Monat in Standard, EFS 0,30 USD/GB/Monat im Standard-Modus. Bei großen ML-Datasets und Modell-Checkpoints ist der Kostenfaktor relevant.
- Latenz ist der Trade-off: Metadata-Operationen bei S3 Files liegen bei 10-50ms, EFS unter 1ms. Workloads mit vielen kleinen File-Operationen (transaktionale DBs, kleine Config-Files in hoher Frequenz) sind nicht das Zielszenario.
- EKS-Integration über CSI-Driver: Der AWS S3 CSI-Driver ist aktualisiert und unterstützt S3 Files als PersistentVolume. Multi-Pod-Zugriff auf denselben Bucket ist möglich, wichtig für Distributed-Training-Setups.
VerwandtBSI-KRITIS, NIS2 und C5: Praxischeck Multi-Cloud-Compliance 2026 / BYOD im deutschen Enterprise 2026
Was S3 Files technisch macht – und was es nicht macht
Was ist Amazon S3 Files? S3 Files ist ein neues Feature von Amazon S3, das einen POSIX-kompatiblen Dateisystem-Mount-Endpunkt für bestehende S3-Buckets bereitstellt. Unter der Haube übersetzt ein Managed Service POSIX-Aufrufe in S3-API-Operationen. Das Ergebnis: eine Applikation die /mnt/data/model.bin liest, greift tatsächlich auf s3://bucket/model.bin zu – ohne das zu wissen.
Die technische Grundlage ist der S3 Files Agent, ein Sidecar-Prozess der auf der EC2-Instanz oder im Kubernetes-Pod läuft. Er übernimmt die POSIX-zu-S3-Übersetzung und hält einen lokalen Metadaten-Cache. Der Agent ist über den AWS S3 CSI-Driver in EKS integriert; für EC2 gibt es ein RPM- und DEB-Paket. Lambda-Unterstützung ist über Managed Runtime Layers verfügbar.
Was S3 Files nicht ist: kein vollständiges POSIX-Filesystem. File-Locking (flock/fcntl) wird nicht unterstützt. Symbolische Links sind read-only. Rename-Operationen haben keine atomare Garantie bei konkurrierendem Zugriff. Für Applikationen die auf diese Primitiven angewiesen sind – insbesondere klassische SQL-Datenbanken oder Build-Systeme mit File-Locking – ist EFS weiterhin die richtige Wahl.
Drei Szenarien für DACH-Teams
Für welche Workloads lohnt S3 Files konkret?
ML-Training und Model-Serving: Das ist das Hauptszenario. Trainingsdaten und Modell-Checkpoints liegen ohnehin in S3. Mit S3 Files kann ein PyTorch-Training-Job die Daten über /mnt/training-data lesen, ohne dass der Code von S3 weiß. Multi-Pod-Zugriff auf denselben Bucket ermöglicht Distributed-Training-Setups bei SageMaker und EKS. Der Kostenvorteil gegenüber EFS ist bei Datasets im TiB-Bereich erheblich: bei 10 TiB Trainingsdaten spart S3 Files rund 2.770 USD/Monat gegenüber EFS Standard.
Legacy-Applikationen mit Filesystem-Interface: Viele ältere Java- und C++-Applikationen lesen Konfigurationen und temporäre Daten aus dem lokalen Dateisystem. Wenn der eigentliche Storage schon in S3 liegt, erlaubt S3 Files den Verzicht auf eine separate EFS-Schicht. Das vereinfacht die Deployment-Architektur, besonders bei Lift-and-Shift-Migrationen die noch nicht refactored wurden.
Lambda und Serverless-Pipelines: Lambda-Funktionen haben bisher nur EFS als persistentes Dateisystem gehabt. S3 Files ist günstiger. Für Lambda-Workloads die ohnehin auf S3-Daten operieren (ETL, Image-Processing, Batch-Transformationen) ist der Mount der natürlichere Zugang als S3-API-Calls im Code.
Kostenvergleich Storage-Optionen (us-east-1)
$0,023
S3 Files / GB / Monat (Standard)
$0,30
EFS Standard / GB / Monat
$0,145
FSx for Lustre Scratch / GB / Monat
Was sich bei EKS ändert
Für Kubernetes-Teams ist der relevante Einstiegspunkt der AWS S3 CSI-Driver in Version 1.10 der die S3 Files-Unterstützung bringt. Ein PersistentVolume mit S3 Files sieht so aus:
kind: PersistentVolume
metadata:
name: s3-files-pv
spec:
capacity:
storage: 100Gi
accessModes:
– ReadWriteMany
mountOptions:
– allow-delete
– allow-overwrite
csi:
driver: s3.csi.aws.com
volumeHandle: s3-files-bucket-name
ReadWriteMany bedeutet dass mehrere Pods gleichzeitig auf denselben Bucket schreiben können. Bei ML-Distributed-Training mit Parameter-Servern oder bei Shared-Model-Repositories ist das das klare Plus gegenüber einer einzelnen EBS-Volume die nur ReadWriteOnce kann.
Ein Hinweis für DACH-Teams unter DSGVO: der S3-Bucket muss in einer europäischen Region liegen. Frankfurt (eu-central-1) und Stockholm (eu-north-1) sind vollständig unterstützt. Der S3 Files Agent kommuniziert ausschließlich mit dem regionalen S3-Endpoint – keine Daten verlassen die Region.
Wann EFS und FSx weiterhin besser sind
S3 Files ist kein EFS-Ersatz. Die Latenz-Unterschiede sind real: Bei Applikationen mit vielen kleinen, sequenziellen Filesystem-Operationen – klassische Web-Server, PHP-Applikationen die Config-Files häufig lesen, Build-Systeme – liegt EFS klar vorn. Metadata-Operationen wie stat() oder Directory-Listings sind bei S3 Files deutlich langsamer.
FSx for Lustre bleibt das Mittel der Wahl wenn Bandbreite maximiert werden soll – Lustre ist für parallelen Hochdurchsatz designed, S3 Files nicht. Bei sehr großen ML-Workloads (Modelle über 100 GB, intensive sequenzielle Reads) lohnt der FSx-Aufpreis weiterhin.
S3 Files: richtig für
- ML-Training auf großen Datasets (>100 GB)
- Model-Checkpoints und Artifact-Storage
- Lambda-Funktionen mit Dateisystem-Interface
- Legacy-Apps bei Lift-and-Shift ohne Refactoring
- Cost-Optimierung bei Storage-intensiven Workloads
Weiter EFS/FSx für
- Applikationen mit File-Locking-Anforderungen
- Viele kleine, sequenzielle Metadata-Operationen
- Web-Server mit häufigen Config-Reads
- Klassische SQL-Datenbankdateien
- Maximaler Durchsatz (>10 GB/s per Pod)
Die richtige Entscheidungsfrage: Liegt der primäre Storage des Workloads heute schon in S3 – hat die Applikation kein File-Locking? Dann ist S3 Files der naheliegende Weg. Liegt der Storage in EBS oder EFS – ist die Applikation stark latenzabhängig? Dann bleibt EFS.
Quellen: AWS-Dokumentation S3 Files GA (April 2026), AWS Pricing Calculator, AWS re:Invent S3-Session-Unterlagen.
Häufige Fragen
Ist S3 Files mit allen S3-Storage-Classes kompatibel?
S3 Files unterstützt S3 Standard, S3 Intelligent-Tiering und S3 Standard-IA für Lese- und Schreiboperationen. S3 Glacier und Glacier Deep Archive sind nicht direkt mountbar – Objekte in Glacier müssen zuerst wiederhergestellt werden. Für ML-Datasets empfiehlt AWS S3 Intelligent-Tiering als Standard-Storage-Class, da Trainingsdaten-Zugriffsmuster variieren.
Wie verhält sich S3 Files bei Multi-Region-Deployments?
S3 Files mounted nur Buckets in derselben Region wie der Mount-Point. Cross-Region-Zugriff ist nicht direkt unterstützt. Wer Workloads über mehrere Regionen hat, braucht entweder S3 Replication für Read-Zugriffe oder S3 Multi-Region Access Points als separaten Layer. Für DACH-Teams mit eu-central-1 und eu-west-1 als primäre Regionen ist das ein Planungspunkt bei globalen Deployments.
Braucht S3 Files zusätzliche IAM-Berechtigungen gegenüber normalem S3-Zugriff?
Ja. Zusätzlich zu den Standard-S3-Permissions (GetObject, PutObject, DeleteObject) braucht S3 Files s3:ListBucket, s3:GetBucketLocation und die neuen s3files:*-Aktionen für Metadata-Operationen. Die vollständige IAM-Policy ist in der AWS-Dokumentation unter „S3 Files IAM Permissions“ dokumentiert. Bei Least-Privilege-Policies müssen diese Aktionen explizit ergänzt werden.
Kann S3 Files in AWS GovCloud und in EU-Sovereign-Deployments genutzt werden?
S3 Files ist in AWS GovCloud (US-East und US-West) verfügbar. Für EU-Sovereign-Anforderungen nach BSI C5 und DSGVO: S3 Files läuft in eu-central-1 (Frankfurt) und ist damit unter deutschen Datenschutz-Rahmenbedingungen nutzbar. AWS hat S3 Files im Scope des C5-Attestierungsverfahrens, das Testat-Update für 2026 war bei GA-Launch in Bearbeitung. Wer das für KRITIS-Compliance braucht, sollte das aktuelle C5-Testat beim AWS Compliance-Team direkt anfragen.
Mehr aus dem MBF Media Netzwerk
Foto: Pexels
Quelle Titelbild: Pexels / panumas nikhomkhai (px:17323801)
