Configurar nombres de dominio personalizados para los agentes Bedrock AgentCore Runtime de Amazon

TL;DR

Usa CloudFront como proxy inverso para mapear un dominio personalizado, por ejemplo https://agent.tuempresa.com, a los endpoints de Bedrock AgentCore Runtime.
Combina CloudFront, Amazon Route 53 y AWS Certificate Manager (ACM) para crear una configuración de dominio personalizado segura y escalable que funcione con agentes existentes.
Los beneficios incluyen integración simplificada para equipos de desarrollo, dominios personalizados alineados con la organización y una infraestructura más limpia que facilita el mantenimiento cuando los endpoints se actualizan. Puedes servir frontend y backend desde el mismo dominio para evitar problemas de CORS.
La solución requiere certificados SSL en la región us-east-1 (para CloudFront) y la implementación se realiza con AWS CDK. También se asume el uso de OAuth con Amazon Cognito y tener a mano el ARN del runtime del agente tras la implementación.
Este enfoque se describe en el blog de AWS ML, que también cubre pruebas, limpieza y consideraciones para producción.

Contexto y antecedentes

Bedrock AgentCore Runtime se presenta como una solución de hosting independiente del framework para agentes de IA. Soporta agentes construidos con LangGraph, CrewAI, Strands Agents o implementaciones personalizadas, ofrece tiempos de ejecución extendidos de hasta 8 horas, microVMs aisladas para cada sesión y un modelo de precios basado en el consumo. La plataforma incluye autenticación integrada y observabilidad especializada para agentes de IA. Cuando se usa AgentCore Runtime con Open Authorization (OAuth), las aplicaciones pueden comunicarse directamente a través de HTTPS con el endpoint del servicio. Aunque esto funciona, existen ventajas al adoptar un dominio personalizado. Al usar CloudFront como proxy inverso, el tráfico del dominio personalizado se transforma en llamadas de API de Bedrock AgentCore Runtime, permitiendo a los clientes acceder a una URL amigable como https://agent.tuempresa.com/ sin cambiar la lógica de la aplicación. Además de CloudFront, la solución utiliza Route 53 para la gestión de DNS y ACM para certificados SSL/TLS. Los certificados SSL de CloudFront deben residir en la región us-east-1. El artículo también enfatiza que una distribución de CloudFront puede servir tanto para frontend como para endpoints de backend, evitando problemas de CORS porque todo proviene del mismo dominio. El CDK de AWS se usa para la implementación del dominio personalizado. Se proporciona un stack completo en el artículo para crear la distribución de CloudFront que proxy las solicitudes de Bedrock AgentCore Runtime. Si tu frontend se ejecuta en un dominio distinto al del agente, deberás configurar encabezados CORS para permitir llamadas entre dominios. Si estás empezando desde cero, deberás obtener el ARN del runtime del agente tras la implementación, ya que lo necesitarás para configurar el dominio personalizado. El artículo también destaca un flujo de pruebas que usa un token JWT de Cognito y muestra cómo probar tanto con el dominio personalizado como con el dominio de CloudFront.

Qué hay de nuevo

Este enfoque documenta el uso de CloudFront como proxy inverso para exponer un endpoint de dominio personalizado para Bedrock AgentCore Runtime. Elementos clave:

Una distribución de CloudFront configurada para enrutar las solicitudes desde tu dominio personalizado hacia las llamadas API de Bedrock AgentCore Runtime.
Una única distribución que puede servir tanto frontend como backend, reduciendo la complejidad de CORS.
Una implementación basada en AWS CDK que agrupa CloudFront, Route 53, ACM y los permisos necesarios para el proxy de solicitudes hacia los endpoints de Bedrock AgentCore Runtime.
Requisitos previos claros, como asegurar certificados SSL en us-east-1 y obtener el ARN del runtime tras la implementación.
Instrucciones de prueba con un JWT de Cognito para autenticar las solicitudes y ejemplos de prueba tanto para el dominio personalizado como para el dominio de CloudFront.

Por qué importa (impacto para desarrolladores/empresas)

