Configurer des noms de domaine personnalisés pour les agents Bedrock AgentCore Runtime d’Amazon

TL;DR

Utiliser CloudFront comme proxy inverse pour mapper un domaine personnalisé, par exemple https://agent.votreentreprise.com, vers les points de terminaison Bedrock AgentCore Runtime.
Combiner CloudFront, Amazon Route 53 et AWS Certificate Manager (ACM) pour configurer un domaine personnalisé sûr et évolutif fonctionnant avec des agents existants.
Avantages: intégration simplifiée, domaines personnalisés alignés sur l’organisation et une infrastructure plus propre qui facilite la maintenance lorsque les endpoints sont mis à jour. Il est possible de servir frontend et backend à partir du même domaine pour éviter les problèmes CORS.
La solution nécessite des certificats SSL dans la région us-east-1 (pour CloudFront) et l’implémentation se fait via AWS CDK. Elle suppose également l’utilisation de OAuth via Amazon Cognito et que l’ARN du runtime de l’agent soit disponible après le déploiement.
Cette approche est décrite dans l’article du AWS ML Blog, qui couvre aussi les tests, le nettoyage et les considérations pour une utilisation en production.

Contexte et aperçu

Bedrock AgentCore Runtime est présenté comme une solution d’hébergement indépendante du framework pour les agents IA. Il prend en charge les agents conçus avec LangGraph, CrewAI, Strands Agents ou des implémentations personnalisées, offre des temps d’exécution allant jusqu’à 8 heures, des microVMs isolées pour chaque session et un modèle de tarification basé sur la consommation. La plateforme inclut une authentification intégrée et une observabilité spécialisée pour les agents IA. Lorsqu’on utilise AgentCore Runtime avec Open Authorization (OAuth), les applications peuvent communiquer directement via HTTPS avec le point de terminaison du service. Bien que cette approche directe fonctionne, il est avantageux d’adopter un domaine personnalisé. En utilisant CloudFront comme proxy inverse, le trafic du domaine personnalisé est transformé en appels API Bedrock AgentCore Runtime, ce qui permet aux clients d’accéder à une URL conviviale comme https://agent.votreentreprise.com/ sans modifier la logique de l’application. En plus de CloudFront, la solution repose sur Route 53 pour la gestion DNS et sur ACM pour les certificats SSL/TLS. Les certificats SSL de CloudFront doivent résider dans la région us-east-1. L’article souligne également qu’une même distribution CloudFront peut servir à la fois le frontend et les endpoints backend, évitant les problèmes CORS puisque tout provient du même domaine. Le CDK AWS est utilisé pour l’implémentation du domaine personnalisé. Un stack complet est fourni dans l’article pour créer la distribution CloudFront qui proxy les requêtes du domaine personnalisé vers les endpoints Bedrock AgentCore Runtime. Si votre frontend est sur un domaine différent de celui de l’agent, vous devrez configurer les en-têtes CORS pour autoriser les appels inter-domaines. Si vous démarrez à partir de zéro, vous devrez obtenir l’ARN du runtime de l’agent après le déploiement, car il sera nécessaire pour la configuration du domaine personnalisé. L’article propose également un flux de tests utilisant un jeton JWT issu de Cognito et montre comment tester avec le domaine personnalisé et le domaine CloudFront.

Ce qui est nouveau

Cette approche documente l’utilisation de CloudFront comme proxy inverse afin d’exposer un endpoint de domaine personnalisé pour Bedrock AgentCore Runtime. Éléments clés :

Une distribution CloudFront configurée pour acheminer les requêtes de votre domaine personnalisé vers les appels d’API Bedrock AgentCore Runtime.
Une seule distribution capable de servir frontend et backend, réduisant la complexité des CORS.
Une implémentation basée sur AWS CDK qui regroupe CloudFront, Route 53, ACM et les autorisations nécessaires au proxy des requêtes vers les endpoints Bedrock AgentCore Runtime.
Des prérequis clairs, comme s’assurer que les certificats SSL soient dans us-east-1 et obtenir l’ARN du runtime après le déploiement.
Des instructions de test avec un JWT Cognito pour authentifier les requêtes et des exemples de test à la fois pour le domaine personnalisé et pour le domaine CloudFront.

Pourquoi cela compte (impact pour les développeurs/entreprises)

