Configure nomes de domínio personalizados para agentes Bedrock AgentCore Runtime da Amazon

TL;DR

Utilize o CloudFront como proxy reverso para mapear um domínio personalizado, como https://agent.suaempresa.com, para os endpoints do Bedrock AgentCore Runtime.
Combine CloudFront, Amazon Route 53 e AWS Certificate Manager (ACM) para criar uma configuração de domínio personalizado segura e escalável que funciona com agentes existentes.
Os benefícios incluem integração simplificada para equipes de desenvolvimento, domínios personalizados alinhados à sua organização e uma infraestrutura mais limpa que facilita a manutenção quando os endpoints são atualizados. É possível servir frontend e backend a partir do mesmo domínio para evitar problemas de CORS.
A solução exige certificados SSL na região us-east-1 (para o CloudFront) e a implantação é realizada com o AWS CDK. Ela também pressupõe o uso de OAuth com o Amazon Cognito e que você tenha o ARN do runtime do agente à mão após a implantação.
Esta abordagem é descrita no post do AWS ML Blog, que também aborda testes, limpeza e considerações para uso em produção.

Contexto e visão geral

O Bedrock AgentCore Runtime é apresentado como uma solução de hospedagem independente de framework para agentes de IA. Ele suporta agentes criados com LangGraph, CrewAI, Strands Agents ou implementações personalizadas, e oferece tempo de execução estendido de até 8 horas, microVMs isoladas para cada sessão de usuário e um modelo de preços baseado no consumo. A plataforma inclui autenticação integrada e observabilidade especializada para agentes de IA. Ao usar o AgentCore Runtime com Open Authorization (OAuth), aplicações podem se comunicar diretamente via HTTPS com o endpoint do serviço. Embora essa abordagem direta funcione, há vantagens claras em adotar um domínio personalizado. Ao empregar o CloudFront como proxy reverso, o tráfego de domínio personalizado é transformado em chamadas de API do Bedrock AgentCore Runtime nos bastidores, permitindo que os clientes alcancem uma URL amigável como https://agent.suaempresa.com/ sem alterar a lógica da aplicação. Além do CloudFront, a solução utiliza o Route 53 para gerenciamento de DNS e o ACM para certificados SSL/TLS. Os certificados SSL do CloudFront devem residir na região us-east-1. O artigo original também enfatiza que uma distribuição do CloudFront pode servir tanto ativos de frontend quanto endpoints de backend, reduzindo problemas de CORS porque todo o conteúdo vem do mesmo domínio. O CDK da AWS é usado para implementação do domínio personalizado. Um stack completo é fornecido no post para criar a distribuição CloudFront que faz o proxy das solicitações do domínio personalizado para os endpoints do Bedrock AgentCore Runtime. Se seu frontend estiver em um domínio diferente do domínio do agente, você precisará configurar cabeçalhos CORS para permitir chamadas entre domínios. Se estiver começando do zero, você criará (ou identificará) o ARN do runtime do agente após a implantação, pois precisará dele para a configuração do domínio personalizado. O post também destaca um fluxo de testes usando um token JWT do Cognito e mostra como testar com o domínio personalizado e com o domínio padrão do CloudFront.

O que houve de novo

Esta abordagem documenta como usar o CloudFront como proxy reverso para expor um endpoint de domínio personalizado para Bedrock AgentCore Runtime. Elementos-chave:

Uma distribuição CloudFront configurada para encaminhar solicitações do seu domínio personalizado para as chamadas de API do Bedrock AgentCore Runtime.
Uma distribuição única que pode servir tanto frontend quanto backend, reduzindo a complexidade de CORS.
Uma implementação baseada em AWS CDK que empacota CloudFront, Route 53, ACM e as permissões necessárias para proxy de solicitações para os endpoints do Bedrock AgentCore Runtime.
Orientações claras sobre pré-requisitos, como garantir certificados SSL em us-east-1 e obter o ARN do runtime do agente após a implantação.
Instruções de teste usando JWT do Cognito para autenticação de solicitações ao domínio personalizado ou ao domínio CloudFront, e etapas para validar respostas adequadas.

Por que isso importa (impacto para desenvolvedores/empresas)

Integração simplificada: equipes podem apontar aplicações para um domínio familiar em vez do endpoint técnico do Bedrock, acelerando fluxos de trabalho de desenvolvimento.
Alinhamento de domínio com a organização: domínios personalizados ajudam na marcação e consistência entre aplicações e serviços.
Infraestrutura mais limpa: servir frontend e backend a partir de um único domínio reduz problemas de CORS.
Práticas de produção: o artigo destaca autenticação, observabilidade e manutenibilidade, além da necessidade de limpeza de recursos para controle de custos.
Segurança e escalabilidade: a solução utiliza um proxy reverso com CloudFront, certificados ACM, DNS Route 53 e as capacidades de autenticação/observabilidade integradas do Bedrock AgentCore Runtime.

