AWS Bedrock AgentCore: o que muda no VPC mode e no acesso a S3

TL;DR

A partir de 5 de maio de 2026, runtimes novas do Amazon Bedrock AgentCore em modo VPC deixam de receber, por padrão, um S3 gateway endpoint service-managed. Isso muda o ponto de responsabilidade: conectividade com S3 passa a ser definida pela sua VPC, e não mais pelo runtime.

Na prática, quem usa isolamento em VPC precisa revisar endpoints, rotas e dependências de startup para evitar falhas ao baixar código e imagens. Em times que rodam workloads na região sa-east-1 ou mantêm tráfego sensível por compliance, essa checagem vira item de arquitetura, não detalhe operacional.

O que mudou no AgentCore Runtime

A documentação da AWS passou a descrever que, em runtimes criadas após o rollout, o modo VPC não inclui mais o gateway S3 service-managed por padrão. O efeito direto é simples: todo tráfego, inclusive para Amazon S3, passa a ser governado exclusivamente pela configuração da sua VPC. Veja os detalhes na referência da AWS CLI e na API VpcConfig.

O nome do ajuste é requireServiceS3Endpoint. Em termos práticos, ele indica se a runtime vai depender do endpoint S3 service-managed no desenho de rede. Quando essa camada deixa de existir por padrão, o time responsável pela VPC precisa garantir a rota para S3 por conta própria.

Impacto prático no acesso a S3

O ponto mais sensível está no startup. A própria documentação associa o endpoint service-managed ao download de código e imagens no momento de inicialização da runtime. Sem conectividade adequada com S3, a aplicação pode nem subir, mesmo que o código esteja correto e os artefatos estejam disponíveis.

Isso afeta padrões comuns de operação em AWS: imagem em ECR, camadas armazenadas em S3, artefatos versionados e inicialização em subnets privadas. Se a VPC não tiver um Gateway VPC Endpoint para S3, ou se as rotas estiverem incompletas, o runtime perde o caminho até os artefatos que precisa carregar.

O que revisar na VPC

• Gateway endpoint para Amazon S3 nas subnets que hospedam a runtime.
• Tabelas de rotas associadas ao endpoint.
• Políticas do endpoint, se houver restrição por bucket ou prefixo.
• Dependências de startup que leem arquivos de S3 antes da aplicação ficar pronta.

A documentação de VPC do AgentCore reforça que, em cenários sem internet, endpoints VPC deixam de ser opcional e viram parte da infraestrutura básica. Na prática, o desenho precisa ser consistente para S3, ECR e demais serviços usados pela runtime.

Como isso muda a operação de quem já tinha runtime em produção

Runtimes existentes antes do rollout não são afetadas automaticamente. O cuidado maior está em ambientes novos, em recriações e em pipelines que sobem infraestrutura a partir de IaC. É fácil achar que a configuração “já vinha pronta” e só descobrir a lacuna quando a primeira instância tenta iniciar.

Se sua equipe usa atualização de runtime via UpdateAgentRuntime, vale ler a documentação com atenção antes de aplicar mudanças em produção. Uma alteração aparentemente pequena no parâmetro de rede pode mudar o comportamento de bootstrap e exigir ajuste fino em endpoints, NAT ou blocos de segurança.

Onde isso pega times brasileiros

No Brasil, esse tipo de ajuste costuma doer mais em dois contextos. Primeiro, em empresas que mantêm workloads na região de São Paulo para reduzir latência e cumprir exigências internas de residência de dados, como projetos sujeitos à LGPD. Segundo, em times que tentam evitar NAT por custo em real, porque tráfego de inicialização e artefatos pode crescer rápido em ambientes com muitas réplicas.

Também é comum encontrar arquiteturas com subnets privadas e pouca folga de orçamento para conectividade redundante. Nesse cenário, esquecer o endpoint de S3 não é só uma falha técnica: pode virar indisponibilidade em janela de deploy, atraso de produto e custo inesperado em AWS.

Checklist de preparação

1. Confirme se a runtime foi criada antes ou depois do rollout de 5 de maio de 2026.
2. Verifique se a VPC tem gateway endpoint para S3 e as rotas corretas.
3. Revise se os artefatos de startup, artefatos de build e dependências estão em buckets acessíveis pela política do endpoint.
4. Teste um deploy em ambiente isolado antes de promover para produção.
5. Documente a decisão de manter ou não o endpoint service-managed, junto com o motivo arquitetural.

Se sua runtime depende de artefatos em S3 para iniciar, trate a conectividade como requisito funcional. A falha de rede acontece antes do seu código conseguir logar qualquer erro útil.

Conclusão

O update de 2026 não cria apenas uma nova opção de configuração; ele empurra o controle de conectividade para a VPC e torna explícito algo que antes vinha abstraído pelo serviço. Para equipes que operam AgentCore em modo VPC, o ganho está em previsibilidade, mas só depois que a infraestrutura estiver corretamente desenhada.

O próximo passo mais útil é abrir a documentação oficial da AWS sobre o parâmetro requireServiceS3Endpoint e comparar com a sua topologia atual de VPC, subnets e endpoints. Em menos de uma hora, você consegue validar se sua runtime tem caminho real até S3 antes de descobrir isso num deploy falho.

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