Aller au contenu principal
InfrastructureAWS ML Blog3h· 2 min de lecture

« Mise en œuvre de patterns de résilience avec Amazon Bedrock et une passerelle LLM »

Source originale ↗·

Amazon Web Services a publié un article technique détaillant cinq patterns de résilience pour les déploiements d'inférence de grands modèles de langage (LLM) sur Amazon Bedrock, conçus pour accompagner les charges de travail d'IA générative qui passent de la phase expérimentale à la production à grande échelle. Le premier de ces patterns repose sur l'inférence cross-Region (CRIS) d'Amazon Bedrock, une fonctionnalité native qui redirige automatiquement les requêtes depuis une région source vers la région de destination optimale, en tenant compte en temps réel de la disponibilité, de la latence et de la demande. Les patterns suivants montent en complexité jusqu'à une orchestration multi-modèles via une passerelle LLM (LLM gateway), permettant de combiner plusieurs fournisseurs et modèles selon les besoins. Un dépôt GitHub accompagne l'article avec des exemples de code pour chaque pattern, afin que les développeurs puissent les tester directement dans leur propre environnement AWS.

Cette approche progressive répond à des problèmes concrets rencontrés par les équipes qui exploitent des applications IA en production: l'épuisement soudain des quotas lors de pics de trafic imprévus, les effets de "voisin bruyant" dans les environnements multi-tenants, ou encore le besoin de répartir géographiquement l'inférence pour maximiser la disponibilité. Au-delà de la simple continuité de service, ces patterns ouvrent aussi la voie à une optimisation des coûts grâce à un routage intelligent des requêtes, et donnent aux équipes la liberté de basculer entre plusieurs modèles ou fournisseurs selon les contraintes de performance ou de budget. Pour des entreprises qui dépendent désormais de l'IA générative dans leurs produits, ces garanties de résilience deviennent aussi critiques que celles déjà appliquées aux architectures cloud traditionnelles.

AWS rappelle que les bonnes pratiques classiques de résilience, comme la stabilité statique ou les mécanismes de backoff et de nouvelles tentatives, restent valables, mais que l'IA générative introduit des contraintes inédites: disponibilité fluctuante des modèles, quotas qui évoluent rapidement, limites de tokens variables selon les fournisseurs, et nécessité de maintenir une cohérence de comportement face aux nouvelles versions de modèles publiées régulièrement. L'article structure sa réflexion autour de quatre dimensions clés, la disponibilité, le temps de réponse, le coût et le débit, en précisant que ce premier volet se concentre sur la disponibilité via le basculement, la répartition géographique et l'isolation des quotas. AWS annonce que de prochains articles approfondiront l'optimisation du temps de réponse et le routage sensible aux coûts, signe que la firme entend documenter une stratégie complète de résilience pour les architectures d'inférence LLM en production.

Dans nos dossiers

Cet article vous a été utile ?

Vu une erreur factuelle dans cet article ? Signalez-la. Toutes les corrections valides sont publiées sur /corrections.

À lire aussi

Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore
1AWS ML Blog 

Sécuriser les agents IA avec des intercepteurs Policy et Lambda dans la passerelle Amazon Bedrock AgentCore

Amazon a enrichi son service Bedrock AgentCore Gateway de deux mécanismes de sécurité complémentaires destinés à contrôler le comportement des agents IA en entreprise. Le premier, appelé Policy, permet de définir des règles d'accès aux outils à l'aide de Cedar, un langage déclaratif d'Amazon qui évalue chaque requête selon un principal, une action et une ressource, puis délivre une décision déterministe d'autorisation ou de refus, automatiquement journalisée. Le second mécanisme, les intercepteurs Lambda, permet d'exécuter du code personnalisé avant ou après chaque appel d'outil, pour effectuer de la validation dynamique, de l'enrichissement de payload, des échanges de tokens ou du filtrage de réponses. Pour illustrer ces capacités, Amazon présente un agent de données baptisé "lakehouse data agent", conçu pour une compagnie d'assurance fictive. Cet agent permet à trois types d'utilisateurs, titulaires de contrats, experts en sinistres et administrateurs, d'interroger des données de réclamations stockées dans Amazon S3 Tables au format Apache Iceberg, via Amazon Athena et AWS Lake Formation. L'interface Streamlit authentifie les utilisateurs via Amazon Cognito et transmet des JWT à l'agent, qui expose cinq outils MCP distincts. Les métadonnées de rôles, les mappings IAM par tenant et la géographie des utilisateurs sont stockés dans Amazon DynamoDB. Ces nouvelles fonctionnalités répondent à un problème de gouvernance concret que rencontrent les grandes organisations déployant des agents IA à l'échelle. Contrairement aux applications traditionnelles qui exécutent une logique fixe, les agents pilotés par un LLM décident au moment de l'exécution quels outils invoquer, avec quels arguments et dans quel ordre. Il devient donc impossible d'auditer le graphe d'appels à l'avance. Sur des plateformes unifiées comptant des centaines d'agents et des milliers d'outils MCP répartis entre différentes équipes et unités métier, ce manque de contrôle crée un risque réel. La combinaison Cedar pour l'autorisation déterministe et Lambda pour la validation contextuelle dynamique, notamment basée sur la géographie de l'utilisateur, offre une architecture de sécurité en couches adaptée à cette réalité. Ce développement s'inscrit dans un mouvement plus large d'industrialisation de l'IA agentique au sein des entreprises, où les questions de sécurité et de conformité deviennent aussi critiques que la performance des modèles eux-mêmes. Le Model Context Protocol, promu initialement par Anthropic, s'impose progressivement comme standard d'interopérabilité entre agents et outils, et AWS prend position en intégrant nativement la gouvernance des outils MCP dans Bedrock. Lake Formation assure par ailleurs une sécurité au niveau des lignes et des colonnes directement à l'exécution des requêtes, garantissant que même un agent mal configuré ne puisse pas exfiltrer de données hors de son périmètre autorisé. La prochaine étape probable pour Amazon sera d'étendre ces mécanismes à des scénarios multi-agents, où la chaîne de confiance entre agents orchestrateurs et agents subalternes soulève des défis de sécurité encore plus complexes.

