Connecter AWS Bedrock à n8n : credentials, modèles Claude et RAG

Pour une équipe déjà installée sur AWS — infrastructure, budget engagé, gouvernance IAM en place — faire transiter les appels IA par Amazon Bedrock plutôt que par une clé API Anthropic ou OpenAI isolée change la donne : un seul contrat, une seule facture, les mêmes règles de sécurité que le reste de l'infrastructure. Bedrock donne accès à Claude, à la famille Titan d'Amazon, à Llama et à Mistral derrière une API unique, hébergée dans la région AWS de votre choix. n8n intègre Bedrock nativement via un sub-node LangChain dédié. La partie qui surprend le plus au premier essai : l'authentification passe par un credential AWS complet (clé, rôle à endosser, région), et chaque modèle doit être explicitement autorisé avant de pouvoir être appelé. Ce guide détaille les deux, du portail AWS au premier agent IA dans n8n.

Pourquoi Bedrock plutôt qu'une clé API directe

Si vos workflows utilisent déjà Claude ou GPT via les nodes standards (voir notre guide Claude/GPT dans n8n), Bedrock répond à des besoins spécifiquement liés à l'infrastructure AWS existante :

• Facturation et engagement unifiés. La consommation de tokens s'ajoute à votre facture AWS et compte dans un éventuel engagement de dépense (Savings Plan, EDP) déjà négocié — pas de carte bancaire séparée pour chaque fournisseur de modèle.
• IAM plutôt que des clés API en clair. L'accès se gouverne avec les mêmes rôles, politiques et journaux CloudTrail que le reste de votre infrastructure AWS, y compris l'accès temporaire par rôle assumé (assume role) plutôt qu'une clé statique à faire tourner.
• Résidence des données par région. Une requête envoyée à Bedrock depuis une région AWS reste traitée dans cette région ; aucune donnée n'est utilisée pour ré-entraîner les modèles sous-jacents, un point souvent exigé par le juridique.
• Un seul point d'accès pour plusieurs familles de modèles. Basculer de Claude à Titan ou à Llama pour un cas d'usage donné ne change ni le contrat, ni le credential, ni la facturation — seulement le champ modèle du node.

Cette logique de facturation à l'usage, sans capacité à réserver à l'avance, est justement le point que confirme une étude qualitative de Muhammad Hamza, Muhammad Azeem Akbar et Rafael Capilla (« Understanding Cost Dynamics of Serverless Computing: An Empirical Study », 2024 — voir sur Google Scholar), menée auprès de 15 experts de 8 entreprises ayant migré vers des architectures serverless : les équipes gagnent en flexibilité budgétaire (paiement strictement à la consommation) mais doivent activement surveiller les coûts variables, faute de quoi la facture peut dériver plus vite qu'avec une infrastructure réservée. Un rappel utile pour Bedrock, facturé exactement sur ce modèle.

Étape 1 : activer l'accès aux modèles dans la console Bedrock

Contrairement à OpenAI ou Anthropic en direct, un compte AWS n'a accès à aucun modèle Bedrock par défaut : chaque modèle doit être explicitement débloqué.

1. Dans la console AWS, ouvrez Amazon Bedrock → Model access.
2. Cliquez sur Modify model access, cochez les modèles souhaités (par exemple Claude d'Anthropic, ou un modèle Titan d'Amazon) et validez. Certains modèles tiers approuvent l'accès instantanément, d'autres demandent une justification d'usage.
3. Vérifiez que l'activation a bien été faite dans la région que vous comptez utiliser dans n8n : l'accès aux modèles se gère région par région, et un modèle activé à Paris ne l'est pas automatiquement à Francfort.

Sans cette étape, tout appel depuis n8n échoue avec une erreur d'accès refusé, même credential et permissions IAM correctement configurés par ailleurs.

Étape 2 : le credential AWS dans n8n

Dans n8n, Credentials → Add credential → AWS. Deux façons de vous authentifier :

• Access Key ID / Secret Access Key : le mode le plus direct, avec une clé IAM classique dédiée à n8n. Ajoutez la Region (celle où vous avez activé les modèles à l'étape précédente).
• Assume Role, pour un accès temporaire multi-comptes : un utilisateur ou rôle IAM avec la permission d'endosser un rôle cible fournit un STS Access Key ID / Secret Access Key, le Role ARN du rôle cible (format arn:aws:iam::123456789012:role/MonRole), et éventuellement un External ID pour éviter le problème du « confused deputy ». Un Session token optionnel complète le tableau pour des identifiants temporaires.

Sur le node AWS Bedrock Chat Model, deux champs d'endpoint apparaissent en plus : Bedrock Endpoint (utilisé pour lister les modèles disponibles) et Bedrock Runtime Endpoint (utilisé pour l'inférence proprement dite). Laissez-les vides en usage standard ; ne les renseignez que si le trafic Bedrock passe par un point de terminaison d'interface VPC (PrivateLink) sans DNS privé.

Comme pour tout credential IA, appliquez le principe du moindre privilège : une politique IAM scopée aux ARN des modèles réellement utilisés, jamais un accès Bedrock complet par confort. Notre guide sur la sécurisation des credentials API dans n8n détaille la rotation et la séparation par environnement, directement applicables ici.

