S3 Files y el rostro cambiante de S3

• Para reducir la ineficiencia del movimiento de datos a gran escala, se introdujo S3 Files, que permite acceder directamente a los datos de S3 como si fueran un sistema de archivos
• Esta función integra Amazon EFS con S3 para hacer posible montar buckets de S3 por NFS y leer/escribir desde EC2, contenedores, Lambda y otros entornos
• Internamente usa una estructura de stage y commit para reflejar periódicamente los cambios en S3, y admite sincronización bidireccional entre archivos y objetos
• Junto con S3 Tables y S3 Vectors, S3 Files funciona como un componente clave para expandir S3 hacia una plataforma de datos unificada
• S3 ya no evoluciona solo como un almacenamiento simple, sino como un espacio de trabajo unificado centrado en los datos que brinda la base para que los desarrolladores usen los datos directamente

---

La evolución de S3 y el diseño de S3 Files

• Las dificultades de mover datos y el punto de partida de S3 Files

  • El proceso de mover grandes volúmenes de datos ha sido una fuente persistente de ineficiencia en múltiples industrias, desde la investigación científica hasta el machine learning
  • En el caso de investigación genómica de UBC, los investigadores dedicaban mucho tiempo a copiar datos entre S3 y sistemas de archivos locales
  • Esta fricción de datos (data friction) surge porque las herramientas acceden a los datos de formas distintas
  • S3 Files fue diseñado para reducir esa fricción permitiendo acceder directamente a los datos de S3 como si fueran un sistema de archivos

• Desarrollo basado en agentes y la importancia de los datos

  • El avance de las herramientas agénticas (agentic tooling) ha incrementado drásticamente la velocidad y diversidad del desarrollo de aplicaciones
  • A medida que baja la barrera para escribir código, se forma un entorno en el que los expertos de dominio pueden construir aplicaciones directamente
  • La vida útil de las aplicaciones se vuelve más corta, y los datos emergen como el activo clave que permanece a largo plazo
  • El almacenamiento no debe ser solo un repositorio, sino una capa de abstracción que separe los datos de las aplicaciones y permita reutilizarlos de forma continua

Nuevas primitivas de datos en S3

• S3 Tables

  • Para manejar datos estructurados, S3 introdujo S3 Tables basadas en Apache Iceberg
  • Mantiene las capacidades de Iceberg y además ofrece protección de integridad de datos, compactación automática (compaction), replicación entre regiones y más
  • Actualmente hay más de 2 millones de tablas almacenadas en S3 Tables, y varias aplicaciones se construyen sobre esta base

• S3 Vectors

  • Con el avance de la IA, ha aumentado la demanda de índices vectoriales
  • Las bases de datos vectoriales existentes almacenan índices en memoria o SSD, pero esto tiene límites de costo y escalabilidad
  • S3 Vectors ofrece un índice vectorial totalmente elástico con un perfil de costo, rendimiento y durabilidad similar al de los objetos de S3
  • Puede escalar desde cientos hasta decenas de miles de millones de registros, y proporciona endpoints de API para búsqueda por similitud (scalar similarity search)

La llegada de S3 Files

• Resumen

  • S3 Files integra Amazon EFS con S3 para permitir acceso directo a datos de S3 como si fuera un sistema de archivos de red (NFS)
  • Es posible montar buckets o prefijos de S3 desde EC2, contenedores, Lambda y otros entornos para leerlos y escribirlos como archivos
  • Los cambios se reflejan automáticamente en S3, lo que permite sincronización bidireccional entre archivos y objetos

• Los retos del diseño

  • Los sistemas de archivos y el almacenamiento de objetos tienen modelos de datos fundamentalmente distintos
  • Al principio se intentó combinar EFS y S3 de forma simple, pero solo quedaron “compromisos poco aceptables (unpalatable compromises)”
  • Los archivos admiten cambios granulares y acceso concurrente, mientras que los objetos asumen inmutabilidad y actualizaciones de la unidad completa
  • El sistema de notificaciones de eventos de S3 procesa más de 300 mil millones de notificaciones al día y funciona con base en cambios a nivel de objeto

Principios de diseño de Stage and Commit

• Convertir el límite en una función

  • En lugar de ocultar la diferencia entre archivos y objetos, se diseñó como un límite explícito
  • Los cambios se stagean (guardado temporal) en EFS y luego se commitean (commit) a S3 en intervalos periódicos
  • Inspirado en el concepto de control de versiones de Git, este enfoque permite controlar la transferencia de datos según tiempo y políticas

• Consistencia y atomicidad

  • Se admite tanto la operación atómica del sistema de archivos (rename, move) como las actualizaciones de objeto completo de S3
  • Al separar ambas capas, se conserva el modelo de consistencia de cada sistema y al mismo tiempo se ofrece una vista única de los datos

• Gestión de permisos

  • Las políticas de IAM de S3 y los permisos basados en inode del sistema de archivos son estructuralmente distintos
  • S3 Files separa ambos esquemas mediante asignación de permisos por montaje
  • Las políticas de IAM de S3 se mantienen como backstop final, lo que permite controlar el acceso cuando cambian los límites de los datos