InfrastructureActu
1 source
Amazon Bedrock lance l'inférence d'IA générative en Asie-Pacifique (Nouvelle-Zélande)
2AWS ML Blog 

Amazon Bedrock lance l'inférence d'IA générative en Asie-Pacifique (Nouvelle-Zélande)

Amazon Web Services vient d'ouvrir l'accès à Amazon Bedrock depuis la région Asie-Pacifique (Nouvelle-Zélande), identifiée sous le code ap-southeast-6 et basée à Auckland. Les clients néo-zélandais peuvent désormais appeler directement les modèles d'Anthropic — Claude Opus 4.5 et 4.6, Sonnet 4.5 et 4.6, et Haiku 4.5 — ainsi que les modèles Amazon Nova 2 Lite, sans passer par une région étrangère. Le mécanisme repose sur l'inférence cross-région : lorsqu'une requête est émise depuis Auckland, Amazon Bedrock la distribue dynamiquement vers une ou plusieurs régions de destination — Auckland elle-même, Sydney (ap-southeast-2) ou Melbourne (ap-southeast-4) — en fonction de la charge et de la disponibilité. Toutes les données transitent exclusivement sur le réseau privé AWS, chiffrées en transit, sans jamais passer par l'internet public. Les appels sont enregistrés dans AWS CloudTrail depuis la région source, et les logs d'invocation peuvent être dirigés vers CloudWatch ou S3 dans la même région. Cette disponibilité régionale répond à une demande concrète des entreprises néo-zélandaises soumises à des exigences de résidence des données. Le profil géographique « AU » permet désormais de garantir que les traitements d'inférence restent dans le périmètre Australie–Nouvelle-Zélande, ce qui est décisif pour des secteurs comme la santé, la finance ou les services publics, où la localisation des données est une contrainte légale ou réglementaire. En parallèle, les organisations sans contrainte de résidence peuvent opter pour le profil global, qui route vers n'importe quelle région commerciale AWS dans le monde pour maximiser le débit disponible. Ce double choix de routage offre une flexibilité opérationnelle rare sur le marché du cloud. Amazon Bedrock s'étend ainsi progressivement dans la zone Pacifique, une région stratégique pour AWS face à la concurrence de Google Cloud et Microsoft Azure, qui ont également multiplié leurs ouvertures de datacenters locaux ces dernières années. La Nouvelle-Zélande, bien que marché de taille modeste, représente un point d'ancrage important pour les entreprises multinationales opérant dans la région ANZ. L'intégration d'Auckland dans le profil cross-région AU — sans modifier les comportements existants de Sydney et Melbourne — illustre une approche incrémentale conçue pour ne pas perturber les architectures déjà en production. La prochaine étape probable sera l'élargissement du catalogue de modèles accessibles depuis cette nouvelle région source, au fur et à mesure que les capacités d'inférence locales monteront en charge.

InfrastructureActu
1 source
Ampersend crée un modèle de paiement à l'usage pour agents IA avec Amazon Bedrock AgentCore Payments
3AWS ML Blog 

Ampersend crée un modèle de paiement à l'usage pour agents IA avec Amazon Bedrock AgentCore Payments