Integración simplificada: los equipos pueden apuntar sus aplicaciones a un dominio familiar en lugar del endpoint de Bedrock, acelerando flujos de desarrollo.
Alineación de dominio con la organización: los dominios personalizados ayudan con la marca y la coherencia entre aplicaciones y servicios.
Infraestructura más limpia: servir frontend y backend desde un único dominio reduce los problemas de CORS.
Consideraciones para producción: el artículo enfatiza la autenticación, observabilidad y mantenibilidad, y recomienda planificar la limpieza de recursos para controlar costos.
Seguridad y escalabilidad: la solución usa un proxy inverso con CloudFront, certificados ACM, DNS Route 53 y capacidades de autenticación y observabilidad integradas del Bedrock AgentCore Runtime.

Detalles técnicos o Implementación

El artículo describe un procedimiento para configurar CloudFront como proxy inverso para Bedrock AgentCore Runtime. Puntos clave:

El endpoint por defecto es similar a https://bedrock-agentcore.`{región}`.amazonaws.com/runtimes/`{EncodedAgentARN}`/invocations. El objetivo es presentar un dominio amigable como https://agent.tuempresa.com.
Debes elegir entre las opciones de dominio presentadas y, si estás probando, empezar con una opción preconfigurada antes de configurar el dominio completo.
Los certificados SSL para CloudFront deben estar en us-east-1. Este es un requisito específico de CloudFront al usar ACM.
Si tu frontend usa un dominio distinto del del agente, debes configurar encabezados CORS para permitir llamadas entre dominios.
Para evitar caching de respuestas del agente, configura la política de caché de CloudFront en CachePolicy.CACHING_DISABLED.
El stack completo de AWS CDK se proporciona en el artículo para orquestar la distribución de CloudFront, el Hosted Zone de Route 53 (si aplica) y el certificado ACM, con los permisos necesarios para proxy de las solicitudes hacia los endpoints Bedrock AgentCore Runtime.
Tras la implementación, puedes probar usando el dominio personalizado o el dominio por defecto de CloudFront. Las pruebas incluyen obtener un token JWT de Cognito y usarlo para autenticar las llamadas. Se proporcionan ejemplos de código para probar con el dominio personalizado y con el dominio de CloudFront para validar las respuestas.
Limpieza: para evitar costos continuos, elimina los recursos cuando ya no los necesites (zonas hosted de Route 53 y certificados ACM). Desde el punto de vista de seguridad y operaciones, Bedrock AgentCore ofrece autenticación integrada y observabilidad especializada para los agentes de IA. La integración con OAuth y Cognito facilita la autenticación mediante tokens Cognito y garantiza que las llamadas pasen por el proxy CloudFront. Bedrock AgentCore está en vista previa y sujeto a cambios. Los precios estándar de AWS se aplican a servicios adicionales usados (CloudFront, Route 53, ACM).

Esquema de implementación (alto nivel)

Identificar o desplegar un agente basado en Bedrock AgentCore Runtime y capturar el ARN del runtime tras la implementación.
Preparar un dominio personalizado (p. ej., agent.tuempresa.com) y configurar DNS/SSL en us-east-1 a través de Route 53 y ACM.
Desplegar una distribución CloudFront con AWS CDK que dirija las solicitudes a los endpoints Bedrock AgentCore Runtime, aplicando una política de caché para contenido dinámico.
Si frontend y backend usan dominios diferentes, configurar CORS para permitir llamadas entre dominios según sea necesario.
Probar la configuración obteniendo un JWT de Cognito y realizando llamadas de prueba a los endpoints mediante el dominio personalizado y el dominio CloudFront.
Supervisar seguridad y observabilidad y planificar la limpieza cuando el entorno ya no sea necesario.

Puntos clave

Dominios personalizados simplifican la integración y fortalecen la marca organizacional.
CloudFront, Route 53 y ACM forman una pila segura y escalable frente a Bedrock AgentCore Runtime.
Una distribución CloudFront puede atender frontend y backend, reduciendo la complejidad de CORS.
Utiliza el stack CDK proporcionado para automatizar la implementación.
Considera seguridad, monitoreo y costos, incluyendo la limpieza de recursos al finalizar.