• Desajuste de namespace

  • S3 no tiene un concepto real de directorio, y el separador de ruta (delimiter) puede definirse arbitrariamente
  • Para resolver el desajuste con el sistema de archivos, se decidió mantener intactas las reglas de nombres de ambos lados
  • Los objetos incompatibles no se mueven; en cambio, generan eventos para que el desarrollador los procese

• Rendimiento y latencia

  • El sistema de archivos está centrado en metadatos, mientras que S3 está optimizado para acceso paralelo a gran escala
  • Como la mayoría de las cargas de trabajo no acceden a archivos y objetos al mismo tiempo, mantener una capa de sincronización resulta más realista que fusionar por completo ambos modelos
  • La vista de archivos mantiene la consistencia NFS, la vista de objetos mantiene la consistencia fuerte de S3, y la capa de sincronización actúa como puente

Cómo funciona S3 Files

• Estructura básica

  • S3 Files usa EFS como backend para ofrecer una experiencia de sistema de archivos
  • Al acceder a un directorio, obtiene los metadatos de S3 para crear una vista sincronizada; para archivos de 128 KB o menos, también carga de inmediato los datos
  • Los archivos grandes usan carga diferida (lazy hydration) para traer los datos cuando se necesitan
  • Los cambios se commitean a S3 con un único PUT aproximadamente cada 60 segundos, realizando sincronización bidireccional

• Conflictos y administración

  • Si ambos lados se modifican al mismo tiempo, S3 se considera la fuente de verdad (source of truth)
  • Los archivos en conflicto se mueven al directorio lost+found y se registran mediante métricas de CloudWatch
  • Los archivos a los que no se accede durante 30 días se eliminan de la vista del sistema de archivos para optimizar costos

• Optimización de rendimiento

  • Mediante la función read bypass, en lecturas secuenciales de gran tamaño se leen directamente desde S3 con solicitudes GET en paralelo

    • Se logra un rendimiento de 3 GB/s por cliente, y con múltiples clientes se obtiene escalabilidad a nivel de terabits

• Limitaciones y mejoras previstas

  • Como S3 no tiene una operación nativa de rename, cambiar el nombre de un directorio requiere copiar y eliminar todo
  • Los montajes con más de 50 millones de objetos muestran una advertencia
  • El control explícito de commit no se incluirá en la versión inicial
  • Algunas claves de objeto no pueden representarse como nombres de archivo POSIX, por lo que se excluyen de la vista de archivos

Diversidad de datos y evolución de S3

• Convivencia de distintos métodos de acceso a datos

  • Como en el caso de investigación de UBC, los desarrolladores dedican mucho tiempo a mover datos, cachearlos y administrar nombres
  • El equipo de S3 busca integrar distintos métodos de acceso a datos mediante Tables, Vectors y Files
  • En lugar de intentar eliminar la diferencia entre archivos y objetos, reconoce las características de cada uno y convierte sus límites en funciones

• El rol ampliado de S3

  • S3 evoluciona de un simple almacenamiento de objetos a una plataforma de almacenamiento unificada que soporta diversas formas de datos
  • Con Tables, Vectors y Files, ahora es posible usar los datos directamente según la forma de trabajo
  • El objetivo es que el almacenamiento deje de ser un obstáculo para el trabajo y se convierta en infraestructura base transparente
  • En el futuro se seguirá ampliando con funciones como control de stage/commit e integración con pipelines

• Conclusión

  • S3 Files combina las ventajas de ambos mundos manteniendo un límite explícito entre archivos y objetos
  • S3, que comenzó hace 20 años como almacenamiento de objetos, ahora evoluciona hacia un espacio de trabajo unificado centrado en los datos
  • Como dice el mensaje “Ahora, construye (Go build!)”, S3 se está posicionando como la base para que los desarrolladores experimenten y construyan con datos más rápido

[xguru]

Ah, ahora es más cómodo porque la sección de lecturas recomendadas enlaza bien los artículos oficiales relacionados.
Siempre me preguntaba qué había que hacer en casos como este, cuando hay un artículo introductorio y otro oficial por separado,
pero me alegra ver que la sección de lecturas recomendadas funciona bien.. jaja

Ahora S3 se está expandiendo como una plataforma de datos que incluye archivos, tablas y vectores.

Da la impresión de que S3, que fue el punto de partida de la infraestructura moderna en la nube, se está redefiniendo otra vez después de 20 años.

[rtyu1120]

Aunque la estructura de archivos no se comparte de forma transparente con S3, también existe software de código abierto llamado ZeroFS que usa S3 como base de datos para ejecutar un sistema de archivos compatible con POSIX. Fue bastante popular por una demo que corría PostgreSQL sobre S3.

https://www.zerofs.net/

[rtyu1120]

También hay un artículo de Archil, una empresa fundada por un exingeniero de S3, donde comparan con su propio producto, así que también resulta interesante verlo jaja

