Amazon S3 für TYPO3

aus_driver_amazon_s3 ist die Standard-Lösung, wenn TYPO3 Assets nicht mehr auf dem Webserver liegen dürfen - die Extension bringt S3-Buckets als vollwertigen FAL-Treiber in den TYPO3-Stack

Ein klassisches TYPO3-Setup speichert alle Mediendaten unter fileadmin auf dem Webserver. Das funktioniert, solange das Projekt auf einer einzigen Maschine läuft und der Speicher ausreicht. Sobald aber Multi-Server-Setups, Container-Cluster, Auto-Scaling oder Content Delivery Networks ins Spiel kommen, bricht dieses Modell. Jede Instanz bräuchte eine identische Kopie aller Dateien, Synchronisierung wird zur Dauerbaustelle, Deployments werden langsam. aus_driver_amazon_s3 löst das, indem es Amazon S3 als externe FAL-Storage einbindet. Dateien liegen im Bucket, TYPO3 liest und schreibt sie über die S3-API, und jede Server-Instanz greift auf denselben konsistenten Datenbestand zu. Für Projekte mit Hochverfügbarkeits-Anforderungen ist das der Standard-Weg.

Neben der technischen Notwendigkeit für Multi-Server-Setups gibt es einen zweiten wichtigen Treiber: Backup und Redundanz. S3 speichert jede Datei automatisch mehrfach über verschiedene Rechenzentren verteilt und erreicht damit eine Datenhaltung, die ein klassischer Webserver nicht garantieren kann. Für Unternehmen, deren Mediendaten geschäftskritisch sind, ist das allein ein Grund, auf S3 zu wechseln.

Typische Einsatzszenarien

Der erste Fall sind Cloud-Native-Deployments auf AWS, Kubernetes oder Docker Swarm. TYPO3 läuft in mehreren Containern hinter einem Load Balancer, jeder Container ist zustandslos. fileadmin als lokales Verzeichnis würde bedeuten, dass Uploads nur auf einem Container landen und die anderen sie nicht sehen. aus_driver_amazon_s3 hält den Asset-Bestand zentral und macht Scale-out erst praktikabel.

Der zweite Fall sind Projekte mit sehr großen Datenmengen. Eine Medien-Plattform, ein Bild-Archiv oder ein Download-Portal wächst schnell auf mehrere hundert Gigabyte oder Terabyte. Lokaler Server-Speicher wird teuer und unflexibel, S3 skaliert transparent und kostet nur, was wirklich belegt ist. Die Anbindung über FAL erlaubt dabei, ohne Code-Änderungen in TYPO3 auf den neuen Storage zu wechseln.

Dritter Einsatz: CDN-Integration. Wer Bilder und Downloads über Cloudfront, Cloudflare oder ein eigenes CDN ausliefern will, nutzt S3 als Origin. aus_driver_amazon_s3 macht die Dateien direkt im Bucket verfügbar, TYPO3 generiert die korrekten URLs und das CDN cached sie global. Das verbessert Ladezeiten für internationale Besucher messbar.

Technische Architektur

aus_driver_amazon_s3 implementiert das FAL-Driver-Interface von TYPO3 und nutzt das offizielle AWS SDK for PHP für die Kommunikation mit S3. Jeder Bucket wird als eigene “File Storage” im TYPO3-Backend eingerichtet, mit Angabe von Bucket-Name, Region, Access Key und Secret Key. Alternativ lassen sich IAM-Rollen verwenden, wenn TYPO3 auf einer EC2-Instanz oder in einem ECS-Task läuft - das ist sauberer, weil keine statischen Credentials in der Konfiguration stehen.

Die Extension unterstützt sowohl Amazon S3 als auch S3-kompatible Services wie MinIO, Backblaze B2, DigitalOcean Spaces oder Scaleway Object Storage. Für Projekte, die aus Datenschutz-Gründen nicht bei AWS liegen können, ist diese Flexibilität wichtig - ein europäischer S3-kompatibler Provider verhält sich aus TYPO3-Sicht genauso wie der AWS-Dienst.

