S3 Files und das sich wandelnde Gesicht von S3

• Um die Ineffizienz großer Datenverschiebungen zu verringern, wurde S3 Files eingeführt, das direkten Zugriff auf S3-Daten wie auf ein Dateisystem ermöglicht
• Diese Funktion integriert Amazon EFS und S3 und erlaubt es, S3-Buckets per NFS zu mounten und von EC2, Containern, Lambda usw. aus zu lesen und zu schreiben
• Intern nutzt es eine Stage-und-Commit-Struktur, um Änderungen periodisch in S3 zu übernehmen, und unterstützt bidirektionale Synchronisierung zwischen Dateien und Objekten
• Zusammen mit S3 Tables und S3 Vectors ist S3 Files eine Schlüsselkomponente, um S3 zu einer integrierten Datenplattform auszubauen
• S3 entwickelt sich damit über einen reinen Speicher hinaus zu einem integrierten, datenorientierten Arbeitsraum und schafft die Grundlage dafür, dass Entwickler Daten direkt nutzen können

---

Der Wandel von S3 und das Design von S3 Files

• Die Schwierigkeit der Datenbewegung und der Ausgangspunkt von S3 Files

  • Das Verschieben großer Datenmengen ist von der wissenschaftlichen Forschung bis zum Machine Learning in vielen Branchen eine dauerhafte Quelle von Ineffizienz
  • Im Beispiel der Genomforschung an der UBC verbrachten Forscher viel Zeit mit Kopiervorgängen zwischen S3 und lokalen Dateisystemen
  • Diese Datenreibung (data friction) entsteht, weil Werkzeuge auf unterschiedliche Weise auf Daten zugreifen
  • S3 Files wurde entwickelt, um diese Reibung zu verringern und direkten Zugriff auf S3-Daten wie auf ein Dateisystem zu ermöglichen

• Agentenbasierte Entwicklung und die Bedeutung von Daten

  • Durch den Fortschritt bei agentic tooling steigen Geschwindigkeit und Vielfalt der Anwendungsentwicklung sprunghaft an
  • Da die Hürden für das Schreiben von Code sinken, entsteht ein Umfeld, in dem Domänenexperten selbst Anwendungen entwickeln können
  • Die Lebensdauer von Anwendungen wird kürzer, während Daten als langfristig verbleibender Kernbestandteil an Bedeutung gewinnen
  • Storage darf nicht nur ein Speicherort sein, sondern muss eine Abstraktionsschicht werden, die Daten von Anwendungen trennt und ihre dauerhafte Nutzung ermöglicht

Neue Datenprimitive in S3

• S3 Tables

  • Um strukturierte Daten zu verarbeiten, hat S3 die auf Apache Iceberg basierenden S3 Tables eingeführt
  • Unter Beibehaltung der Funktionen von Iceberg werden Schutz der Datenintegrität, automatische Kompaktierung (compaction), regionsübergreifende Replikation und mehr geboten
  • Derzeit sind mehr als 2 Millionen Tabellen in S3 Tables gespeichert, und zahlreiche Anwendungen bauen darauf auf

• S3 Vectors

  • Mit dem Fortschritt der KI steigt die Nachfrage nach Vektorindizes
  • Bestehende Vektordatenbanken speichern Indizes in Arbeitsspeicher oder auf SSDs, was Kosten- und Skalierungsgrenzen mit sich bringt
  • S3 Vectors bietet vollständig elastische Vektorindizes mit einem Kosten-, Performance- und Haltbarkeitsprofil, das S3-Objekten ähnelt
  • Es skaliert von Hunderten bis zu Milliarden Datensätzen und bietet API-Endpunkte für die Ähnlichkeitssuche (scalar similarity search)

Das Erscheinen von S3 Files

• Überblick

  • S3 Files integriert Amazon EFS in S3 und ermöglicht so direkten Zugriff auf S3-Daten wie auf ein Netzwerkdateisystem (NFS)
  • Von EC2, Containern, Lambda usw. aus lassen sich S3-Buckets oder Präfixe mounten und wie Dateien lesen und schreiben
  • Änderungen werden automatisch in S3 übernommen und unterstützen so die bidirektionale Synchronisierung zwischen Dateien und Objekten

• Die schwierigen Designfragen

  • Dateisysteme und Objektspeicher haben grundlegend unterschiedliche Datenmodelle
  • Anfangs wollte man EFS und S3 einfach zusammenführen, doch am Ende blieben nur „unpalatable compromises“
  • Dateien unterstützen feingranulare Änderungen und gleichzeitigen Zugriff, während Objekte auf Unveränderlichkeit und Updates ganzer Einheiten ausgelegt sind
  • Das Event-Notification-System von S3 verarbeitet über 300 Milliarden Benachrichtigungen pro Tag und arbeitet auf Basis von Änderungen auf Objektebene