https://x.com/jhleath/status/2042613823522377933

[GN⁺]

Comentarios en Hacker News

• Esto es, en la práctica, usar S3FS pero con EFS (el servicio NFS administrado de AWS) como capa de caché para datos activos y accesos aleatorios pequeños
  El problema es que arrastra intacto el costoso esquema de precios de EFS
  — Todas las escrituras cuestan $0.06 por GB, lo que puede ser letal para cargas de trabajo intensivas en escritura
  — Las lecturas desde la caché cobran $0.03 por GB, y las lecturas grandes de más de 128 KB se transmiten directamente desde el bucket de S3 sin costo
  — La caché cuesta $0.30 por GB al mes, pero como principalmente guarda de forma persistente solo archivos pequeños de 128 KB o menos, no parece que el costo vaya a ser tan grande

  • Me pregunto si realmente es cierto que las lecturas de archivos grandes (>128 KB) siempre evitan la caché
    Me preocupa porque la latencia de S3 es bastante mala

• La frase “NFS provides the semantics your applications expect” es de lo más gracioso que he visto

  • Las aplicaciones no esperan que una sola caída de red deje una llamada al sistema bloqueada indefinidamente ni que el sistema de archivos quede en un estado imposible de desmontar

• Hugging Face Buckets también agregó recientemente una función para montar buckets como si fueran un sistema de archivos
  registro de cambios de hf-mount

• Me daba curiosidad la parte relacionada con la sincronización
  Según la documentación de AWS,
  si modificas /mnt/s3files/report.csv y luego se sube otra versión al bucket de S3, en caso de conflicto tu versión se mueve al directorio .s3files-lost+found-file-system-id y se reemplaza por la versión del bucket
  Es decir, existe un directorio de recuperación automática en caso de conflicto

• FiberFS está casi en su primera versión oficial
  Tiene caché integrada, compatibilidad con CDN, metadatos JSON y seguridad de concurrencia, y apunta a todo almacenamiento compatible con S3

  • Me pregunto cómo se compara con la propia implementación FUSE de Amazon. Ya van por la tercera versión

• Ojalá AWS ofreciera un puente administrado con almacenamiento NVMe local
  NVMe es mucho más rápido que EBS, y EBS es más rápido que EFS
  Si se montara una capa de caché sobre NVMe, probablemente el rendimiento sería bastante bueno, aunque una opción totalmente integrada sería aún mejor

  • Si EFS no es más que un montaje NFS simple, quizá se podría implementar manualmente adjuntando un volumen NVMe y configurando cachefilesd
    Por ejemplo

    mkfs.ext4 /dev/nvme0n1 && \
    mount /dev/nvme0n1 /var/cache/fscache && \
    mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
    

    Algo así podría funcionar de inmediato
    En esencia son tres líneas de comando, y que AWS lo convierta en un servicio administrado es muy propio de AWS

• Según recuerdo, antes AWS decía que no había que usar S3 como sistema de archivos, así que me pregunto por qué ahora cambió

  • Esta vez parece una arquitectura que pone un sistema de archivos real (EFS) delante de S3 y hace una sincronización transparente
    En el blog también mencionan precauciones como problemas de consistencia o manejo de nombres de objetos
    Como fan de S3, me parece una solución intermedia bastante razonable
  • Los arquitectos de grandes clientes llevan mucho tiempo usando S3 como si fuera un sistema de archivos
    La presión de los tickets de soporte que recibió AWS y las peticiones de “¿por qué no se puede?” seguramente se fueron acumulando hasta llevarlos en esta dirección
    Personalmente no me gusta porque me parece un enfoque de “empaquetar de nuevo algo que en esencia es distinto”, pero suena a un caso de presión social por los $$$
  • Parece una estrategia para atraer también a usuarios con menos nivel técnico
    Así pueden convertir en clientes de AWS a quienes usan herramientas tipo “S3asYourFS.exe”
    Aun así, considerando la capacidad de soporte al cliente de AWS, no sé si fue una decisión inteligente
    Pero la tentación de sumar más usuarios pagando cada mes debió de haber sido grande
  • De todos modos, si la gente va a usar S3 como sistema de archivos sí o sí, entonces mejor darle soporte oficial
  • Al final AWS puso una caché delante y creó un modelo de ingresos
    Desde el punto de vista del usuario, el rendimiento mejora, y AWS reduce carga
    Puede que ahorres dinero, o puede que no

• Me pregunto qué pasaría si se guarda una base de datos SQLite en esto
  Probablemente solo sirva para réplicas de solo lectura, y quizá no para respaldos al estilo Litestream

  • El mecanismo de bloqueo de SQLite no es seguro en NFS, así que no funciona

• El comportamiento de locking de NFS ya es bastante complejo, y mezclarle además un backend remoto de S3 suena aún más confuso

• Werner Vogels es realmente impresionante
  Conocí sus textos hace tiempo mientras estudiaba DynamoDB, y desde entonces soy fan