Ampersend, une plateforme de gestion des paiements pour agents IA développée par Edge & Node, a annoncé la mise en production d'une couche de routage pay-per-intelligence construite sur Amazon Bedrock AgentCore Payments. Le système permet à des agents autonomes de sélectionner dynamiquement un modèle de langage adapté à leur tâche, résumé de document, audit de smart contract, analyse de données on-chain, puis de régler la prestation par requête, sans intervention humaine, en s'appuyant sur le protocole ouvert x402. L'infrastructure repose sur un mécanisme en deux sauts : l'agent appelle Ampersend, qui règle ensuite le fournisseur de modèle en aval via son propre SDK. Le tout se pilote depuis un point d'intégration unique, sans abonnement distinct par fournisseur. Jusqu'ici, connecter un agent IA à des services payants réclamait des mois de travail préalable : gestion de portefeuilles cryptographiques, signature des paiements, respect des limites de dépenses, intégration avec la facturation de chaque fournisseur. Ce fardeau infrastructure freinait considérablement le déploiement d'agents en production. AgentCore Payments supprime ce prérequis en offrant une couche de gouvernance clé en main : un Payment Manager définit les règles de dépense et les connexions aux portefeuilles, tandis qu'une Payment Session ouvre un contexte d'exécution borné avant chaque run d'agent. Résultat concret pour les développeurs : ils écrivent la logique métier de l'agent sans s'occuper de la plomberie financière. Pour des plateformes comme Ampersend, c'est la possibilité d'agréger des dizaines de fournisseurs de modèles derrière une interface de paiement unique, sécurisée et auditée nativement. Ce lancement s'inscrit dans une tendance plus large : l'émergence d'une économie machine-to-machine où les agents IA deviennent des acteurs économiques à part entière, capables de consommer des APIs payantes de façon autonome. Le protocole x402, sur lequel repose l'architecture, est conçu pour des transactions programmatiques instantanées, à l'image de ce qu'HTTP fait pour les échanges de données. Amazon, avec Bedrock AgentCore, consolide sa position d'infrastructure sous-jacente pour les stacks agentiques d'entreprise, aux côtés de ses outils d'orchestration existants. Ampersend, de son côté, parie que la fragmentation du marché des modèles, OpenAI, Anthropic, modèles open source, spécialistes verticaux, rendra indispensable ce type de couche d'abstraction de paiement. Les prochaines étapes probables incluent l'extension du catalogue de modèles, des politiques de dépense plus granulaires, et l'intégration avec d'autres protocoles de paiement agentic émergents.

InfrastructureActu
1 source
4AWS ML Blog 

Amazon Bedrock propose désormais une attribution détaillée des coûts

Amazon Web Services vient d'annoncer une nouvelle fonctionnalité d'attribution granulaire des coûts pour Amazon Bedrock, son service d'inférence d'IA en cloud. Désormais, Bedrock attribue automatiquement chaque dépense d'inférence à l'identité IAM (Identity and Access Management) qui a effectué l'appel, qu'il s'agisse d'un utilisateur IAM classique, d'un rôle assumé par une application Lambda, ou d'une identité fédérée via un fournisseur comme Okta ou Microsoft Entra ID. Ces données apparaissent directement dans AWS Cost and Usage Reports (CUR 2.0) sans aucune ressource supplémentaire à gérer ni modification des workflows existants. Concrètement, un rapport peut montrer qu'Alice a dépensé 0,069 dollar en tokens d'entrée et 0,214 dollar en tokens de sortie avec Claude Sonnet 4.6, pendant que Bob a consommé 1,188 dollar au total avec Claude Opus 4.6, avec une précision à l'identité près. Il est également possible d'ajouter des tags de coût sur les identités IAM pour regrouper les dépenses par équipe, projet ou centre de coût dans AWS Cost Explorer. Cette visibilité fine répond à un besoin croissant des entreprises qui voient l'inférence IA représenter une part de plus en plus significative de leur facture cloud. Sans attribution précise, il est impossible de refacturer correctement les équipes internes, d'identifier les usages inefficaces ou de planifier les budgets. Grâce à cette fonctionnalité, un DSI peut désormais savoir exactement quelle équipe produit, quel service applicatif ou quel développeur génère quels coûts LLM, sans déployer d'infrastructure de monitoring supplémentaire. Pour les organisations qui font transiter leurs appels via une passerelle LLM centralisée, AWS recommande d'utiliser AssumeRole avec des tags de session dynamiques afin de préserver la granularité par utilisateur final, même derrière un proxy unique. Cette annonce s'inscrit dans une tendance de fond : les grands fournisseurs de cloud cherchent à rendre l'IA générative compatible avec les pratiques de gouvernance financière des entreprises. Amazon Bedrock, qui donne accès à des modèles de plusieurs éditeurs dont Anthropic, Mistral et Meta, doit convaincre les directions financières que la dépense IA est traçable et contrôlable. La concurrence avec Azure AI et Google Vertex AI pousse AWS à muscler ses outils de FinOps autour de l'IA. À mesure que les modèles comme Claude Opus deviennent plus coûteux à l'usage, la capacité à attribuer précisément chaque dollar dépensé devient un argument de vente central pour les déploiements en entreprise, où la responsabilisation budgétaire par équipe est souvent non négociable.

UELes entreprises européennes utilisant Amazon Bedrock peuvent désormais attribuer précisément leurs dépenses d'inférence IA par équipe ou projet, facilitant la gouvernance financière et la refacturation interne sans infrastructure supplémentaire.

InfrastructureActu
1 source

Recevez l'essentiel de l'IA chaque jour

Une sélection éditoriale quotidienne, sans bruit. Directement dans votre boîte mail.

Recevez l'essentiel de l'IA chaque jour

Gratuit · 1 email le matin, l'essentiel de l'IA · désinscription en un clic