Como o AgentCore Runtime passa a montar S3 Files e EFS

TL;DR

O Amazon Bedrock AgentCore Runtime passou a aceitar um filesystem “bring-your-own” nas sessões, com montagem via filesystemConfigurations para Amazon S3 Files e Amazon EFS. Na prática, isso dá ao agente um caminho mais direto para ler e escrever arquivos no runtime, sem depender de gambiarras de sincronização para cada cenário.

Para quem constrói agentes com estado, artefatos temporários ou integração com storage legado, a mudança simplifica a arquitetura e aproxima o runtime do modelo de filesystem que muitos times já conhecem. A atenção agora vai para o desenho do mount path, a escolha entre S3 Files e EFS e os limites de cada opção.

O que mudou no AgentCore Runtime

A novidade anunciada pela AWS é o suporte a filesystem “bring-your-own” no AgentCore Runtime, com Amazon S3 Files e Amazon EFS como origens montáveis nas sessões do agente (fonte oficial). Em vez de tratar o storage como algo externo à execução, o runtime passa a expor um path montado para uso direto pelo agente.

A documentação oficial descreve a configuração por meio de filesystemConfigurations, que concentra os parâmetros de mount e a associação com o storage escolhido (documentação). Isso é relevante porque transforma o storage em parte explícita da configuração do runtime, e não em um detalhe solto na aplicação.

Por que isso importa para agentes

Agentes que geram arquivos, consultam artefatos, salvam checkpoints ou compartilham dados entre etapas costumam sofrer quando o storage vira uma camada paralela demais da aplicação. Ao montar o filesystem no runtime, o código do agente pode operar com leitura e escrita de arquivos em um path conhecido, usando o modelo mental de sistema de arquivos que já existe em aplicações tradicionais.

Esse encaixe é especialmente útil quando o agente precisa lidar com artefatos intermediários, relatórios, planilhas, JSONs ou saídas de ferramentas externas. Em vez de orquestrar upload e download a cada passo, você concentra a semântica de persistência no mount configurado.

S3 Files e EFS não são a mesma coisa

A AWS oferece duas opções nessa novidade, e vale separar bem os papéis. O S3 Files entra como opção mais próxima de um armazenamento de objetos exposto por access point, enquanto o Amazon EFS oferece um filesystem de rede com semântica mais tradicional para diretórios e arquivos compartilhados (docs).

O ponto prático é simples: se o seu caso parece mais com troca de artefatos e arquivos de sessão, o S3 Files pode ser suficiente; se você precisa de uma superfície compartilhada com comportamento mais próximo de filesystem POSIX para múltiplas execuções, o EFS tende a encaixar melhor. A escolha depende do padrão de acesso, da consistência esperada e da forma como a sua aplicação já organiza os dados.

Mount path e a regra de /mnt

No caso de S3 Files access points, a documentação do esquema informa que o mount path precisa ficar sob /mnt e seguir a restrição de um único nível de subdiretório, como /mnt/<subdir> (schema oficial). Esse detalhe parece pequeno, mas ele guiará a estrutura real do seu código e da sua organização de arquivos.

Para EFS access points, a configuração também depende de montar o access point em um path definido dentro de filesystemConfigurations (SDK oficial). O que muda aqui não é só o backend de storage; muda a forma como você planeja o layout dos diretórios do agente.

Como pensar a arquitetura com esse recurso

O ganho principal não está em “ter storage”, porque isso todo stack já tem. O ganho está em tornar o storage parte do contrato do runtime do agente, o que reduz o número de pontos de integração para o seu código e para as ferramentas chamadas pelo agente.

Em cenários com múltiplas etapas, isso evita que cada tool precise conhecer detalhes de buckets, prefixes, chaves ou endpoints. O agente trabalha com arquivos montados, e a infraestrutura resolve a ponte para o backend escolhido.

Um desenho comum em produção

Um padrão razoável é separar três zonas: entrada, trabalho e saída. A entrada contém documentos ou contexto inicial; a zona de trabalho guarda transformações intermediárias; a saída concentra o artefato final que será entregue a outro serviço ou à interface da aplicação.

Num fluxo mais simples, isso pode significar montar algo como /mnt/input e /mnt/output quando a documentação e as restrições da configuração permitirem esse desenho. O importante é que o agente não precise adivinhar onde está cada tipo de arquivo, porque a estrutura já vem do runtime.

Se o seu caso depender de versão específica do SDK, da API ou do CLI da AWS, revise o changelog oficial antes de colocar em produção. Em serviços de IA, a superfície de integração muda rápido e pequenos detalhes de configuração podem alterar o comportamento do runtime.