Detalhes técnicos ou Implementação

O artigo original oferece um passo a passo para configurar o CloudFront como proxy reverso para o Bedrock AgentCore Runtime. Pontos centrais:

O endpoint padrão do AgentCore Runtime é similar a https://bedrock-agentcore.`{regiao}`.amazonaws.com/runtimes/`{EncodedAgentARN}`/invocations. O objetivo é apresentar um domínio amigável, como https://agent.suaempresa.com.
Você deve escolher entre as opções de domínio apresentadas no guia e, se estiver apenas testando, pode começar com uma opção pré-definida antes de configurar o domínio completo.
Os certificados SSL para o CloudFront devem estar na região us-east-1. Esse é um requisito específico do CloudFront ao usar ACM para certificados.
Se seu domínio de frontend for diferente do domínio do agente, configure cabeçalhos CORS para permitir solicitações entre domínios.
Para evitar cache de respostas de agente, defina a política de cache do CloudFront como CachePolicy.CACHING_DISABLED.
O stack completo do AWS CDK é fornecido no post para orquestrar a distribuição CloudFront, o Hosted Zone do Route 53 (se aplicável) e o certificado ACM, junto com as permissões necessárias para encaminhar solicitações aos endpoints do Bedrock AgentCore Runtime.
Após a implantação, você pode testar usando o domínio personalizado ou o domínio padrão do CloudFront. Os passos de teste incluem obter um token JWT do Cognito e usar esse token para chamar o endpoint do agente. O post fornece exemplos de código para testar com o domínio personalizado e com o domínio do CloudFront para validar as respostas apropriadas.
Cuidados com custos: para evitar gastos contínuos, exclua os recursos quando não forem mais necessários, incluindo zonas hospedadas do Route 53 e certificados ACM. Do ponto de vista de segurança e operações, o Bedrock AgentCore oferece autenticação integrada e observabilidade especializada para agentes de IA. A integração com OAuth e com o Amazon Cognito como provedor de identidade facilita a autenticação de solicitações por meio de tokens emitidos pelo Cognito e a verificação de que as solicitações passam pelo proxy CloudFront. O Bedrock AgentCore está em pré-visualação e sujeito a alterações. Os preços padrão da AWS se aplicam aos serviços adicionais utilizados (CloudFront, Route 53, ACM), portanto, leve esses custos em consideração no planejamento.

Esboço de implementação (alto nível)

Identificar ou implantar um agente baseado no Bedrock AgentCore Runtime e capturar o ARN do runtime após a implantação.
Preparar um domínio personalizado (ex.: agent.suaempresa.com) e configurar DNS/SSL na us-east-1 via Route 53 e ACM.
Implantar uma distribuição CloudFront usando AWS CDK que encaminha solicitações para os endpoints do Bedrock AgentCore Runtime, aplicando política de cache para conteúdo dinâmico.
Se frontend e backend usarem domínios diferentes, configurar CORS para permitir chamadas entre domínios conforme necessário.
Testar a configuração obtendo um token JWT do Cognito e realizando chamadas de teste aos endpoints via domínio personalizado e via domínio CloudFront.
Monitorar recursos de segurança e observabilidade oferecidos pelo Bedrock AgentCore Runtime e planejar a limpeza ao encerrar o ambiente.

Pontos-chave

Domínios personalizados simplificam a integração e ajudam na consistência de branding.
CloudFront, Route 53 e ACM formam um stack coeso para um proxy seguro e escalável na frente do Bedrock AgentCore Runtime.
Uma distribuição CloudFront pode atender frontend e backend, reduzindo a complexidade de CORS.
Use o stack CDK fornecido no post para automatizar a implantação.
Considere segurança, monitoramento e custos, incluindo limpeza de recursos ao terminar.

FAQ

Qual o benefício de usar um domínio personalizado com Bedrock AgentCore Runtime?

Proporciona uma experiência profissional e integrada, facilita o branding organizacional e simplifica a integração ao consolidar o acesso sob um domínio único, mantendo a chamada direta ao Bedrock AgentCore Runtime.
uais serviços da AWS são usados nessa solução?

CloudFront como proxy reverso, Route 53 para DNS e ACM para certificados SSL, orquestrados via AWS CDK.
Existem pré-requisitos para certificados SSL e regiões?

Sim. Certificados SSL para o CloudFront devem ficar na us-east-1. O artigo utiliza esse requisito como parte da arquitetura.
Como testar a configuração do domínio personalizado?

pós a implantação, obtenha um token JWT do Cognito e use-o para autenticar chamadas ao domínio personalizado ou ao domínio CloudFront, validando que as respostas chegam corretamente ao Bedrock AgentCore Runtime.
O que fazer para limpar recursos quando não forem mais necessários?

Exclua a distribuição CloudFront, certificados ACM e quaisquer zonas hospedadas do Route 53 criadas para a solução para evitar custos contínuos.