Amazon S3 Files: qué es, cómo funciona y cuándo usarlo en AWS

AWS acaba de presentar Amazon S3 Files, una novedad importante dentro del ecosistema de almacenamiento cloud. La idea es potente: hacer que un bucket de S3 sea accesible como un file system para las cargas de trabajo que necesitan trabajar con archivos, directorios, permisos y operaciones típicas de un sistema de archivos.

En otras palabras, S3 sigue siendo S3, pero ahora ciertos workloads pueden consumir esos datos con una experiencia mucho más cercana a la de un sistema de archivos tradicional. Esto abre una puerta muy interesante para aplicaciones interactivas, pipelines de machine learning, entornos compartidos y nuevos escenarios de IA agentic en AWS.

¿Qué es exactamente Amazon S3 Files?

Amazon S3 Files es un servicio que conecta recursos de cómputo de AWS directamente con los datos almacenados en Amazon S3 mediante una interfaz de sistema de archivos compartido. Así, un bucket general purpose puede montarse y utilizarse como si fuera un file system desde servicios como Amazon EC2, contenedores en Amazon ECS o Amazon EKS, e incluso funciones AWS Lambda.

La gran diferencia frente al enfoque tradicional es que ya no tienes que elegir tan claramente entre las ventajas del object storage y la comodidad de un file system. Con S3 Files, AWS intenta reducir esa fricción para workloads que necesitan trabajar con archivos de forma compartida y mutable.

¿Cómo funciona S3 Files por debajo?

Aunque hacia fuera parece un sistema de archivos, por debajo S3 Files sigue apoyándose en Amazon S3 como repositorio central de datos. AWS añade una capa de high-performance storage para mantener activos los datos y metadatos que más se usan, de forma que el acceso a los ficheros activos tenga baja latencia.

• Los archivos activos pueden servirse con latencias muy bajas.
• Las lecturas grandes y secuenciales pueden servirse directamente desde S3 para maximizar throughput.
• La sincronización funciona en ambos sentidos: los cambios del file system se exportan al bucket y los cambios directos en S3 se reflejan después en el file system.
• Los datos fríos pueden salir de la capa rápida sin desaparecer del bucket.

Este diseño intenta equilibrar coste, rendimiento y simplicidad operativa sin que tengas que mover datasets manualmente entre dos mundos distintos.

Qué problema intenta resolver

Hasta ahora, muchas arquitecturas se encontraban con una disyuntiva muy típica:

• Guardar los datos en S3 por precio, durabilidad y ecosistema.
• O duplicarlos en EFS, FSx u otro file system para que las aplicaciones pudieran tratarlos como archivos.

Esa duplicación implicaba más coste, más complejidad y procesos extra de sincronización. S3 Files nace precisamente para reducir ese problema y convertir S3 en hub central de datos también para workloads basados en archivos.

Casos de uso donde S3 Files tiene mucho sentido

Esta novedad encaja especialmente bien en escenarios donde varios recursos de cómputo necesitan acceder a los mismos datos como archivos, pero la empresa quiere seguir usando S3 como origen central.

• Pipelines de machine learning que leen y transforman datasets compartidos.
• Sistemas de IA agentic que usan librerías, scripts y herramientas que esperan rutas de archivos.
• Aplicaciones interactivas que modifican ficheros desde varios nodos.
• Clusters de procesamiento que necesitan compartir datos sin duplicación.
• Migraciones parciales de flujos basados en NAS hacia una arquitectura más cloud-native.

En todos estos casos, el valor real está en poder trabajar con datos jerárquicos y compartidos sin perder la base operativa de S3.

Qué no es S3 Files

Aquí conviene ser muy claro: S3 Files no significa que ahora S3 sustituya automáticamente a todos los file systems de AWS. Tampoco implica que sea la mejor opción para cualquier workload con archivos.

Si una aplicación necesita compatibilidad muy específica de NAS empresarial, semánticas avanzadas concretas o una plataforma de alto rendimiento especializada para entornos muy concretos, servicios como Amazon FSx pueden seguir siendo más adecuados. Del mismo modo, no hay que asumir que cualquier workload sensible a muchísimas operaciones pequeñas vaya a salir siempre barato.

¿S3 Files reemplaza a EFS o FSx?

No exactamente. La mejor forma de verlo es esta:

• S3 Files: ideal cuando tus datos ya viven en S3 y quieres acceso compartido como sistema de archivos sin duplicar datasets.
• Amazon EFS: muy útil cuando necesitas un file system elástico nativo para Linux compartido entre instancias y contenedores, sin girar alrededor de un bucket S3.
• Amazon FSx: mejor cuando necesitas capacidades concretas de sistemas como Windows File Server, NetApp ONTAP, OpenZFS o Lustre para HPC y cargas especializadas.

La decisión correcta depende del patrón de acceso, el tipo de aplicación, la sensibilidad a latencia, la compatibilidad requerida y, sobre todo, del punto de verdad donde quieres que viva el dato.

Rendimiento: lo más importante que debes entender