Die Designprinzipien von Stage and Commit

• Grenzen in eine Funktion verwandeln

  • Der Unterschied zwischen Dateien und Objekten wird nicht verborgen, sondern als explizite Grenze entworfen
  • Änderungen werden in EFS gestaged (temporär gespeichert) und in regelmäßigen Abständen committet, um in S3 übernommen zu werden
  • Dieser Ansatz ist vom Versionsverwaltungskonzept von Git inspiriert und ermöglicht eine zeit- und richtlinienbasierte Steuerung des Datentransfers

• Konsistenz und Atomarität

  • Die atomaren Operationen des Dateisystems (rename, move) und die objektweiten Updates von S3 werden parallel unterstützt
  • Durch die Trennung der beiden Ebenen bleibt das jeweilige Konsistenzmodell erhalten, während zugleich eine einheitliche Datensicht bereitgestellt wird

• Berechtigungsverwaltung

  • Die IAM-Richtlinien von S3 und die inode-basierten Berechtigungen eines Dateisystems unterscheiden sich strukturell
  • S3 Files trennt diese beiden Systeme durch Berechtigungsvergabe pro Mount
  • Die IAM-Richtlinien von S3 bleiben als ultimativer Backstop bestehen, sodass sich der Zugriff bei Veränderungen der Datengrenzen kontrollieren lässt

• Abweichende Namensräume

  • S3 kennt kein Verzeichniskonzept, und auch Pfadtrenner (delimiter) können frei gewählt werden
  • Um die Diskrepanz zum Dateisystem zu lösen, werden die Benennungsregeln beider Seiten unverändert beibehalten
  • Nicht kompatible Objekte werden nicht verschoben; stattdessen werden Events ausgelöst, damit Entwickler sie behandeln können

• Performance und Latenz

  • Dateisysteme sind auf metadatenzentrierten Zugriff optimiert, S3 auf groß angelegten parallelen Zugriff
  • Da die meisten Workloads nicht gleichzeitig auf Dateien und Objekte zugreifen, ist die Beibehaltung einer Synchronisierungsschicht realistischer als eine vollständige Verschmelzung der Modelle
  • Die Dateiansicht behält NFS-Konsistenz, die Objektsicht starke S3-Konsistenz, und die Synchronisierungsschicht verbindet beide

So funktioniert S3 Files

• Grundstruktur

  • S3 Files nutzt EFS als Backend und bietet so ein Dateisystem-Erlebnis
  • Beim Zugriff auf Verzeichnisse werden S3-Metadaten geladen, um eine synchronisierte Sicht zu erzeugen; Dateien bis 128 KB laden auch die Daten sofort
  • Große Dateien werden per lazy hydration erst bei Bedarf geladen
  • Änderungen werden etwa alle 60 Sekunden per einem einzigen PUT nach S3 committet, wobei eine bidirektionale Synchronisierung erfolgt

• Konflikte und Verwaltung

  • Bei gleichzeitigen Änderungen auf beiden Seiten gilt S3 als Source of Truth
  • Konfliktdateien werden in das Verzeichnis lost+found verschoben und über CloudWatch-Metriken protokolliert
  • Dateien, auf die 30 Tage lang nicht zugegriffen wurde, werden aus der Dateisystemansicht entfernt, um Kosten zu optimieren

• Performance-Optimierung

  • Über die Funktion read bypass wird bei großen sequenziellen Lesevorgängen direkt mit parallelen GET-Anfragen aus S3 gelesen

    • Es werden 3 GB/s Durchsatz pro Client erreicht; mit mehreren Clients ist Skalierung im Terabit-Bereich möglich

• Grenzen und geplante Verbesserungen

  • Da S3 keine native rename-Operation besitzt, erfordern Verzeichnisumbenennungen das vollständige Kopieren und Löschen
  • Bei Mounts mit mehr als 50 Millionen Objekten wird eine Warnung angezeigt
  • Explizite Commit-Steuerung ist in der ersten Version nicht enthalten
  • Einige Objektschlüssel lassen sich nicht als POSIX-Dateinamen darstellen und werden deshalb aus der Dateiansicht ausgeschlossen

Datenvielfalt und die Weiterentwicklung von S3

