Amazon S3 sempre foi o lugar onde os dados corporativos vivem, mas nunca foi onde os agentes de IA conseguiam trabalhar de verdade.
Essa divisão entre object storage e file system criou um problema silencioso que foi quebrando pipelines de multi-agentes aos poucos, forçando times de engenharia a manter camadas paralelas de infraestrutura só para fazer as coisas funcionarem.
O cenário era mais ou menos assim: os AI agents operam naturalmente com caminhos de arquivo, diretórios e ferramentas de leitura baseadas em file system. Só que os dados estavam no S3, acessíveis apenas via chamadas de API. Para conectar esses dois mundos, as equipes precisavam baixar os arquivos localmente, manter tudo sincronizado e torcer para que o agente não perdesse o estado da sessão no meio do caminho.
Spoiler: isso acontecia o tempo todo. 😅
A AWS sentiu esse problema na própria pele enquanto usava ferramentas como Kiro e Claude Code internamente. E a resposta da empresa para isso foi o S3 Files, uma solução que conecta o Elastic File System (EFS) diretamente ao S3 para entregar semântica nativa de file system sem mover nenhum dado do lugar. Sem gambiarras, sem camadas extras, sem sincronização manual. O que parece um detalhe técnico, na prática, muda completamente como os agentes de IA interagem com dados em escala corporativa. 🚀
O problema real por trás da divisão entre object storage e file system
Quando você para pra pensar na arquitetura que sustenta a maioria dos sistemas de AI agents hoje, percebe rapidamente que há uma tensão estrutural que nunca foi completamente resolvida. Os modelos de linguagem e os agentes que operam sobre eles foram projetados para trabalhar com abstrações de file system, aquelas com caminhos como /dados/relatorios/2024/q1.csv, operações de leitura e escrita sequencial, e navegação por diretórios. É exatamente esse tipo de interface que ferramentas de agentes como as que a AWS usa internamente esperam encontrar quando precisam acessar contexto ou persistir resultados entre etapas de uma pipeline.
O Amazon S3, por outro lado, foi construído sobre um modelo completamente diferente. Ele é um object storage, o que significa que cada arquivo, ou objeto, é identificado por uma chave única dentro de um bucket. Não existe hierarquia real de diretórios, não existe a possibilidade de fazer um atomic move de um objeto, e cada acesso passa por uma chamada de API HTTP. Como Andy Warfield, VP e Distinguished Engineer da AWS, explicou: o S3 não é um file system e não tem semântica de file system em uma série de frentes. Você não consegue fazer um move atômico de um objeto, e não existem diretórios de verdade no S3.
Para workloads de dados em repouso, backup, distribuição de conteúdo e até data lakes, esse modelo é absolutamente perfeito. Mas para um agente que precisa abrir um arquivo, escrever um trecho de resultado, fechar e abrir outro enquanto mantém estado da sessão, o modelo de object storage vira um obstáculo de engenharia que consome tempo, recursos e, principalmente, estabilidade.
O resultado prático disso era que os times de engenharia acabavam desenvolvendo e mantendo camadas intermediárias só para fazer essa ponte funcionar. Alguns times usavam instâncias EC2 com discos locais como buffer temporário. Outros implementavam soluções de cache com sincronização periódica para o S3. Havia ainda quem usasse o próprio Elastic File System da AWS como sistema primário e replicasse os dados para o S3 em paralelo. Cada uma dessas abordagens funcionava até certo ponto, mas todas adicionavam latência, custo operacional e pontos de falha extras numa arquitetura que já era complexa o suficiente para escalar com segurança.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Tentativas anteriores com FUSE e por que não bastaram
Antes do S3 Files, a resposta padrão da indústria para esse problema era o FUSE, sigla para Filesystems in USErspace. Essa tecnologia permite montar um file system customizado no espaço de usuário sem alterar o storage por baixo. Ferramentas como o Mount Point da própria AWS, o gcsfuse do Google e o blobfuse2 da Microsoft seguiam esse caminho, usando drivers baseados em FUSE para fazer seus respectivos object stores parecerem um file system.
O problema, como Warfield apontou, é que esses object stores continuavam não sendo file systems de verdade. Os drivers FUSE ou simulavam comportamento de arquivo inserindo metadados extras nos buckets, o que acabava quebrando a visão de API de objetos, ou simplesmente recusavam operações de arquivo que o object store não conseguia suportar nativamente. Em ambos os casos, o resultado era uma camada de abstração frágil que transferia a complexidade para o usuário final.
Jeff Vogel, analista do Gartner, foi bastante direto ao avaliar a limitação dessas abordagens FUSE. Segundo ele, soluções baseadas em FUSE externalizam complexidade e problemas para o usuário. Ele também destacou que o S3 Files elimina uma classe inteira de modos de falha, incluindo falhas inexplicáveis de treinamento e inferência causadas por metadados desatualizados, que são notoriamente difíceis de debugar.
Esse ponto sobre metadados desatualizados, ou stale metadata, é particularmente importante para quem trabalha com pipelines de IA. Quando um agente lê um arquivo cujo metadado no cache local não reflete mais o estado real do objeto no bucket, o resultado pode ser desde dados corrompidos até falhas silenciosas que só aparecem muito depois, tornando o diagnóstico um pesadelo operacional. 😬
Como o S3 Files resolve isso na prática
O S3 Files é uma funcionalidade que a AWS desenvolveu para eliminar exatamente essa camada de fricção. Em vez de criar um novo serviço separado ou obrigar o desenvolvedor a migrar dados entre sistemas, a solução integra o Elastic File System diretamente com os buckets do Amazon S3, permitindo que os dados armazenados no S3 sejam acessados com semântica de file system completa, incluindo leitura e escrita por caminho, listagem de diretórios e operações atômicas, sem que nenhum byte precise ser movido de lugar.
A arquitetura é fundamentalmente diferente das abordagens FUSE anteriores. O S3 Files apresenta uma camada nativa de file system enquanto mantém o S3 como sistema de registro. E aqui está o ponto mais relevante: tanto a API de file system quanto a API de objetos do S3 permanecem acessíveis simultaneamente sobre os mesmos dados. Isso significa que aplicações legadas que já usam a API do S3 continuam funcionando normalmente, enquanto novos workloads agenticos podem acessar os mesmos dados via file system nativo.
Na prática, o que muda é a forma como os AI agents enxergam os dados. Com o S3 Files, um agente pode montar um bucket S3 diretamente no seu ambiente local com um único comando e, a partir daí, trabalhar com os arquivos exatamente como faria em um sistema de arquivos local ou em rede. Isso significa que as ferramentas de file system que os agentes já usam nativamente, como leitura linha a linha, escrita incremental e navegação por estrutura de diretórios, funcionam sem nenhuma adaptação no código do agente. A camada de tradução entre object storage e file system agora é responsabilidade da infraestrutura, não do desenvolvedor.
Warfield ilustrou essa mudança com um exemplo bem concreto de análise de logs. No cenário anterior, um desenvolvedor usando Kiro ou Claude Code para trabalhar com dados de log precisava explicitamente dizer ao agente onde os arquivos de log estavam e instruí-lo a baixá-los. Com o S3 Files, os logs ficam imediatamente montáveis no file system local, e o desenvolvedor pode simplesmente indicar que os logs estão em um caminho específico. O agente tem acesso imediato para navegar e analisar tudo sem etapas intermediárias.
Um detalhe importante é que a AWS foi além de só resolver o problema técnico. A empresa chegou a essa solução a partir de uma dor real que ela mesma enfrentou ao usar ferramentas como Kiro e Claude Code nos seus próprios ambientes internos de desenvolvimento. Isso é relevante porque significa que o S3 Files não foi desenhado num vácuo teórico, mas sim testado em cenários reais de uso de agentes de IA em escala corporativa. 🎯
Como Warfield explicou, ao tornar os dados no S3 imediatamente disponíveis como se fossem parte do file system local, a equipe encontrou uma grande aceleração na capacidade de ferramentas como Kiro e Claude Code trabalharem com esses dados. O S3 Files já está disponível na maioria das regiões da AWS.
O impacto direto para pipelines de multi-agentes
Pipelines de multi-agentes são, por natureza, sistemas distribuídos onde diferentes agentes precisam ler e escrever em contextos compartilhados ao longo de etapas encadeadas. Num fluxo típico, um agente de coleta pode buscar documentos, um agente de processamento pode transformá-los, um agente de análise pode extrair insights e um agente de síntese pode consolidar tudo num relatório final. Cada um desses agentes precisa de acesso confiável ao estado deixado pelo agente anterior, e qualquer falha nessa cadeia de passagem de contexto compromete o resultado final da pipeline inteira.
Com a abordagem tradicional de object storage, esse fluxo dependia de sincronizações explícitas entre etapas. O agente A terminava seu trabalho, fazia upload pro S3, o agente B precisava saber que o upload tinha acontecido, baixava o arquivo, trabalhava nele e repetia o ciclo. Além da latência extra em cada etapa, havia o risco real de condições de corrida, onde dois agentes tentavam acessar ou modificar o mesmo objeto ao mesmo tempo sem os mecanismos de controle de concorrência que um file system nativo oferece. O resultado era instabilidade, perda de estado e falhas difíceis de debugar porque aconteciam de forma intermitente e dependiam do tempo de execução de cada agente.
Com o S3 Files e a integração nativa com o Elastic File System, os agentes dentro de uma pipeline passam a compartilhar um file system comum montado sobre o S3. Isso significa que as garantias de consistência e controle de acesso que o EFS oferece se aplicam diretamente sobre os dados que já estão no S3, sem duplicação, sem sincronização e sem a necessidade de gerenciar estado externo.
A AWS informou que milhares de recursos computacionais podem se conectar a um único file system S3 ao mesmo tempo, com throughput agregado de leitura alcançando múltiplos terabytes por segundo. O estado compartilhado entre agentes funciona através de convenções padrão de file system: subdiretórios, arquivos de notas e diretórios de projeto compartilhados que qualquer agente na pipeline pode ler e escrever. Warfield descreveu times de engenharia da própria AWS usando esse padrão internamente, com agentes registrando notas de investigação e resumos de tarefas em diretórios de projeto compartilhados.
Para times que estão construindo pipelines de RAG sobre conteúdo compartilhado entre agentes, o S3 Vectors, lançado no AWS re:Invent em dezembro de 2024, se integra como camada adicional para busca por similaridade e geração aumentada por recuperação sobre esses mesmos dados. 💡
O que os analistas estão dizendo sobre o S3 Files
A reação dos analistas de mercado ao lançamento do S3 Files tem sido bastante positiva, e com perspectivas que vão além da questão puramente técnica de performance.
Jeff Vogel, do Gartner, resumiu bem o impacto: o S3 Files elimina a movimentação de dados entre object storage e file storage, transformando o S3 em um espaço de trabalho compartilhado e de baixa latência sem copiar dados. Nas palavras dele, o file system se torna uma view, não outro dataset. Essa distinção é fundamental porque significa que não existe mais a necessidade de manter duas cópias dos mesmos dados em formatos diferentes.
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
Dave McCarthy, analista do IDC, trouxe uma perspectiva ainda mais ampla sobre o que isso significa para IA agentica. Segundo ele, para AI agentica, que pensa em termos de arquivos, caminhos e scripts locais, o S3 Files é o elo que estava faltando. A funcionalidade permite que um agente de IA trate um bucket de escala exabyte como seu próprio disco rígido local, habilitando um nível de velocidade operacional autônoma que antes estava travado pelo overhead de API associado a abordagens como FUSE.
McCarthy foi além e classificou o lançamento como um ponto de inflexão mais amplo para como as empresas utilizam seus dados. Na visão dele, o lançamento do S3 Files não é apenas o S3 com uma nova interface, mas sim a remoção do último ponto de fricção entre data lakes massivos e IA autônoma. Ao convergir acesso de arquivo e objeto com o S3, a AWS está abrindo portas para mais casos de uso com menos retrabalho.
O que muda para quem está construindo com AI agents hoje
Do ponto de vista prático, o S3 Files representa uma simplificação significativa na stack de infraestrutura de quem trabalha com AI agents em ambientes que já usam o ecossistema AWS. Times que hoje mantêm instâncias extras, scripts de sincronização ou soluções de cache entre o EFS e o S3 passam a ter uma alternativa nativa que elimina essa complexidade operacional. Menos componentes para gerenciar significa menos pontos de falha e menos custo de manutenção a longo prazo, especialmente em projetos que precisam escalar sem aumentar proporcionalmente o tamanho do time de engenharia.
Para equipes corporativas que vinham mantendo um file system separado ao lado do S3 para suportar aplicações baseadas em arquivo ou workloads de agentes, essa arquitetura paralela agora se torna desnecessária. O S3 deixa de ser apenas o destino para onde o agente envia seus resultados e passa a ser o ambiente onde o trabalho do agente efetivamente acontece.
Além disso, há um impacto direto na velocidade de desenvolvimento. Quando os agentes podem trabalhar com file system nativo sobre o Amazon S3, os desenvolvedores podem usar bibliotecas, frameworks e padrões de código que já conhecem, sem precisar adaptar a lógica do agente para lidar com as particularidades de chamadas de API de object storage. Isso reduz a curva de aprendizado para quem está começando com sistemas agenticos e também facilita a migração de pipelines que hoje rodam em ambientes locais ou em outros serviços de cloud para a infraestrutura AWS.
Como Warfield fez questão de ressaltar, todas essas mudanças de API vindas dos times de storage da AWS nascem do trabalho direto e da experiência de clientes usando agentes para trabalhar com dados. O foco está em remover qualquer fricção e fazer essas interações funcionarem da melhor forma possível.
O timing do lançamento do S3 Files também é relevante. O mercado de ferramentas e frameworks para construção de AI agents está crescendo em ritmo acelerado, com novos padrões de arquitetura surgindo constantemente. Ao oferecer uma integração nativa entre object storage e file system agora, a AWS está posicionando o S3 como infraestrutura de dados não só para workloads tradicionais, mas como base confiável para a próxima geração de aplicações inteligentes. E dado que o S3 já é onde a maioria das empresas guarda seus dados corporativos, essa jogada faz bastante sentido dentro de uma estratégia mais ampla de dominância em cloud para IA. 🧠
