Amazon S3 siempre fue el lugar donde viven los datos corporativos, pero nunca fue donde los agentes de IA conseguían trabajar de verdad.
Esa división entre object storage y file system creó un problema silencioso que fue rompiendo pipelines de multi-agentes poco a poco, obligando a los equipos de ingeniería a mantener capas paralelas de infraestructura solo para que las cosas funcionaran.
El escenario era más o menos así: los AI agents operan naturalmente con rutas de archivo, directorios y herramientas de lectura basadas en file system. Pero los datos estaban en S3, accesibles únicamente mediante llamadas de API. Para conectar esos dos mundos, los equipos necesitaban descargar los archivos localmente, mantener todo sincronizado y cruzar los dedos para que el agente no perdiera el estado de la sesión a mitad de camino.
Spoiler: eso pasaba todo el tiempo. 😅
AWS sintió ese problema en carne propia mientras usaba herramientas como Kiro y Claude Code internamente. Y la respuesta de la compañía fue S3 Files, una solución que conecta el Elastic File System (EFS) directamente con S3 para entregar semántica nativa de file system sin mover ningún dato de su lugar. Sin parches, sin capas extras, sin sincronización manual. Lo que parece un detalle técnico, en la práctica, cambia completamente cómo los agentes de IA interactúan con datos a escala corporativa. 🚀
El problema real detrás de la división entre object storage y file system
Cuando te pones a pensar en la arquitectura que sostiene la mayoría de los sistemas de AI agents hoy, te das cuenta rápidamente de que hay una tensión estructural que nunca se resolvió del todo. Los modelos de lenguaje y los agentes que operan sobre ellos fueron diseñados para trabajar con abstracciones de file system, esas con rutas como /datos/reportes/2024/q1.csv, operaciones de lectura y escritura secuencial, y navegación por directorios. Es exactamente ese tipo de interfaz la que herramientas de agentes como las que AWS usa internamente esperan encontrar cuando necesitan acceder a contexto o persistir resultados entre etapas de una pipeline.
Amazon S3, por otro lado, fue construido sobre un modelo completamente diferente. Es un object storage, lo que significa que cada archivo, u objeto, se identifica por una clave única dentro de un bucket. No existe una jerarquía real de directorios, no existe la posibilidad de hacer un atomic move de un objeto, y cada acceso pasa por una llamada de API HTTP. Como Andy Warfield, VP y Distinguished Engineer de AWS, explicó: S3 no es un file system y no tiene semántica de file system en una serie de frentes. No puedes hacer un move atómico de un objeto, y no existen directorios reales en S3.
Para workloads de datos en reposo, backup, distribución de contenido e incluso data lakes, ese modelo es absolutamente perfecto. Pero para un agente que necesita abrir un archivo, escribir un fragmento de resultado, cerrarlo y abrir otro mientras mantiene el estado de la sesión, el modelo de object storage se convierte en un obstáculo de ingeniería que consume tiempo, recursos y, sobre todo, estabilidad.
El resultado práctico de esto era que los equipos de ingeniería terminaban desarrollando y manteniendo capas intermedias solo para que ese puente funcionara. Algunos equipos usaban instancias EC2 con discos locales como buffer temporal. Otros implementaban soluciones de caché con sincronización periódica hacia S3. Había también quienes usaban el propio Elastic File System de AWS como sistema primario y replicaban los datos hacia S3 en paralelo. Cada uno de estos enfoques funcionaba hasta cierto punto, pero todos añadían latencia, costo operativo y puntos de falla extra en una arquitectura que ya era lo bastante compleja como para escalar con seguridad.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Intentos anteriores con FUSE y por qué no fueron suficientes
Antes de S3 Files, la respuesta estándar de la industria para este problema era FUSE, siglas de Filesystems in USErspace. Esta tecnología permite montar un file system personalizado en el espacio de usuario sin alterar el storage subyacente. Herramientas como Mount Point de la propia AWS, gcsfuse de Google y blobfuse2 de Microsoft seguían este camino, usando drivers basados en FUSE para hacer que sus respectivos object stores parecieran un file system.
El problema, como señaló Warfield, es que esos object stores seguían sin ser file systems de verdad. Los drivers FUSE o simulaban comportamiento de archivo insertando metadatos extra en los buckets, lo que terminaba rompiendo la visión de API de objetos, o simplemente rechazaban operaciones de archivo que el object store no podía soportar nativamente. En ambos casos, el resultado era una capa de abstracción frágil que trasladaba la complejidad al usuario final.
Jeff Vogel, analista de Gartner, fue bastante directo al evaluar la limitación de estos enfoques FUSE. Según él, las soluciones basadas en FUSE externalizan complejidad y problemas al usuario. También destacó que S3 Files elimina toda una clase de modos de fallo, incluyendo fallos inexplicables de entrenamiento e de inferencia causados por metadatos desactualizados, que son notoriamente difíciles de depurar.
Ese punto sobre metadatos desactualizados, o stale metadata, es particularmente importante para quienes trabajan con pipelines de IA. Cuando un agente lee un archivo cuyo metadato en la caché local ya no refleja el estado real del objeto en el bucket, el resultado puede ir desde datos corruptos hasta fallos silenciosos que solo aparecen mucho después, convirtiendo el diagnóstico en una pesadilla operativa. 😬
Cómo S3 Files resuelve esto en la práctica
S3 Files es una funcionalidad que AWS desarrolló para eliminar exactamente esa capa de fricción. En lugar de crear un nuevo servicio separado u obligar al desarrollador a migrar datos entre sistemas, la solución integra el Elastic File System directamente con los buckets de Amazon S3, permitiendo que los datos almacenados en S3 se accedan con semántica completa de file system, incluyendo lectura y escritura por ruta, listado de directorios y operaciones atómicas, sin que un solo byte necesite moverse de lugar.
La arquitectura es fundamentalmente diferente de los enfoques FUSE anteriores. S3 Files presenta una capa nativa de file system mientras mantiene S3 como sistema de registro. Y aquí está el punto más relevante: tanto la API de file system como la API de objetos de S3 permanecen accesibles simultáneamente sobre los mismos datos. Esto significa que las aplicaciones heredadas que ya usan la API de S3 siguen funcionando normalmente, mientras que los nuevos workloads agénticos pueden acceder a los mismos datos vía file system nativo.
En la práctica, lo que cambia es la forma en que los AI agents ven los datos. Con S3 Files, un agente puede montar un bucket S3 directamente en su entorno local con un solo comando y, a partir de ahí, trabajar con los archivos exactamente como lo haría en un sistema de archivos local o en red. Esto significa que las herramientas de file system que los agentes ya usan nativamente, como lectura línea por línea, escritura incremental y navegación por estructura de directorios, funcionan sin ninguna adaptación en el código del agente. La capa de traducción entre object storage y file system ahora es responsabilidad de la infraestructura, no del desarrollador.
Warfield ilustró este cambio con un ejemplo muy concreto de análisis de logs. En el escenario anterior, un desarrollador usando Kiro o Claude Code para trabajar con datos de log necesitaba decirle explícitamente al agente dónde estaban los archivos de log e pedirle que los descargara. Con S3 Files, los logs quedan inmediatamente montables en el file system local, y el desarrollador puede simplemente indicar que los logs están en una ruta específica. El agente tiene acceso inmediato para navegar y analizar todo sin pasos intermedios.
Un detalle importante es que AWS fue más allá de solo resolver el problema técnico. La compañía llegó a esta solución a partir de un dolor real que ella misma enfrentó al usar herramientas como Kiro y Claude Code en sus propios entornos internos de desarrollo. Esto es relevante porque significa que S3 Files no fue diseñado en un vacío teórico, sino probado en escenarios reales de uso de agentes de IA a escala corporativa. 🎯
Como explicó Warfield, al hacer que los datos en S3 estuvieran inmediatamente disponibles como si fueran parte del file system local, el equipo encontró una gran aceleración en la capacidad de herramientas como Kiro y Claude Code para trabajar con esos datos. S3 Files ya está disponible en la mayoría de las regiones de AWS.
El impacto directo para pipelines de multi-agentes
Las pipelines de multi-agentes son, por naturaleza, sistemas distribuidos donde diferentes agentes necesitan leer y escribir en contextos compartidos a lo largo de etapas encadenadas. En un flujo típico, un agente de recopilación puede buscar documentos, un agente de procesamiento puede transformarlos, un agente de análisis puede extraer insights y un agente de síntesis puede consolidar todo en un informe final. Cada uno de estos agentes necesita acceso confiable al estado dejado por el agente anterior, y cualquier fallo en esa cadena de traspaso de contexto compromete el resultado final de la pipeline entera.
Con el enfoque tradicional de object storage, este flujo dependía de sincronizaciones explícitas entre etapas. El agente A terminaba su trabajo, hacía upload a S3, el agente B necesitaba saber que el upload había ocurrido, descargaba el archivo, trabajaba en él y repetía el ciclo. Además de la latencia extra en cada etapa, existía el riesgo real de condiciones de carrera, donde dos agentes intentaban acceder o modificar el mismo objeto al mismo tiempo sin los mecanismos de control de concurrencia que un file system nativo ofrece. El resultado era inestabilidad, pérdida de estado y fallos difíciles de depurar porque ocurrían de forma intermitente y dependían del tiempo de ejecución de cada agente.
Con S3 Files y la integración nativa con el Elastic File System, los agentes dentro de una pipeline pasan a compartir un file system común montado sobre S3. Esto significa que las garantías de consistencia y control de acceso que EFS ofrece se aplican directamente sobre los datos que ya están en S3, sin duplicación, sin sincronización y sin la necesidad de gestionar estado externo.
AWS informó que miles de recursos computacionales pueden conectarse a un único file system S3 al mismo tiempo, con throughput agregado de lectura alcanzando múltiples terabytes por segundo. El estado compartido entre agentes funciona a través de convenciones estándar de file system: subdirectorios, archivos de notas y directorios de proyecto compartidos que cualquier agente en la pipeline puede leer y escribir. Warfield describió equipos de ingeniería de la propia AWS usando este patrón internamente, con agentes registrando notas de investigación y resúmenes de tareas en directorios de proyecto compartidos.
Para equipos que están construyendo pipelines de RAG sobre contenido compartido entre agentes, S3 Vectors, lanzado en AWS re:Invent en diciembre de 2024, se integra como capa adicional para búsqueda por similitud y generación aumentada por recuperación sobre esos mismos datos. 💡
Lo que dicen los analistas sobre S3 Files
La reacción de los analistas de mercado ante el lanzamiento de S3 Files ha sido bastante positiva, con perspectivas que van más allá de la cuestión puramente técnica de rendimiento.
Jeff Vogel, de Gartner, resumió bien el impacto: S3 Files elimina el movimiento de datos entre object storage y file storage, transformando S3 en un espacio de trabajo compartido y de baja latencia sin copiar datos. En sus palabras, el file system se convierte en una view, no en otro dataset. Esta distinción es fundamental porque significa que ya no existe la necesidad de mantener dos copias de los mismos datos en formatos diferentes.
Herramientas que usamos a diario
Dave McCarthy, analista de IDC, aportó una perspectiva aún más amplia sobre lo que esto significa para la IA agéntica. Según él, para la AI agéntica, que piensa en términos de archivos, rutas y scripts locales, S3 Files es el eslabón que faltaba. La funcionalidad permite que un agente de IA trate un bucket de escala exabyte como su propio disco duro local, habilitando un nivel de velocidad operativa autónoma que antes estaba frenado por el overhead de API asociado a enfoques como FUSE.
McCarthy fue más allá y clasificó el lanzamiento como un punto de inflexión más amplio para cómo las empresas utilizan sus datos. En su visión, el lanzamiento de S3 Files no es simplemente S3 con una nueva interfaz, sino la eliminación del último punto de fricción entre data lakes masivos e IA autónoma. Al convergir el acceso de archivo y objeto con S3, AWS está abriendo puertas a más casos de uso con menos retrabajo.
Qué cambia para quienes están construyendo con AI agents hoy
Desde el punto de vista práctico, S3 Files representa una simplificación significativa en el stack de infraestructura de quienes trabajan con AI agents en entornos que ya usan el ecosistema AWS. Equipos que hoy mantienen instancias extras, scripts de sincronización o soluciones de caché entre EFS y S3 pasan a tener una alternativa nativa que elimina esa complejidad operativa. Menos componentes que gestionar significa menos puntos de fallo y menos costo de mantenimiento a largo plazo, especialmente en proyectos que necesitan escalar sin aumentar proporcionalmente el tamaño del equipo de ingeniería.
Para equipos corporativos que venían manteniendo un file system separado junto al S3 para soportar aplicaciones basadas en archivos o workloads de agentes, esa arquitectura paralela ahora se vuelve innecesaria. S3 deja de ser solo el destino al que el agente envía sus resultados y pasa a ser el entorno donde el trabajo del agente efectivamente ocurre.
Además, hay un impacto directo en la velocidad de desarrollo. Cuando los agentes pueden trabajar con file system nativo sobre Amazon S3, los desarrolladores pueden usar bibliotecas, frameworks y patrones de código que ya conocen, sin necesidad de adaptar la lógica del agente para lidiar con las particularidades de las llamadas de API de object storage. Esto reduce la curva de aprendizaje para quienes están empezando con sistemas agénticos y también facilita la migración de pipelines que hoy corren en entornos locales o en otros servicios de cloud hacia la infraestructura AWS.
Como Warfield se encargó de resaltar, todos estos cambios de API provenientes de los equipos de storage de AWS nacen del trabajo directo y la experiencia de clientes usando agentes para trabajar con datos. El foco está en eliminar cualquier fricción y hacer que estas interacciones funcionen de la mejor manera posible.
El timing del lanzamiento de S3 Files también es relevante. El mercado de herramientas y frameworks para construcción de AI agents está creciendo a un ritmo acelerado, con nuevos patrones de arquitectura surgiendo constantemente. Al ofrecer una integración nativa entre object storage y file system ahora, AWS está posicionando a S3 como infraestructura de datos no solo para workloads tradicionales, sino como base confiable para la próxima generación de aplicaciones inteligentes. Y dado que S3 ya es donde la mayoría de las empresas guardan sus datos corporativos, esta jugada tiene bastante sentido dentro de una estrategia más amplia de dominio en cloud para IA. 🧠
