7 min. Tiempo de lectura
Con el lanzamiento de GA de Amazon S3 Files en abril de 2026, los arquitectos en la nube se enfrentan ahora a una elección triple en los sistemas de archivos de AWS. S3 Files permite integrar directamente los buckets S3 como puntos de montaje NFS — sin el costo adicional de EFS, pero con otros compromisos. ¿Cuándo es S3 Files la opción más económica? ¿Cuándo EFS aprovecha su fortaleza en almacenamiento multi-az? ¿Y cuándo FSx for Lustre sigue siendo la única opción razonable? Una matriz de decisiones para 2026.
Lo más importante en resumen
- S3 Files está disponible desde abril de 2026: es posible integrar buckets S3 como puntos de montaje NFS, con un modelo de precios S3 en lugar de cargos por rendimiento de EFS — muy atractivo para trabajos de análisis y trabajo por lotes.
- EFS sigue siendo líder en almacenamiento compartido multi-az: acceso simultáneo a escrituras desde múltiples zonas de disponibilidad, fuerte semántica POSIX, sin necesidad de gestión manual de capacidad.
- FSx for Lustre: imprescindible para HPC y entrenamiento de ML con latencias de sub-milisegundos — protocolo Lustre, stripes paralelos sobre varios servidores de almacenamiento, integración directa con S3 para la importación de datos.
- Comparativa de costos para 100 TB: S3 Files cuesta aproximadamente 230 USD/mes, frente a EFS General Purpose que cuesta alrededor de 3.100 USD/mes, y FSx Lustre que asciende a 4.500 USD/mes (ScratchFS 2) — siempre sin transferencia de datos.
- Criterio de decisión: patrones de acceso (escrituras aleatorias vs. lecturas secuenciales), requisitos de latencia y si se necesita consistencia multi-az.
RelacionadoMigración de Kubernetes 1.36: Lista de verificación empresarial cgroup-v2 + DRA-GA / Amazon Bedrock AgentCore: Cadena de herramientas CDK para agentes de producción
¿Qué es Amazon S3 Files? Amazon S3 Files es un servicio de AWS lanzado como General Availability en abril de 2026, que permite integrar buckets S3 como sistemas de archivos NFS v4.0 directamente en instancias EC2 — sin necesidad de una appliance intermedia ni de un servicio de sistema de archivos separado. Complementa a Amazon EFS y FSx como la tercera opción de sistemas de archivos gestionados en AWS.
Archivos S3: Lo que realmente significa el lanzamiento de GA
Amazon S3 Files no debe confundirse con el antiguo S3 File Gateway (anteriormente Storage Gateway NFS). La nueva función S3 Files permite montar directamente NFS desde buckets de S3 con S3 Express One Zone o buckets estándar como backend de almacenamiento. La diferencia clave respecto al File Gateway: ya no existe una appliance ni una VM on-premises — el punto de montaje se ejecuta completamente en la región de AWS como un servicio gestionado.
El modelo de precios sigue la lógica de S3: costes de almacenamiento según la tarifa de S3, cargos por solicitudes según las llamadas a la API. Para cargas de trabajo con predominio de lecturas, resulta más económico que EFS, que factura según la capacidad provisionada o utilizada más los cargos por throughput. En cargas de trabajo con muchas escrituras aleatorias pequeñas, el precio puede volverse rápidamente más caro de lo esperado — cada escritura es un S3-PUT.
Lo que S3 Files no puede hacer: bloqueo POSIX (bloqueos consultivos, sin bloqueos forzados por rango de bytes), tampoco ofrece garantía de consistencia fuerte ante accesos paralelos de escritura desde múltiples clientes. Para servidores web, bases de datos o aplicaciones que dependen de bloqueos POSIX, S3 Files queda descartado.
Comparación de costes: 100 TB de almacenamiento activamente utilizado (UE-Francfort, mayo de 2026)
~230 USD
S3 Files (S3 Standard, sin costes de solicitud)
~3.100 USD
EFS General Purpose (Elastic Throughput)
~4.500 USD
FSx for Lustre Scratch FS 2 (bloques de 1,2 TB)
Precios sin costes de transferencia de datos. FSx Lustre está diseñado para clústeres de scratch de corta duración — no para almacenamiento a largo plazo.
EFS: Cuándo justifica el sobreprecio
Amazon EFS justifica su sobrecoste gracias a una característica que S3 Files no ofrece: consistencia fuerte ante accesos paralelos de escritura desde múltiples zonas de disponibilidad. Quien tiene instancias EC2 en eu-central-1a, 1b y 1c escribiendo simultáneamente en el mismo sistema de archivos y necesita semántica POSIX, no tiene alternativa a EFS.
El segundo argumento a favor de EFS es de naturaleza operativa: no requiere planificación de capacidad. EFS crece y se reduce según el almacenamiento utilizado. Con S3 Files, hay que gestionar activamente los límites de bucket y las políticas de ciclo de vida. Para equipos sin un equipo dedicado de ingeniería de almacenamiento, EFS simplifica notablemente las operaciones.
Cargas típicas de EFS en 2026: almacenamiento compartido de contenedores para ECS y EKS (ReadWriteMany PVC), aplicaciones lift-and-shift que esperan NFS desde el centro de datos, sistemas de gestión de contenido con instancias paralelas de servidores web, entornos compartidos de herramientas de desarrollo.
„EFS es la elección adecuada cuando se necesita consistencia de escritura multi-AZ o bloqueo POSIX. Para cargas puramente de análisis de lectura sobre datos existentes en S3, S3 Files hoy es más económico que EFS será jamás.“
FSx for Lustre: No sustituye a los demás, pero es insustituible para HPC
FSx for Lustre no es un sistema de archivos genérico y nunca lo fue. Lustre se desarrolló para cargas de trabajo paralelas de computación de alto rendimiento (HPC): trabajos de entrenamiento de ML, análisis genómicos, pipelines de renderizado de vídeo, cargas de simulación. Su fortaleza reside en el patrón de striping: los datos se distribuyen entre varios servidores de almacenamiento, de modo que un trabajo de entrenamiento de ML con cien instancias de GPU puede leer simultáneamente con el máximo ancho de banda.
La integración con S3 es un detalle importante: FSx for Lustre puede importar directamente un bucket de S3 como fuente de datos, procesar los datos localmente con el rendimiento de Lustre y escribir los resultados de vuelta en S3. Esto lo convierte en la opción preferida para pipelines de ML donde los conjuntos de datos de entrenamiento residen en S3 y deben ser accesibles rápidamente.
La principal desventaja es su carácter de sistema de archivos temporal: los clústeres Scratch están diseñados para cargas de trabajo efímeras, mientras que los clústeres Persistentes tienen un coste proporcionalmente mayor. FSx for Lustre no es un sustituto de EFS para el almacenamiento compartido permanente; los costes lo harían inviable.
Matriz de decisión: Qué servicio para cada carga de trabajo
| Criterio | S3 Files | EFS | FSx Lustre |
|---|---|---|---|
| Consistencia de escritura Multi-AZ | No | Sí | Single-AZ |
| Bloqueo POSIX | Solo advisory | Completo | Completo |
| Ancho de banda de lectura paralelo | Límites de S3 | Bueno | Muy alto (GB/s) |
| Coste 100 TB | ~230 USD/mes | ~3.100 USD/mes | ~4.500 USD/mes |
| Sin planificación de capacidad | No (gestión de buckets) | Sí | No (dimensionamiento del clúster) |
| Ideal para | Analítica, Batch, Archivo | Contenedores, Lift-and-Shift, CMS | Entrenamiento ML, HPC, Vídeo |
Comparativa directa: Pros y contras
S3 Files
+ Almacenamiento muy económico
+ No se necesita una nueva capa de almacenamiento (S3 ya está disponible)
+ Inicio sencillo para equipos de análisis
– Sin escritura real Multi-AZ
– Costes de solicitud en cargas intensivas de escritura
– Sin bloqueo POSIX
EFS
+ Semántica POSIX completa
+ Multi-AZ sin esfuerzo de configuración
+ No es necesario gestionar la capacidad
– Costes significativamente más altos
– El nivel de rendimiento puede disparar los costes
– Insuficiente para el ancho de banda HPC
FSx for Lustre
+ Ancho de banda paralelo máximo
+ Integración directa con fuentes de datos S3
+ Latencia sub-milisegundo para trabajos de entrenamiento ML
– Los costes más elevados de las tres opciones
– Single-AZ, no es almacenamiento a largo plazo
– Esfuerzo de dimensionamiento del clúster
Notas de migración para despliegues EFS existentes
Para los equipos que actualmente utilizan EFS para cargas de trabajo de análisis o trabajos por lotes, merece la pena revisar los costes con S3 Files. La migración es técnicamente manejable si: la carga de trabajo es principalmente de lectura secuencial, no requiere escritura Multi-AZ y no utiliza bloqueo POSIX.
Un patrón de migración típico: crear un bucket S3, copiar los datos EFS existentes a S3 mediante la transferencia AWS DataSync y cambiar el punto de montaje. El paso crítico es auditar el uso de bloqueos POSIX en la aplicación – muchos frameworks de análisis no utilizan bloqueos, pero algunos frameworks de procesamiento lo exigen.
Para cargas de trabajo de contenedores en EKS o ECS sigue siendo válido: EFS es la vía recomendada para volúmenes persistentes ReadWriteMany. S3 Files aún no está disponible como controlador CSI para Kubernetes (a mayo de 2026), lo que limita su sustitución directa en entornos de contenedores.
Preguntas frecuentes
¿Puedo utilizar directamente los datos existentes de EFS con S3 Files?
No, EFS y S3 son backends de almacenamiento separados. Para una migración, los datos deben copiarse primero desde EFS a S3 mediante AWS DataSync. Después, el punto de montaje NFS puede cambiarse de EFS a S3 Files – siempre que la carga de trabajo no requiera bloqueo POSIX ni escritura Multi-AZ.
¿En qué regiones de AWS está disponible S3 Files?
En el momento del GA en abril de 2026, S3 Files está disponible en las principales regiones de AWS, incluida eu-central-1 (Fráncfort). La lista actualizada de regiones se mantiene en la documentación oficial de AWS. Para empresas del espacio DACH con requisitos de RGPD, eu-central-1 es la región relevante.
¿En qué se diferencian FSx for Lustre Scratch y Persistent?
Scratch FS 2 está diseñado para cargas de trabajo temporales y efímeras – por ejemplo, un trabajo de entrenamiento de ML que dura varias horas. No tiene replicación automática y es más económico. Persistent FS 1 y 2 ofrecen replicación automática de datos dentro de la Zona de Disponibilidad, mayor durabilidad y son adecuados para cargas de trabajo de ejecución prolongada – pero son significativamente más caros.
¿S3 Files admite cargas de trabajo de Windows mediante SMB?
No. S3 Files solo admite NFS v4.0 y, por tanto, está limitado a cargas de trabajo Linux. Para entornos Windows que necesiten un sistema de archivos compartido, Amazon FSx for Windows File Server (protocolo SMB) sigue siendo la opción recomendada en AWS.
¿Existe soporte para S3 Files como PersistentVolume de Kubernetes?
A mayo de 2026, no hay un controlador CSI oficial para S3 Files como PersistentVolume de Kubernetes. EFS sigue siendo la opción recomendada para volúmenes persistentes ReadWriteMany en EKS. Existen proyectos comunitarios, pero no están cualificados para uso en producción. La situación podría cambiar con futuras versiones de AWS.
Más del Grupo MBF Media
- MyBusinessFuture: Factura electrónica final de año 2026 – Lista de verificación para la transición a XRechnung y ZUGFeRD
- Digital Chiefs: Estrategia de datos DACH 2026 – Por qué los presupuestos de TI se desplazan del Frontend a la Gobernanza de Datos
- SecurityToday: CISA KEV abril de 2026 – Samsung MagicINFO, SimpleHelp y D-Link bajo explotación activa
Adrian Garcia-Kunz escribe para cloudmagazin.com sobre patrones nativos de la nube, arquitectura de almacenamiento y herramientas para desarrolladores.
Fuente imagen principal: Pexels / Brett Sayles (px:5050305)