Im laufenden Betrieb liest und schreibt TYPO3 direkt gegen S3. Die Processed Files - also die zugeschnittenen und optimierten Bildvarianten - werden standardmäßig ebenfalls im Bucket gespeichert. Alternativ kann ein lokales Verzeichnis für Processed Files konfiguriert werden, was die Bildverarbeitung beschleunigt, weil GIFBUILDER nicht jedes Quellbild erst aus S3 ziehen muss.

Die Konfiguration erfolgt über das Backend-Modul “File Storages” und ergänzende TypoScript-Einstellungen für die Bucket-URL und CDN-Präfixe. Entwickler müssen zusätzlich die AWS-SDK-Dependency per Composer installieren und die richtigen Berechtigungen am Bucket setzen.

Häufige Probleme und Lösungen

Das erste Problem ist die Performance bei großen Bilderlisten. Wenn eine Seite dutzende Bilder gleichzeitig zuschneiden muss und die Quelldateien aus S3 gezogen werden, dauert der Seitenaufbau spürbar länger. Die Lösung liegt in einem lokalen Cache für Processed Files, eventuell kombiniert mit einem Pre-Warming-Skript, das nach neuen Uploads die gängigsten Varianten vorab erzeugt.

Zweites Problem: Berechtigungsfehler beim Upload. Wenn TYPO3 in den Bucket schreiben will, aber die IAM-Policy nur Lesezugriff erlaubt, bricht der Upload mit einer kryptischen Fehlermeldung ab. Die Lösung ist eine präzise Policy mit s3:GetObject, s3:PutObject, s3:DeleteObject und s3:ListBucket für genau den TYPO3-Bucket, idealerweise begrenzt auf einen Präfix, damit andere Anwendungen auf demselben Bucket nicht versehentlich betroffen sind.

Drittes Problem: Datenschutz und Regionen-Wahl. Projekte, die DSGVO-konform arbeiten müssen, sollten AWS-Regionen in der EU wählen - typischerweise eu-central-1 in Frankfurt oder eu-west-1 in Irland. Für höhere Anforderungen oder Kunden, die AWS grundsätzlich ausschließen, ist ein europäischer S3-kompatibler Provider wie Hetzner, IONOS oder Scaleway der passende Weg. Die Extension arbeitet mit all diesen Providern.

Migration und Versions-Kompatibilität

aus_driver_amazon_s3 ist mit TYPO3 v11, v12 und v13 kompatibel und wird aktiv weiterentwickelt. Bei Upgrades ist die Version des AWS SDK zu beachten - neuere TYPO3-Versionen erfordern oft aktuelle SDK-Versionen, die wiederum PHP 8.1 oder höher voraussetzen.

Eine Migration von lokalem fileadmin zu S3 ist ein klar abgrenzbares Projekt: Dateien initial per aws s3 sync in den Bucket kopieren, im TYPO3-Backend eine neue File Storage einrichten, bestehende sys_file-Datensätze per Skript auf die neue Storage umbiegen, lokale Dateien nach erfolgreichem Test löschen. Die Extension bringt keine fertige Migrations-Routine mit, weil die genaue Vorgehensweise projektspezifisch ist.

Im Bestand gilt vor der Migration die Pflicht zur Inventarisierung. Wie viele Dateien liegen im fileadmin, wie groß ist der Datenbestand, welche davon sind verwaist und welche tatsächlich noch verlinkt? Oft stellt sich bei solchen Audits heraus, dass ein Großteil der Altdaten nie wieder aufgerufen wird und sich die Migration auf die aktiv genutzten Dateien beschränken lässt. Das reduziert Risiko, Aufwand und Bucket-Kosten.

Gosign begleitet S3-Migrationen für TYPO3-Projekte und konzipiert Multi-Cloud-Architekturen, die Datenschutz-Anforderungen und Performance-Ziele gleichzeitig erfüllen.