Intégration simplifiée: les équipes peuvent pointer leurs applications vers un domaine familier plutôt que vers l’endpoint Bedrock technique, accélérant les workflows de développement.
Alignement du domaine avec l’organisation: les domaines personnalisés soutiennent le branding et la cohérence entre applications et services.
Infrastructure plus propre: servir frontend et backend à partir d’un seul domaine réduit les problèmes de CORS.
Considérations de production: l’article met l’accent sur l’authentification, l’observabilité et la maintenabilité, tout en incitant à planifier le nettoyage des ressources pour contrôler les coûts.
Sécurité et évolutivité: la solution utilise un proxy inverse avec CloudFront, des certificats ACM, DNS Route 53 et les capacités d’authentification et d’observabilité intégrées du Bedrock AgentCore Runtime.

Détails techniques ou Mise en œuvre

L’article décrit une procédure pour configurer CloudFront comme proxy inversé pour Bedrock AgentCore Runtime. Points clés :

L’endpoint par défaut ressemble à https://bedrock-agentcore.`{région}`.amazonaws.com/runtimes/`{EncodedAgentARN}`/invocations. L’objectif est de présenter un domaine convivial tel que https://agent.votreentreprise.com.
Vous devez choisir parmi les options de domaine proposées et, si vous testez, commencer par une option préconfigurée avant de passer au domaine personnalisé complet.
Les certificats SSL du CloudFront doivent être dans us-east-1. C’est une exigence spécifique de CloudFront lorsqu’on utilise ACM.
Si votre frontend utilise un domaine différent de celui de l’agent, il faut configurer les en-têtes CORS pour autoriser les appels entre domaines.
Pour éviter le caching des réponses de l’agent, définissez la politique de caching du CloudFront sur CachePolicy.CACHING_DISABLED.
Le stack AWS CDK complet est fourni dans l’article pour orchestrer la distribution CloudFront, le Hosted Zone Route 53 (le cas échéant) et le certificat ACM, avec les permissions nécessaires pour proxy les appels vers les endpoints Bedrock AgentCore Runtime.
Après le déploiement, vous pouvez tester en utilisant le domaine personnalisé ou le domaine CloudFront. Les étapes de test incluent l’obtention d’un jeton JWT du Cognito et l’utilisation de ce jeton pour appeler l’endpoint de l’agent. Des exemples de code sont fournis pour tester avec le domaine personnalisé et avec le domaine CloudFront afin de valider les réponses.
Nettoyage: pour éviter des coûts continus, supprimez les ressources lorsque l’environnement n’est plus nécessaire (zones DNS Route 53, certificats ACM). Du point de vue sécurité et opérations, Bedrock AgentCore offre une authentification intégrée et une observabilité spécialisée pour les agents IA. L’intégration avec OAuth et Cognito facilite l’authentification via des jetons Cognito et assure que les requêtes passent par le proxy CloudFront. Bedrock AgentCore est encore en prévisualisation et peut évoluer. Les tarifs AWS standards s’appliquent aux services supplémentaires utilisés (CloudFront, Route 53, ACM).

Plan d’implémentation (haut niveau)

Identifier ou déployer un agent basé sur Bedrock AgentCore Runtime et capturer l’ARN du runtime après le déploiement.
Préparer un domaine personnalisé (p. ex. agent.votreentreprise.com) et configurer DNS/SSL dans us-east-1 via Route 53 et ACM.
Déployer une distribution CloudFront avec AWS CDK qui redirige les requêtes vers les endpoints Bedrock AgentCore Runtime, en appliquant une politique de cache pour le contenu dynamique.
Si frontend et backend utilisent des domaines différents, configurer CORS pour autoriser les appels inter-domaines selon les besoins.
Tester la configuration en obtenant un jeton JWT Cognito et en effectuant des appels tests vers les endpoints via le domaine personnalisé et via le domaine CloudFront.
Surveiller les aspects sécurité et observabilité et planifier le nettoyage lorsque l’environnement n’est plus nécessaire.

Points clés

Les domaines personnalisés simplifient l’intégration et renforcent le branding organisationnel.
CloudFront, Route 53 et ACM forment une pile sûre et scalable devant Bedrock AgentCore Runtime.
Une distribution CloudFront peut desservir frontend et backend, réduisant la complexité des CORS.
Utilisez le stack CDK fourni pour automatiser l’implémentation.
Préparez-vous pour la sécurité, la surveillance et la gestion des coûts, y compris le nettoyage des ressources après utilisation.