Amazon Bedrock AgentCore Runtime com filesystem próprio
TL;DR
O Amazon Bedrock AgentCore Runtime passou a aceitar um filesystem trazido pelo usuário, com suporte a Amazon S3 Files e Amazon EFS access points. Na prática, isso reduz a necessidade de camadas customizadas para sincronizar arquivos entre agente, bucket e storage compartilhado.
Para quem constrói agentes com estado, artefatos ou datasets persistentes, a mudança simplifica o desenho da arquitetura e abre espaço para compartilhamento controlado entre sessões. O ponto central é tratar storage como parte declarativa do runtime, e não como um detalhe improvisado fora dele.
O que mudou no AgentCore Runtime
O anúncio da AWS de maio de 2026 informa que o Amazon Bedrock AgentCore Runtime agora suporta bring-your-own file system com Amazon S3 Files e Amazon EFS. A documentação oficial de filesystem configurations para AgentCore Runtime mostra que esse suporte é exposto por configuração declarativa, por meio de mounts definidos no runtime.
Isso importa porque o agente deixa de depender só de memória volátil da sessão para trabalhar com arquivos. Em vez de reconstruir artefatos a cada execução, o runtime passa a oferecer um ponto consistente para leitura e escrita, com persistência ou compartilhamento conforme o tipo de storage montado.
S3 Files como filesystem persistente compartilhado
O guia da AWS descreve o uso de S3 Files with AgentCore Runtime como um filesystem compartilhado e persistente. A ideia é direta: o agente trabalha com operações de arquivo padrão e o conteúdo é sincronizado de volta para o armazenamento subjacente, algo útil para artefatos de sessão, templates, uploads e saídas intermediárias.
Esse padrão evita criar um serviço intermediário só para copiar arquivos entre o runtime e o bucket. Para workloads de IA, isso reduz um ponto de complexidade bem comum: o agente gerar um arquivo, outro componente mover esse arquivo, e uma terceira etapa garantir que o repositório certo recebeu a versão final.
Amazon EFS para compartilhamento em estilo filesystem tradicional
Além de S3 Files, o anúncio também cita Amazon EFS access points como opção de BYO filesystem. Isso encaixa melhor quando o projeto quer um compartilhamento de arquivos com semântica de filesystem tradicional, especialmente em cenários em que múltiplas execuções precisam acessar o mesmo conjunto de dados, modelos auxiliares ou documentos de trabalho.
Na prática, isso permite escolher o tipo de storage pelo comportamento esperado do dado. S3 Files faz sentido quando a persistência baseada em objetos com sync é suficiente; EFS faz mais sentido quando o problema pede acesso compartilhado mais próximo do padrão NFS.
Configuração declarativa no runtime
A documentação da AWS indica o uso do parâmetro filesystemConfigurations para definir montagens de filesystem no AgentCore Runtime. O schema oficial de FilesystemConfiguration confirma que a configuração é feita de forma estruturada, com paths definidos para cada mount.
Esse detalhe ajuda muito em ambientes com múltiplos domínios de dados. Dá para separar, por exemplo, um diretório para workspace persistente, outro para ativos compartilhados e outro para arquivos temporários, sem misturar responsabilidade em uma única pasta genérica.
Isolamento por sessão e storage compartilhado
O material de exemplo da AWS reforça o modelo de session isolation with shared storage: cada sessão roda isolada em sua própria microVM, enquanto o filesystem montado pode ser comum entre execuções. Esse desenho é interessante porque preserva isolamento operacional, mas ainda permite reuso de artefatos quando o caso de uso pede colaboração ou persistência.
Para agentes multi-etapa, isso é especialmente útil. Um agente pode criar um arquivo de trabalho, uma segunda sessão pode continuar a partir dele, e um pipeline maior pode consultar o mesmo mount sem precisar inventar um mecanismo paralelo de sincronização.
Onde isso muda a arquitetura na prática
O principal ganho é retirar fricção do ciclo de vida de arquivos do agente. Se antes era comum tratar S3 ou EFS como integrações externas, agora o storage passa a participar do contrato de execução do runtime. Isso abre espaço para arquiteturas mais legíveis, em que o que é persistente fica montado e o que é efêmero continua na sessão.
Em projetos de assistentes que geram relatórios, rascunhos de código, embeddings auxiliares, índices ou anexos processados, essa abordagem simplifica bastante o fluxo. O agente pode ler, alterar e salvar arquivos no mesmo contexto operacional, sem depender de um orquestrador externo para cada passo.
Exemplo de desenho mental de diretórios
Um desenho comum é reservar caminhos diferentes para cada tipo de dado. O workspace do agente pode ficar em um mount persistente, os assets compartilhados em outro e os arquivos temporários em uma área separada, reduzindo colisão entre sessões e deixando a governança mais previsível.
Esse tipo de organização também ajuda quando o time precisa auditar o que é entrada, o que é saída e o que pode ser reaproveitado. Em vez de espalhar estado por múltiplos serviços, o runtime concentra o contrato de armazenamento em uma configuração única e revisável.
Permissões não são detalhe
A documentação de troubleshooting da AWS lembra que o role de execução precisa ter permissões adequadas para o storage utilizado, inclusive para operações relacionadas a S3 Files e EFS: runtime troubleshooting. Em outras palavras, montar o filesystem é só parte da história; o acesso real ao caminho depende da política aplicada ao runtime.
Na prática, vale revisar o IAM com o mesmo cuidado que você já revisa acesso a bucket, access point e rede. Para um agente, erro de permissão em storage aparece como falha de execução, então essa camada precisa entrar no desenho desde o começo.
Quando escolher S3 Files e quando escolher EFS
A escolha tende a seguir o comportamento esperado do dado. Se o objetivo principal é persistir artefatos e manter um fluxo simples de leitura e escrita com sincronização, S3 Files se encaixa bem. Se o trabalho pede um filesystem compartilhado mais tradicional, EFS ganha força por causa da semântica de acesso.
Para times de engenharia, a decisão costuma ser menos sobre “qual é mais moderno” e mais sobre latência, padrão de acesso, custo e previsibilidade operacional. Em workloads com arquivos grandes, acesso concorrente ou dependência de layout filesystem clássico, EFS costuma ser uma leitura natural; para persistência compartilhada de artefatos, S3 Files atende bem ao caso.
Um cuidado importante: não confundir persistência com banco de dados
O suporte a filesystem não transforma o runtime em storage transacional. Arquivos persistentes ajudam a organizar estado e artefatos, mas não substituem mecanismos próprios para consistência forte, versionamento de fatos críticos ou controle de concorrência de alto nível. Se o agente precisa registrar transações, a base de dados continua sendo a peça certa para isso.
Por isso, o bom uso dessa novidade é manter no filesystem aquilo que combina com arquivo: documentos, templates, relatórios, módulos auxiliares, outputs intermediários e material de trabalho. Para dados estruturados e operações de negócio, o caminho usual continua sendo banco, fila ou serviço dedicado.
Por que importa pro dev brasileiro
O contexto brasileiro pesa mais do que parece aqui por causa de custo, região e governança. Muitos times no Brasil precisam equilibrar orçamento em BRL com serviços cobrados em dólar, além de lidar com latência para regiões como us-east-1 e com regras de tratamento de dados sob a LGPD. Isso faz qualquer simplificação de arquitetura de storage ser mais relevante do que em cenários onde o time tem folga orçamentária e baixa fricção regulatória.
Na prática, montar filesystem no runtime pode reduzir a quantidade de componentes intermediários, o que ajuda especialmente times pequenos, squads de produto e consultorias que operam com orçamento apertado. Menos serviço para manter também significa menos superfície para erro em ambiente com deploys frequentes e times que muitas vezes acumulam cloud, backend e IA ao mesmo tempo.
Limites e pontos de atenção
Mesmo com a novidade, vale olhar com cuidado para o comportamento real do storage no seu caso de uso. Montagem declarativa resolve a parte de integração, mas não elimina a necessidade de pensar em concorrência, ciclo de vida de arquivos, retenção e governança de acesso.
Outro ponto é separar o que deve ser compartilhado entre sessões do que deve permanecer isolado. Se vários agentes acessam o mesmo mount, a disciplina de nomenclatura e diretórios se torna essencial para evitar sobrescrita acidental e dependência invisível entre execuções.
Conclusão
O suporte a bring-your-own file system no Amazon Bedrock AgentCore Runtime deixa o armazenamento mais próximo do contrato de execução do agente. Com S3 Files e EFS, o time ganha uma forma declarativa de persistir e compartilhar arquivos sem construir uma camada própria de sincronização para cada projeto.
Se você trabalha com agentes que produzem artefatos, relatórios ou conhecimento operacional, vale validar rapidamente se o seu fluxo atual ainda precisa daquele serviço intermediário de cópia. Em até 1 hora, abra a documentação oficial de filesystem configurations e rascunhe como dividiria workspace, assets e temporários em mounts separados no seu runtime atual.
Conteúdos da DIO para quem quer aprofundar
- AWS - Cloud Amazon Web Services — trilha de introdução e aprofundamento em serviços AWS, útil para contextualizar storage, rede e fundamentos de nuvem.
- CI&T - Backend com Java & AWS — trilha focada em backend com Java e AWS, boa para quem quer ligar arquitetura de aplicações com serviços de nuvem.
- Formação AWS CLF-02 Practitioner — formação para base de cloud na AWS, ajudando a organizar conceitos que aparecem em runtime, IAM e storage.
- Nexa - Engenharia de Prompts na AWS com Claude — trilha que combina IA e AWS, útil para quem quer desenhar agentes e fluxos aplicados a serviços cloud.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
