Amazon S3 para TYPO3

aus_driver_amazon_s3 es la solución estándar cuando los activos de TYPO3 ya no pueden estar en el servidor web, la extensión incorpora los buckets S3 como driver FAL de pleno derecho en el stack TYPO3

Una configuración TYPO3 clásica guarda todos los datos de media en fileadmin dentro del servidor web. Eso funciona mientras el proyecto corre en una única máquina y el almacenamiento es suficiente. Pero en cuanto entran en juego configuraciones multi-servidor, clústeres de contenedores, autoescalado o Content Delivery Networks, ese modelo se rompe. Cada instancia necesitaría una copia idéntica de todos los archivos, la sincronización se convierte en una obra permanente y los despliegues se vuelven lentos. aus_driver_amazon_s3 lo resuelve integrando Amazon S3 como storage FAL externo. Los archivos están en el bucket, TYPO3 los lee y los escribe mediante la API de S3, y cada instancia de servidor accede al mismo fondo de datos consistente. Para proyectos con requisitos de alta disponibilidad, ese es el camino estándar.

Junto a la necesidad técnica de las configuraciones multi-servidor hay un segundo motivador importante: backup y redundancia. S3 almacena cada archivo automáticamente de forma múltiple repartido entre distintos centros de datos y alcanza así una persistencia de datos que un servidor web clásico no puede garantizar. Para empresas cuyos datos media son críticos para el negocio, ese es ya por sí solo un motivo para cambiar a S3.

Escenarios típicos de uso

El primer caso son despliegues cloud-native en AWS, Kubernetes o Docker Swarm. TYPO3 corre en varios contenedores detrás de un balanceador de carga, cada contenedor es sin estado. fileadmin como directorio local significaría que las subidas acaban solo en un contenedor y los demás no las ven. aus_driver_amazon_s3 mantiene el inventario de activos central y hace practicable el scale out.

El segundo caso son proyectos con volúmenes de datos muy grandes. Una plataforma de medios, un archivo de imágenes o un portal de descargas crece rápido a varios cientos de gigabytes o terabytes. El almacenamiento local en servidor se vuelve caro y poco flexible, S3 escala de forma transparente y cuesta solo lo que realmente se ocupa. La conexión mediante FAL permite cambiar a nuevo storage sin cambios de código en TYPO3.

Tercer uso: integración con CDN. Quien quiera entregar imágenes y descargas a través de Cloudfront, Cloudflare o un CDN propio utiliza S3 como origen. aus_driver_amazon_s3 hace disponibles los archivos directamente en el bucket, TYPO3 genera las URLs correctas y el CDN las cachea globalmente. Eso mejora medible los tiempos de carga para visitantes internacionales.

Arquitectura técnica

aus_driver_amazon_s3 implementa el FAL Driver Interface de TYPO3 y utiliza el AWS SDK for PHP oficial para la comunicación con S3. Cada bucket se configura como “File Storage” propio en el backend de TYPO3, con indicación de nombre de bucket, región, Access Key y Secret Key. Alternativamente pueden usarse roles IAM si TYPO3 corre en una instancia EC2 o en una tarea ECS, lo que es más limpio porque no deja credenciales estáticas en la configuración.

La extensión soporta tanto Amazon S3 como servicios compatibles con S3 como MinIO, Backblaze B2, DigitalOcean Spaces o Scaleway Object Storage. Para proyectos que por motivos de protección de datos no pueden alojarse en AWS, esa flexibilidad es importante: un proveedor europeo compatible con S3 se comporta desde el punto de vista de TYPO3 exactamente como el servicio de AWS. La AEPD y otras agencias autonómicas de protección de datos advierten del uso de proveedores estadounidenses tras la sentencia Schrems II.

En operación, TYPO3 lee y escribe directamente contra S3. Los processed files, es decir, las variantes de imagen recortadas y optimizadas, se guardan por defecto también en el bucket. Alternativamente puede configurarse un directorio local para processed files, lo que acelera el procesamiento de imágenes porque GIFBUILDER no tiene que tirar primero cada imagen fuente desde S3.

La configuración se realiza mediante el módulo backend “File Storages” y ajustes TypoScript complementarios para la URL del bucket y los prefijos de CDN. Los desarrolladores deben además instalar la dependencia del AWS SDK mediante Composer y establecer los permisos correctos en el bucket.

Problemas frecuentes y soluciones

El primer problema es el rendimiento con listas de muchas imágenes. Cuando una página debe recortar docenas de imágenes simultáneamente y los archivos fuente se tiran de S3, el montaje de la página se alarga perceptiblemente. La solución está en un caché local para processed files, eventualmente combinado con un script de pre-warming que, tras nuevas subidas, genere por adelantado las variantes más habituales.

Segundo problema: errores de permisos al subir. Cuando TYPO3 quiere escribir en el bucket pero la IAM Policy solo permite lectura, la subida aborta con un mensaje de error críptico. La solución es una policy precisa con s3:GetObject, s3:PutObject, s3:DeleteObject y s3:ListBucket para exactamente el bucket de TYPO3, idealmente limitada a un prefijo para que otras aplicaciones sobre el mismo bucket no se vean afectadas por error.

Tercer problema: protección de datos y elección de región. Los proyectos que deben trabajar conforme al RGPD deberían elegir regiones AWS en la UE, típicamente eu-central-1 en Fráncfort o eu-west-1 en Irlanda. Para requisitos más altos o clientes que excluyan AWS por principio, un proveedor europeo compatible con S3 como Hetzner, IONOS o Scaleway es el camino adecuado. La extensión trabaja con todos esos proveedores.

Migración y compatibilidad de versiones

aus_driver_amazon_s3 es compatible con TYPO3 v11, v12 y v13 y se sigue desarrollando activamente. En los upgrades hay que atender a la versión del AWS SDK: las versiones más nuevas de TYPO3 suelen exigir versiones SDK actuales que, a su vez, requieren PHP 8.1 o superior.

Una migración de un fileadmin local a S3 es un proyecto claramente delimitable: copiar inicialmente los archivos al bucket mediante aws s3 sync, configurar una nueva File Storage en el backend de TYPO3, derivar mediante script los registros sys_file existentes al nuevo storage, eliminar los archivos locales tras una prueba exitosa. La extensión no trae una rutina de migración lista, porque el procedimiento concreto es específico del proyecto.

En proyectos existentes rige, antes de la migración, la obligación de inventariar. ¿Cuántos archivos hay en fileadmin, qué tamaño tiene el inventario, cuáles son huérfanos y cuáles siguen realmente enlazados? A menudo las auditorías revelan que una gran parte de los datos antiguos ya no se consulta y que la migración puede limitarse a los archivos usados activamente. Eso reduce riesgo, esfuerzo y costes de bucket.

Gosign acompaña migraciones S3 para proyectos TYPO3 y diseña arquitecturas multi-cloud que cumplen los requisitos de protección de datos y los objetivos de rendimiento simultáneamente.