• Koexistenz verschiedener Datenzugriffsarten

  • Wie das UBC-Forschungsbeispiel zeigt, verbringen Entwickler viel Zeit mit Datenverschiebung, Caching und Namensverwaltung
  • Das S3-Team unterstützt mit Tables, Vectors und Files integriert unterschiedliche Arten des Datenzugriffs
  • Statt die Unterschiede zwischen Dateien und Objekten zu beseitigen, werden ihre jeweiligen Eigenschaften anerkannt und ihre Grenzen funktional nutzbar gemacht

• Die erweiterte Rolle von S3

  • S3 entwickelt sich von einem einfachen Objektspeicher zu einer integrierten Storage-Plattform für unterschiedliche Datenformen
  • Mit Tables, Vectors und Files können Daten direkt entsprechend der jeweiligen Arbeitsweise genutzt werden
  • Das Ziel ist, dass Storage kein Hindernis für die Arbeit, sondern eine transparente Basisinfrastruktur wird
  • Künftig sollen Funktionen wie Stage-/Commit-Steuerung und Pipeline-Integration weiter ausgebaut werden

• Fazit

  • S3 Files kombiniert die Vorteile beider Seiten und wahrt dabei die explizite Grenze zwischen Dateien und Objekten
  • S3 begann vor 20 Jahren als Objektspeicher und entwickelt sich nun zu einem integrierten, datenorientierten Arbeitsraum
  • Wie die Botschaft „Go build!“ andeutet, etabliert sich S3 als Grundlage, mit der Entwickler schneller mit Daten experimentieren und darauf aufbauen können

[xguru]

Ah, jetzt ist es wirklich praktisch, weil „Lesenswerte weiterführende Artikel“ die passenden offiziellen Beiträge gut verknüpft.
Ich habe immer überlegt, wie man es am besten handhabt, wenn es einen Einführungsartikel und den offiziellen Beitrag getrennt gibt,
und es freut mich, dass „Lesenswerte weiterführende Artikel“ so gut funktioniert .. haha

S3 entwickelt sich jetzt zu einer Datenplattform weiter, die Dateien, Tabellen und Vektoren gleichermaßen umfasst.

Es fühlt sich so an, als würde S3, der Ausgangspunkt moderner Cloud-Infrastruktur, nach 20 Jahren noch einmal neu definiert.

[rtyu1120]

S3 teilt die Dateistruktur zwar nicht transparent, aber es gibt auch Open Source wie ZeroFS, das S3 als Datenbank nutzt und darauf ein POSIX-konformes Dateisystem betreibt. Die Demo, PostgreSQL auf S3 zu betreiben, war ziemlich beliebt.

https://www.zerofs.net/

[rtyu1120]

Es gibt auch einen Beitrag von Archil, einem Startup, das von einem ehemaligen S3-Ingenieur gegründet wurde und in dem das eigene Produkt damit verglichen wird — macht zusammen gelesen auch Spaß.

https://x.com/jhleath/status/2042613823522377933

[GN⁺]

Hacker-News-Kommentare

• Das ist im Grunde eine Konstruktion, die S3FS verwendet und EFS (AWS’ verwalteten NFS-Dienst) als Cache-Schicht für aktive Daten und kleine Random-Access-Zugriffe nutzt
  Das Problem ist, dass damit auch das teure Preismodell von EFS übernommen wird
  — Alle Schreibvorgänge kosten $0.06 pro GB, was für schreibintensive Workloads verheerend sein kann
  — Für Lesezugriffe aus dem Cache werden $0.03 pro GB berechnet, während große Lesevorgänge über 128 KB kostenlos direkt aus dem S3-Bucket gestreamt werden
  — Der Cache kostet $0.30 pro GB und Monat, aber da dort meist nur kleine Dateien unter 128 KB dauerhaft gespeichert werden, dürften die Kosten nicht allzu hoch sein

  • Ich frage mich, ob es wirklich stimmt, dass große Datei-Lesevorgänge (>128 KB) immer am Cache vorbeigehen
    Die Latenz von S3 ist ziemlich schlecht, das macht mir Sorgen

• Die Formulierung „NFS provides the semantics your applications expect“ war mit Abstand das Lustigste, was ich bisher gesehen habe

  • Anwendungen erwarten nicht, dass schon ein einzelner Netzwerkausfall dazu führt, dass System-Calls unendlich blockieren und das Dateisystem sich nicht mehr unmounten lässt

• Hugging Face Buckets hat kürzlich ebenfalls eine Funktion hinzugefügt, mit der sich Buckets wie ein Dateisystem mounten lassen
  hf-mount Changelog