AWS posiciona S3 Files para acceso interactivo y compartido, con una estrategia de lectura inteligente. Los archivos pequeños y activos pueden servirse desde la capa rápida con baja latencia, mientras que las lecturas secuenciales grandes se sirven directamente desde S3 para aprovechar throughput alto.

Esto significa que el comportamiento del sistema depende bastante del patrón de acceso. No es lo mismo navegar directorios y editar ficheros activos que lanzar millones de pequeñas operaciones desordenadas sin planificación. Por eso, entender bien el workload será clave antes de adoptarlo en producción.

Sincronización: una ventaja potente, pero con matices

Uno de los puntos más atractivos de S3 Files es que sincroniza cambios entre el file system y el bucket. Cuando modificas archivos desde el sistema montado, AWS exporta esos cambios hacia S3. Cuando cambias objetos directamente en el bucket, el file system termina reflejándolos.

Pero esto no debe interpretarse como sincronización instantánea absoluta en todos los casos. En arquitectura cloud, siempre conviene diseñar teniendo en cuenta los tiempos de propagación y los detalles de consistencia del servicio, especialmente si varias aplicaciones tocan el mismo dataset por rutas distintas.

Seguridad y control de acceso

AWS integra S3 Files con IAM para políticas de acceso y con cifrado en tránsito y en reposo. Además, el servicio trabaja con permisos POSIX para archivos y directorios, usando UID y GID almacenados como metadatos del objeto.

• IAM para control de acceso a nivel de identidad y recurso.
• TLS 1.3 para cifrado en tránsito.
• SSE-S3 o AWS KMS para cifrado en reposo.
• CloudWatch y CloudTrail para observabilidad y auditoría.

Para equipos que trabajan con datos sensibles, esto lo convierte en una opción seria dentro de una arquitectura bien gobernada.

Costes: ojo, no es solo “usar S3 y ya”

Aquí está uno de los puntos más importantes del artículo. S3 Files no significa almacenamiento gratis por montar un bucket. AWS factura por la parte de datos que reside en la capa de high-performance storage y por las operaciones del file system, además de las solicitudes S3 involucradas en la sincronización.

En la práctica, esto obliga a pensar bien en los accesos. Si tu workload genera muchísimas operaciones pequeñas, movimientos frecuentes o renombrados masivos, el coste puede crecer más de lo esperado. Por eso AWS recomienda optimizar tamaños de I/O y comprender cómo se mide cada operación.

Cuándo sí lo usaría

• Cuando los datos ya viven en S3 y no quiero duplicarlos en otro servicio.
• Cuando varias aplicaciones o nodos necesitan acceso compartido a archivos.
• Cuando el workload mezcla jerarquía de archivos con integración directa en AWS.
• Cuando necesito acelerar escenarios de ML, analítica o IA basados en archivos.

Cuándo tendría cuidado o elegiría otra opción

• Si necesito capacidades muy específicas de FSx o de NAS empresarial.
• Si el patrón de acceso es extremadamente sensible a latencia en operaciones muy concretas.
• Si la aplicación hace muchísimos renames, movimientos o pequeñas escrituras que pueden encarecer el uso.
• Si realmente no necesito compartir datos como archivos y con S3 nativo ya me basta.

Puesta en marcha rápida

El flujo básico de adopción es bastante directo:

1. Crear el file system vinculado al bucket S3.
2. Crear o revisar los mount targets dentro de la VPC.
3. Montarlo desde una instancia EC2 o desde el runtime correspondiente.
4. Trabajar con los archivos usando comandos estándar del sistema operativo.

Un detalle práctico importante es verificar que la instancia tenga la versión reciente de amazon-efs-utils, porque el helper de montaje forma parte de ese paquete.

Mi lectura como arquitecto cloud

Amazon S3 Files me parece uno de esos lanzamientos que no solo añade una función nueva, sino que cambia una conversación entera dentro de AWS. Durante años, una de las explicaciones básicas en cloud era separar mentalmente object storage y file system como dos mundos claramente distintos. Con S3 Files, AWS no elimina esa diferencia, pero sí la hace mucho más flexible.

Para equipos de plataforma, datos, MLOps y DevOps, esto puede simplificar arquitecturas, reducir silos y evitar sincronizaciones caseras entre servicios. Pero como casi siempre en cloud, la clave no es enamorarse de la novedad: la clave es mapear bien el patrón real del workload.

Conclusión

Amazon S3 Files es una de las novedades de almacenamiento más interesantes de AWS en 2026. Permite usar Amazon S3 como fuente central de datos y, al mismo tiempo, ofrecer una experiencia de sistema de archivos compartido para cargas que lo necesitan.

No reemplaza automáticamente a EFS o FSx, pero sí crea un punto intermedio muy potente para workloads donde antes había fricción, duplicación o demasiada complejidad. Bien utilizado, puede simplificar mucho la arquitectura. Mal evaluado, puede introducir costes y expectativas equivocadas.

La mejor forma de verlo es esta: S3 Files no cambia lo que es S3, pero cambia mucho lo que ahora puedes hacer con S3.