Étape 3 : le node AWS Bedrock Chat Model

Comme son équivalent Anthropic ou Azure OpenAI, c'est un sub-node LangChain : il ne s'exécute pas seul, il se branche comme modèle de langage sur un node parent.

Chat Trigger ──▶ AI Agent ──▶ Réponse
                   │
                   ├── AWS Bedrock Chat Model  (credential AWS)
                   │     Model : anthropic.claude-3-5-sonnet-...
                   └── Outils (HTTP Request, Vector Store…)

1. Ajoutez un AI Agent (ou une Basic LLM Chain pour un appel simple sans outils) — voir notre guide complet du node AI Agent pour la mécanique générale.
2. Attachez un AWS Bedrock Chat Model avec votre credential AWS.
3. Sélectionnez le modèle dans la liste, ou saisissez son identifiant Bedrock directement (format fournisseur.nom-du-modèle-version).
4. Réglez Maximum Number of Tokens, Sampling Temperature et Top P comme sur les autres nodes de chat model n8n.

Un piège fréquent avec les modèles Claude les plus récents : l'ID de modèle brut renvoie une erreur « On-demand throughput isn't supported », car ces modèles exigent un profil d'inférence plutôt qu'un accès direct à la demande. La solution consiste à passer le champ Model en mode Expression et à saisir l'ID du profil d'inférence propre à votre région (généralement préfixé par un code de région) plutôt que l'ID de modèle nu.

Embeddings AWS Bedrock pour le RAG

Le node Embeddings AWS Bedrock utilise le même credential et génère des vecteurs — via Titan Embeddings ou un autre modèle d'embeddings disponible sur Bedrock — à brancher sur les nodes de vector store de n8n, exactement comme les embeddings OpenAI ou Azure. C'est le composant clé pour un pipeline RAG entièrement hébergé sous contrat AWS : ingestion documentaire, indexation vectorielle et génération de réponses passent tous par le même point d'accès et la même facturation. Notre guide RAG avec Supabase pgvector reste valable tel quel côté stockage vectoriel ; seul le node d'embeddings change. C'est exactement l'architecture que couvre le Pack Assistant RAG, adaptable à Bedrock en remplaçant simplement le sub-node d'embeddings et de chat model.

Erreurs courantes et leur diagnostic

• AccessDeniedException : le modèle n'est pas activé dans Model access pour la région configurée, ou la politique IAM associée au credential ne porte pas bedrock:InvokeModel (et bedrock:InvokeModelWithResponseStream pour le streaming) sur l'ARN du modèle appelé. Vérifiez les deux dans la même région.
• ValidationException — on-demand throughput isn't supported : utilisez l'ID de profil d'inférence plutôt que l'ID de modèle brut, en mode Expression sur le champ Model.
• Modèle absent de la liste dans n8n : le credential pointe vers une région où le modèle n'est tout simplement pas proposé par AWS ; changez de région dans le credential ou choisissez un modèle disponible localement.
• 429 / limitation de débit : Bedrock applique des quotas de débit par modèle et par compte, ajustables sur demande dans la console Service Quotas. Les mêmes patterns n8n s'appliquent que pour tout autre fournisseur — notre guide sur les rate limits des API d'IA détaille Loop Over Items, Wait et le respect du header de nouvel essai.

Bonnes pratiques en production

• IAM scopé par usage. Un rôle ou une politique par cas d'usage (agent support, extraction de documents, RAG interne) plutôt qu'un accès Bedrock large : un incident sur un workflow ne compromet pas les autres.
• Tag et suivi des coûts. AWS Cost Explorer permet de tagger les appels Bedrock par projet ; combinez-le avec un suivi côté n8n pour attribuer précisément le coût à chaque workflow, comme décrit dans notre méthode de suivi du coût des appels IA.
• Un plan de repli. Un incident régional ou un quota saturé sur un modèle Bedrock reste possible ; le pattern de fallback multi-fournisseurs fonctionne aussi bien entre deux modèles Bedrock qu'entre Bedrock et un fournisseur externe — un filet particulièrement pertinent pour les pipelines de conformité et d'audit du Pack Conformité & Audit, où une interruption silencieuse n'est jamais une option.
• Assume Role plutôt que clés statiques dès que plusieurs comptes AWS ou environnements (dev/prod) sont en jeu : la rotation devient automatique et rien de sensible ne dort dans n8n au-delà de la durée de la session.

En résumé

• AWS Bedrock donne accès à Claude, Titan, Llama et Mistral sous un seul contrat AWS, avec gouvernance IAM et résidence des données par région.
• Chaque modèle doit être explicitement activé dans Model access (console Bedrock), région par région, avant tout appel depuis n8n.
• Le credential AWS de n8n accepte une clé classique ou un Assume Role (Role ARN, External ID, Session token) pour un accès temporaire multi-comptes.
• Le node AWS Bedrock Chat Model se branche sur un AI Agent ou une Basic LLM Chain ; les modèles Claude récents demandent souvent un profil d'inférence plutôt qu'un ID de modèle brut.
• Le node Embeddings AWS Bedrock couvre le RAG avec le même credential, pour un pipeline entièrement hébergé sous contrat AWS.