• Mich hat der Teil zur Synchronisierung interessiert
  Laut der AWS-Dokumentation
  wird, wenn man /mnt/s3files/report.csv bearbeitet und dann eine andere Version in den S3-Bucket hochgeladen wird, bei einem Konflikt meine Version in das Verzeichnis .s3files-lost+found-file-system-id verschoben und durch die Bucket-Version ersetzt
  Das heißt, es gibt bei Konflikten ein automatisches Recovery-Verzeichnis

• FiberFS ist fast bei der ersten offiziellen Release-Version angekommen
  Es bietet integrierten Cache, CDN-Kompatibilität, JSON-Metadaten, Concurrency-Sicherheit und richtet sich an alle S3-kompatiblen Storage-Systeme

  • Ich frage mich, wie es sich im Vergleich zu Amazons eigener FUSE-Implementierung schlägt. Inzwischen gibt es schon die dritte Version

• Es wäre schön, wenn AWS eine verwaltete Bridging-Lösung mit lokalem NVMe-Storage anbieten würde
  NVMe ist viel schneller als EBS, und EBS ist schneller als EFS
  Mit einer Cache-Schicht auf NVMe dürfte man ziemlich gute Geschwindigkeit erreichen, aber eine vollständig integrierte Option wäre noch besser

  • Wenn EFS nur ein einfacher NFS-Mount ist, könnte man das womöglich auch selbst bauen, indem man ein NVMe-Volume anhängt und cachefilesd konfiguriert
    Zum Beispiel

    mkfs.ext4 /dev/nvme0n1 && \
    mount /dev/nvme0n1 /var/cache/fscache && \
    mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
    

    So könnte es vielleicht direkt funktionieren
    Im Grunde sind das nur drei Zeilen Kommandozeile, aber genau so etwas als Managed Service anzubieten, ist sehr AWS-typisch

• Ich dachte, AWS hätte früher gesagt, man solle S3 nicht als Dateisystem verwenden. Ich frage mich, warum sie jetzt ihre Haltung geändert haben

  • Diesmal scheint es eine Struktur zu sein, bei der vor S3 ein echtes Dateisystem (EFS) liegt und eine transparente Synchronisierung stattfindet
    Im Blog werden auch Hinweise zu Konsistenzproblemen oder der Behandlung von Objektnamen erwähnt
    Als S3-Fan finde ich dieses Design einen ziemlich guten Kompromiss
  • Architekten großer Unternehmenskunden haben S3 schon seit Langem wie ein Dateisystem genutzt
    Der Druck durch Support-Tickets bei AWS und die ständigen „Warum geht das nicht?“-Anfragen haben sich wohl aufgestaut und am Ende zu dieser Richtung geführt
    Persönlich gefällt mir dieser Ansatz nicht besonders, weil er sich anfühlt wie „im Kern etwas anderes, nur neu verpackt“, aber es wirkt wie ein Fall von sozialem Druck durch $$$
  • Das sieht nach einer Strategie aus, auch Nutzer mit geringerer technischer Kompetenz anzusprechen
    So kann man auch Leute, die Tools wie „S3asYourFS.exe“ benutzen, zu AWS-Kunden machen
    Wenn man allerdings an die Support-Fähigkeiten von AWS denkt, ist fraglich, ob das eine kluge Entscheidung ist
    Trotzdem war die Versuchung groß, mehr monatlich zahlende Nutzer zu gewinnen
  • Wenn die Leute S3 ohnehin wie ein Dateisystem verwenden werden, ist es vermutlich besser, das offiziell zu unterstützen
  • Am Ende hat AWS einfach einen Ertragsmechanismus geschaffen, indem es einen Cache davorschaltet
    Für die Nutzer steigt die Performance, und AWS reduziert die Last
    Ob man damit Geld spart oder nicht, ist eine andere Frage

• Ich frage mich, was passiert, wenn man darauf eine SQLite-Datenbank speichert
  Wahrscheinlich wären höchstens schreibgeschützte Replikate möglich, und Backups wie mit Litestream eher nicht

  • Der Lock-Mechanismus von SQLite ist auf NFS nicht sicher und funktioniert daher nicht

• Das Locking-Verhalten von NFS ist ohnehin schon kompliziert, und wenn man dazu noch ein entferntes S3-Backend mischt, dürfte das nur noch verwirrender werden

• Werner Vogels ist wirklich beeindruckend
  Ich bin ihm zum ersten Mal begegnet, als ich mich früher mit DynamoDB beschäftigt habe, und seitdem bin ich Fan