AWS a expliqué comment déployer des agents vocaux AI Pipecat dans Bedrock AgentCore Runtime

AWS a lancé la première partie d'un guide pratique sur la façon de déployer des agents de voix Pipecat dans Amazon Bedrock AgentCore Runtime. L'accent ne porte pas sur les modèles eux-mêmes, mais sur la couche de transport, qui détermine si la conversation sonnera naturelle ou si l'utilisateur connaîtra des pauses et des retards.

Pourquoi la latence est importante

Un agent de voix fonctionne presque toujours dans des conditions difficiles : navigateur, application mobile ou appel téléphonique, réseau instable, pics de charge et attente de réponse en temps réel. AWS souligne que pour un dialogue naturel, la latence doit rester quasi imperceptible — généralement dans une seconde de la fin de la déclaration de l'utilisateur au début de la réponse de l'agent. Sinon, la conversation s'effondre : l'interlocuteur interrompt l'agent, pense qu'il s'est figé ou s'en va simplement. C'est particulièrement critique pour le support, les assistants virtuels et les campagnes sortantes.

Pour atténuer ce risque, AWS suggère d'exécuter des agents Pipecat dans Bedrock AgentCore Runtime — un environnement serverless sécurisé pour les agents IA. Chaque session s'exécute dans une microVM isolée, la plateforme se met à l'échelle automatiquement pour les pics de trafic et peut maintenir des conversations continues pendant jusqu'à huit heures. C'est important pour les appels longs et multi-étapes où vous ne pouvez pas simplement couper le contexte. Un autre avantage est de payer uniquement les ressources réellement consommées, sans avoir à maintenir des réserves de serveur pour la charge maximale.

Pipecat lui-même peut être empaqueté dans un conteneur et déployé avec un surcoût minimal si l'image est compilée pour ARM64.

Quelles options existent

Dans la première partie, AWS examine le chemin du client à l'agent — ce "premier saut" qui affecte le plus fortement la perception de la vitesse. L'entreprise compare quatre approches : WebSockets ordinaires, WebRTC avec relais TURN, WebRTC géré via des fournisseurs spécialisés, et téléphonie pour travailler avec PSTN et les centres de contact. Chaque option a son propre équilibre entre simplicité, fiabilité et qualité de connexion.

L'idée est simple : il n'existe pas un seul meilleur transport pour tous les scénarios, mais il existe des cas d'usage clairs où chacun semble un point de départ raisonnable.

• WebSockets — l'option la plus simple pour les prototypes et les scénarios légers dans les applications web et mobiles.
• WebRTC avec TURN — le meilleur choix si vous avez besoin d'une latence plus faible et d'une résilience sur les mauvais réseaux.
• WebRTC géré — le chemin vers la production quand vous voulez confier le réseau de médias global, l'analyse et l'infrastructure de relais à un service externe.
• Téléphonie — une option pour les appels, le remplacement de IVR, les campagnes sortantes et l'intégration avec les centres de contact.

Pour WebSockets, AWS montre une approche maximalement directe. Le client demande d'abord une adresse signée à un serveur intermédiaire ; ce serveur génère une URL pré-signée avec signature SigV4 via AWS SDK ; puis le navigateur se connecte directement à l'agent à l'adresse /ws. Cela garde les identifiants hors du côté client, et le trafic lui-même après établissement de la connexion s'écoule sans intermédiaire inutile. AWS l'appelle un bon point de départ : c'est plus simple que les alternatives, nativement supporté par la plupart des clients, et approprié pour valider rapidement un produit.

Ce qu'il faut considérer en production

Si l'objectif n'est pas une démo mais une interface conversationnelle stable, AWS recommande de regarder vers WebRTC. Ce transport fonctionne généralement sur UDP, gère mieux les conditions de réseau fluctuantes et livre l'audio plus rapidement dans les deux sens. Mais AgentCore a des nuances architecturales.

Une connexion peer-to-peer directe ne fonctionne pas ici car l'environnement runtime ne reçoit pas d'IP publique. Le scénario STUN ne fonctionne pas non plus comme le chemin principal : AWS note que NAT Gateway utilise NAT symétrique, ce qui brise le perçage direct de connexion. Par conséquent, la recommandation pratique est le relais TURN et la configuration VPC pour le runtime.

Dans le schéma de fonctionnement, vous devez configurer la variable ICE_SERVER_URLS à la fois sur le serveur intermédiaire et dans l'environnement de l'agent, puis placer AgentCore Runtime dans un sous-réseau privé VPC et lui donner l'accès sortant via NAT Gateway.

En tant qu'option AWS native pour TURN, l'entreprise propose Amazon Kinesis Video Streams : le service fournit des identifiants ICE temporaires et automatiquement renouvelés via l'API GetIceServerConfig. Cela élimine les dépendances externes, mais il y a des limitations : un canal de signalisation actif coûte 0,03 $ par mois, la limite est de 5 TPS par canal, ce qui signifie à volumes élevés de nouvelles sessions vous devrez distribuer la charge sur plusieurs canaux. De plus, vous avez toujours besoin d'un accès Internet pour atteindre KVS.

AWS mentionne également séparément les fournisseurs WebRTC gérés du AWS Marketplace. Cette option est utile si en plus du transport vous avez besoin de nœuds SFU/TURN distribués mondialement, d'une observabilité intégrée et du support de salles multi-utilisateurs, pas seulement du dialogue un-à-un.

Pour les scénarios de téléphonie, la logique est similaire : l'agent continue à maintenir un flux audio bidirectionnel constant mais se connecte au fournisseur de télécommunications via SIP, WebSocket ou WebRTC. Pipecat fournit déjà des transports et des sérialiseurs prêts à l'emploi, donc la tâche se réduit non pas à construire une pile de voix à partir de zéro mais à choisir le bon canal.

Ce que cela signifie

AWS montre effectivement que le goulot d'étranglement chez les agents IA vocaux s'est depuis longtemps déplacé du modèle à l'infrastructure de livraison audio. Pour les équipes, c'est une orientation utile : vous pouvez commencer par WebSockets, mais pour la production sérieuse, vous devrez presque inévitablement choisir entre WebRTC, les réseaux de médias gérés et la téléphonie — selon exactement où l'utilisateur parle à l'agent.