6 Min. Tiempo de lectura
Amazon S3 Files está disponible de forma general desde el 7 de abril de 2026. La función permite montar buckets S3 directamente como un sistema de archivos compatible con NFS en EC2, EKS y Lambda, sin cambios en el código de las aplicaciones existentes. Para los equipos de DACH con cargas de trabajo heredadas, canalizaciones de ML y requisitos de almacenamiento compartido, esto cambia fundamentalmente las opciones de arquitectura.
Lo más importante en resumen
- Montaje NFS sin cambios en la aplicación: S3 Files proporciona un punto de montaje compatible con POSIX. Las aplicaciones existentes que trabajan con open(), read() y write() pueden acceder a S3 sin refactorización.
- 34 regiones, diferencia de precio significativa con respecto a EFS: El almacenamiento S3 cuesta 0,023 USD/GB/mes en estándar, EFS cuesta 0,30 USD/GB/mes en modo estándar. Para grandes conjuntos de datos de ML y puntos de control de modelos, el factor de costo es relevante.
- La latencia es el compromiso: Las operaciones de metadatos en S3 Files están entre 10-50ms, EFS está por debajo de 1ms. Las cargas de trabajo con muchas operaciones de archivo pequeñas (DB transaccionales, archivos de configuración pequeños con alta frecuencia) no son el escenario objetivo.
- Integración con EKS a través del controlador CSI: El controlador CSI de AWS S3 está actualizado y admite S3 Files como PersistentVolume. El acceso multi-Pod al mismo bucket es posible, lo cual es importante para configuraciones de entrenamiento distribuido.
RelacionadoBSI-KRITIS, NIS2 y C5: Verificación de cumplimiento de Multi-Cloud en la práctica 2026 / BYOD en la empresa alemana 2026
Qué hace técnicamente S3 Files – y qué no hace
¿Qué es Amazon S3 Files? S3 Files es una nueva característica de Amazon S3 que proporciona un punto de montaje de sistema de archivos compatible con POSIX para buckets S3 existentes. Bajo el capó, un servicio gestionado traduce llamadas POSIX en operaciones de API de S3. El resultado: una aplicación que lee /mnt/data/model.bin accede en realidad a s3://bucket/model.bin sin saberlo.
La base técnica es el agente S3 Files, un proceso sidecar que se ejecuta en la instancia EC2 o en el pod de Kubernetes. Se encarga de la traducción de POSIX a S3 y mantiene una caché de metadatos local. El agente está integrado en EKS a través del controlador CSI de AWS S3; para EC2 hay un paquete RPM y DEB. La compatibilidad con Lambda está disponible a través de capas de ejecución gestionadas.
Lo que S3 Files no es: un sistema de archivos POSIX completo. El bloqueo de archivos (flock/fcntl) no es compatible. Los enlaces simbólicos son de solo lectura. Las operaciones de cambio de nombre no tienen garantía atómica en caso de acceso concurrente. Para aplicaciones que dependen de estos primitivos – en particular, bases de datos SQL clásicas o sistemas de compilación con bloqueo de archivos – EFS sigue siendo la opción correcta.
Tres escenarios para equipos DACH
¿Para qué cargas de trabajo resulta realmente rentable S3 Files?
Entrenamiento de ML y servicio de modelos: Este es el escenario principal. Los datos de entrenamiento y los puntos de control del modelo ya se encuentran en S3. Con S3 Files, un trabajo de entrenamiento PyTorch puede leer los datos a través de /mnt/training-data, sin que el código necesite conocer S3. El acceso multi-pod al mismo bucket permite configuraciones de entrenamiento distribuido en SageMaker y EKS. La ventaja de costes frente a EFS es significativa en conjuntos de datos del orden de TiB: con 10 TiB de datos de entrenamiento, S3 Files ahorra aproximadamente 2.770 USD/mes frente a EFS Standard.
Aplicaciones heredadas con interfaz de sistema de archivos: Muchas aplicaciones antiguas en Java y C++ leen configuraciones y datos temporales desde el sistema de archivos local. Si el almacenamiento principal ya está en S3, S3 Files permite prescindir de una capa EFS adicional. Esto simplifica la arquitectura de despliegue, especialmente en migraciones Lift-and-Shift aún no refactorizadas.
Lambda y pipelines sin servidor: Hasta ahora, las funciones Lambda solo tenían EFS como sistema de archivos persistente. S3 Files es más económico. Para cargas de trabajo de Lambda que operan sobre datos de S3 (ETL, procesamiento de imágenes, transformaciones por lotes), el montaje directo es un acceso más natural que las llamadas a la API de S3 en el código.
Comparación de costes de opciones de almacenamiento (us-east-1)
$0,023
S3 Files / GB / mes (estándar)
$0,30
EFS Standard / GB / mes
$0,145
FSx for Lustre Scratch / GB / mes
„La función permite montar buckets de S3 directamente como un sistema de archivos compatible con NFS en EC2, EKS y Lambda – sin modificar el código de las aplicaciones existentes.»
Lo que cambia en EKS
Para los equipos de Kubernetes, el punto de entrada relevante es el driver AWS S3 CSI en la versión 1.10, que ofrece soporte para archivos S3. Un PersistentVolume con archivos S3 tiene este aspecto:
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 significa que varios pods pueden escribir simultáneamente en el mismo bucket. En el entrenamiento distribuido de ML con servidores de parámetros o en repositorios compartidos de modelos, esto representa una clara ventaja frente a un único volumen EBS que solo puede ser ReadWriteOnce.
Un consejo para los equipos de DACH bajo la GDPR: el bucket S3 debe estar ubicado en una región europea. Frankfurt (eu-central-1) y Estocolmo (eu-north-1) son completamente compatibles. El agente S3 Files se comunica exclusivamente con el endpoint regional de S3 — ningún dato sale de la región.
Cuándo EFS y FSx siguen siendo mejores
S3 Files no sustituye a EFS. Las diferencias de latencia son reales: en aplicaciones con muchas operaciones pequeñas y secuenciales en el sistema de archivos —servidores web clásicos, aplicaciones PHP que leen frecuentemente archivos de configuración, sistemas de compilación— EFS lleva claramente ventaja. Las operaciones de metadatos como stat() o listados de directorios son significativamente más lentas en S3 Files.
FSx for Lustre sigue siendo la mejor opción cuando se busca maximizar el ancho de banda —Lustre está diseñado para alto rendimiento paralelo, mientras que S3 Files no lo está. En cargas de trabajo muy grandes de ML (modelos de más de 100 GB, lecturas secuenciales intensivas), el sobrecoste de FSx sigue valiendo la pena.
S3 Files: adecuado para
- Entrenamiento de ML en conjuntos de datos grandes (>100 GB)
- Puntos de control de modelos y almacenamiento de artefactos
- Funciones Lambda con interfaz de sistema de archivos
- Aplicaciones heredadas en lift-and-shift sin refactorización
- Optimización de costos en cargas de trabajo intensivas en almacenamiento
Continúa siendo mejor EFS/FSx para
- Aplicaciones con requisitos de bloqueo de archivos
- Muchas operaciones pequeñas y secuenciales de metadatos
- Servidores web con lecturas frecuentes de configuración
- Archivos clásicos de bases de datos SQL
- Tráfico máximo (>10 GB/s por pod)
La pregunta decisiva es: ¿el almacenamiento principal del workload ya está en S3 —y la aplicación no necesita bloqueo de archivos? Entonces S3 Files es la opción más lógica. Si el almacenamiento está en EBS o EFS —¿la aplicación es muy sensible a la latencia? Entonces EFS sigue siendo la mejor opción.
Fuentes: Documentación de AWS S3 Files GA (abril de 2026), Calculadora de precios de AWS, Documentación de la sesión sobre S3 en AWS re:Invent.
Preguntas frecuentes
¿Es compatible S3 Files con todas las clases de almacenamiento de S3?
S3 Files es compatible con S3 Standard, S3 Intelligent-Tiering y S3 Standard-IA para operaciones de lectura y escritura. S3 Glacier y Glacier Deep Archive no pueden montarse directamente — los objetos en Glacier deben restaurarse primero. Para conjuntos de datos ML, AWS recomienda S3 Intelligent-Tiering como clase de almacenamiento estándar, ya que los patrones de acceso a los datos de entrenamiento varían.
¿Cómo se comporta S3 Files en implementaciones multi-región?
S3 Files solo monta buckets en la misma región que el punto de montaje. El acceso entre regiones no está directamente soportado. Si tienes cargas de trabajo distribuidas en múltiples regiones, necesitas utilizar S3 Replication para accesos de lectura o S3 Multi-Region Access Points como un nivel separado. Para equipos de Alemania, Austria y Suiza con eu-central-1 y eu-west-1 como regiones principales, este es un punto clave a considerar en implementaciones globales.
¿Necesita S3 Files permisos adicionales en comparación con el acceso normal a S3?
Sí. Además de los permisos estándar de S3 (GetObject, PutObject, DeleteObject), S3 Files necesita s3:ListBucket, s3:GetBucketLocation, y las nuevas acciones s3files:* para operaciones de metadatos. La política completa de IAM está documentada en la documentación de AWS bajo el título «S3 Files IAM Permissions». En el caso de políticas de menos privilegios, estos permisos deben añadirse explícitamente.
¿Puede S3 Files utilizarse en AWS GovCloud y en implementaciones soberanas de la UE?
S3 Files está disponible en AWS GovCloud (US-East y US-West). Para requisitos soberanos de la UE según BSI C5 y DSGVO: S3 Files opera en eu-central-1 (Fráncfort) y, por lo tanto, puede utilizarse bajo los marcos de protección de datos alemanes. AWS ha incluido S3 Files en el ámbito del procedimiento de certificación C5; la actualización de la certificación para 2026 estaba en proceso al momento del lanzamiento de GA. Quienes necesitan esto para cumplir con normativas CRITIS deberían solicitar directamente la certificación C5 actualizada al equipo de cumplimiento de AWS.
Más contenido del red MBF Media
Foto: Pexels
Fuente de la imagen de título: Pexels / panumas nikhomkhai (px:17323801)