Impacto em persistência, compartilhamento e observabilidade

Há uma diferença importante entre persistir estado da sessão e montar um filesystem próprio. Persistência de sessão é útil para manter contexto entre interações; filesystem montado é mais indicado quando a unidade relevante é arquivo, diretório ou artefato compartilhado (contexto de session storage).

Isso abre espaço para separar responsabilidades. O contexto conversacional fica em um mecanismo de sessão, enquanto documentos, payloads e saídas de ferramentas ficam no filesystem montado. Para quem mantém pipelines de agente, essa separação ajuda a diagnosticar falhas e a recuperar artefatos sem misturar tudo no mesmo mecanismo.

Também há ganho indireto de observabilidade. Quando a aplicação trabalha com paths claros, fica mais fácil inspecionar o que o agente leu, alterou ou gerou. Isso é útil tanto para depuração quanto para auditoria operacional.

Por que importa pro dev brasileiro

Esse tipo de integração pesa mais no Brasil porque muitas equipes precisam equilibrar arquitetura, custo e conformidade ao mesmo tempo. Em projetos com dados pessoais, a LGPD exige cuidado com tratamento, retenção e compartilhamento de dados, então decidir entre S3 Files e EFS não é só uma escolha técnica; é também uma escolha de governo de dados (Lei 13.709/2018).

Além disso, times no Brasil frequentemente operam com margens mais apertadas e com infraestrutura concentrada em regiões da AWS fora do país. Quando o acesso a arquivos vira parte do runtime do agente, o custo de tráfego, armazenamento e latência deixa de ser detalhe e entra no desenho da solução desde o início. Isso faz diferença em SaaS, fintechs e áreas reguladas que precisam justificar cada camada da arquitetura.

Na prática, uma equipe brasileira pode usar esse recurso para reduzir retrabalho entre o agente e serviços internos já consolidados, sem abrir mão de controles de acesso e rastreabilidade. Em vez de criar mais uma integração ad hoc, o time monta o storage que já faz parte do processo operacional da empresa.

Quando usar e quando evitar

Vale usar essa feature quando o agente realmente trabalha com arquivos: relatórios, planilhas, extratos, logs, anexos ou pacotes de contexto que precisam sobreviver a uma etapa de processamento. Também faz sentido quando você quer compartilhar arquivos entre tools diferentes sem replicar lógica de upload e download em cada uma delas.

Por outro lado, se o seu agente só precisa guardar pequenas variáveis de estado, talvez storage montado seja mais do que o necessário. Nesses casos, um mecanismo de session storage ou uma base leve de metadados pode resolver com menos complexidade operacional.

Outro cuidado é não transformar o filesystem em “banco de dados disfarçado”. Arquivos são ótimos para artefatos e documentos; para consultas estruturadas e concorrência alta, outras camadas continuam mais apropriadas.

O que revisar antes de adotar

Antes de colocar isso em um fluxo real, vale conferir três pontos: o formato permitido do mount path, as permissões do access point e a estratégia de leitura e escrita do agente. Esses detalhes aparecem na documentação oficial e precisam ser validados no seu desenho de runtime (docs, schema).

Também é prudente testar como o agente se comporta quando o arquivo não existe, quando o diretório está vazio e quando há conflito de escrita. O valor do recurso aparece justamente nesses casos reais de execução, não só no caminho feliz.

Conclusão

O suporte a filesystem próprio no Amazon Bedrock AgentCore Runtime aproxima a execução do agente de um modelo mais direto de arquivos e diretórios, com S3 Files e EFS entrando como opções de montagem oficial. Para aplicações com artefatos, contexto persistente e integração com storage já existente, isso reduz fricção arquitetural e torna o desenho do agente mais previsível.

Se você já trabalha com Bedrock AgentCore, a ação mais útil agora é abrir a documentação de filesystemConfigurations, escolher um caso real do seu projeto e mapear um mount path válido para testar localmente a leitura e a escrita de um artefato simples em até 1 hora (documentação oficial).

Conteúdos da DIO para quem quer aprofundar

• Formação AWS CLF-02 Practitioner — oferece uma base sólida nos conceitos essenciais da computação em nuvem pela AWS, cobrindo valor de negócio, segurança, conformidade e estratégias de migração.
• AWS - Cloud Amazon Web Services — trilha com conteúdo do básico ao preparatório para certificações, incluindo cursos exclusivos AWS e mentorias ao vivo com experts certificados.
• Cloud Computing & Serverless — apresenta ferramentas de nuvem e serviços do Azure, com foco em criação de conta, otimização de trabalho e entendimento prático dos serviços disponíveis.

Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.