Déployer un RAG sur AWS avec Bedrock et Qdrant

Déployer un RAG sur AWS revient à choisir entre deux familles d'architecture. D'un côté, les services managés (Bedrock Knowledge Bases, avec OpenSearch Serverless ou S3 Vectors comme base vectorielle) qui réduisent l'exploitation au prix d'un coût plancher et de moins de contrôle fin. De l'autre, des briques assemblées (modèles servis via Bedrock ou hébergés séparément, Qdrant ou OpenSearch déployés sur ECS ou EKS) qui demandent plus d'ingénierie mais rendent la main sur le chunking, le reranking et la facture.

Le bon choix ne dépend pas de la technologie la plus citée sur les forums, mais de trois questions concrètes : ce que votre équipe sait déjà opérer, la sensibilité réelle des données traitées, et le volume attendu de documents et de requêtes. Un projet réel accompagné par Tensoria, pour un éditeur toulousain de logiciel médical, a tranché ces trois questions en optant pour Qdrant et des LLM hébergés dans des régions AWS européennes, avec à la clé une réduction de moitié des tickets support.

Cet article détaille les deux architectures, la région Paris et l'isolement des données par IAM, l'ingestion depuis S3, les coûts d'infrastructure réels et les cas où AWS n'est tout simplement pas le bon choix.

Bedrock Knowledge Bases ou architecture assemblée, les deux familles

Un RAG sur AWS se construit soit avec Bedrock Knowledge Bases, un service managé de bout en bout, soit avec des briques assemblées où chaque composant est choisi et opéré séparément. Le premier accélère la mise en route, le second donne le contrôle fin sur la qualité et sur la facture à l'échelle.

Ce que fait Bedrock Knowledge Bases à votre place

Bedrock Knowledge Bases prend en charge l'ingestion depuis S3, le découpage en chunks, l'appel au modèle d'embedding (Titan ou Cohere disponibles nativement) et l'indexation dans une base vectorielle, par défaut OpenSearch Serverless. Depuis décembre 2025, Amazon S3 Vectors est disponible en alternative et réduit fortement le coût de stockage vectoriel pour les nouveaux projets sans dépendance stricte à OpenSearch. Le service expose ensuite une API de récupération directement branchable sur un agent Bedrock.

L'avantage est la vitesse de mise en route : un premier index fonctionnel en quelques jours, sans écrire de pipeline d'ingestion, avec une intégration IAM native. La contrepartie est un contrôle plus limité sur la stratégie de chunking et sur le reranking, et un coût plancher qui pèse dès les faibles volumes.

Ce que permet une architecture assemblée avec Qdrant ou OpenSearch

Dans une architecture assemblée, vous déployez vous-même la base vectorielle, que ce soit Qdrant (auto-hébergé sur ECS ou EKS, ou via Qdrant Cloud disponible sur AWS Marketplace) ou un cluster OpenSearch classique. Le pipeline d'ingestion (Lambda, Step Functions ou un service sur ECS Fargate) et le choix des modèles (embeddings et génération via Bedrock, ou modèles ouverts self-hébergés sur SageMaker ou EC2 GPU) restent entièrement de votre ressort.

Cette approche a été retenue sur un projet réel pour un éditeur de logiciel médical : documentation et transcriptions vidéo indexées dans une base Qdrant hébergée en Europe, avec une recherche hybride combinant embeddings et BM25, fusionnée par Reciprocal Rank Fusion pour retrouver les termes techniques exacts du domaine médical, et des LLM hébergés dans des régions AWS européennes. Résultat mesuré : une réduction de 50 % des tickets support.

Région Paris, IAM et isolement des données

La région AWS de Paris (eu-west-3) garde le stockage et le traitement dans le périmètre européen pour les services qui le supportent, ce qui répond à une préférence de résidence des données et réduit la latence pour des utilisateurs en France. C'est un critère de choix fréquent pour un CTO qui doit répondre à un questionnaire de sécurité, mais ce n'est pas une garantie de souveraineté complète, un point détaillé plus loin.

Trois principes d'isolement structurent une architecture RAG sérieuse sur AWS :

• IAM à privilège minimal : la fonction d'ingestion n'a accès qu'au préfixe S3 concerné et à l'action d'écriture sur la base vectorielle, la fonction de récupération n'a que l'action de lecture, jamais les deux dans le même rôle.
• Chiffrement par clé KMS gérée par le client plutôt que la clé par défaut d'AWS, pour garder la capacité de révoquer l'accès aux données indépendamment d'AWS.
• Trafic interne via VPC endpoints (PrivateLink) entre les fonctions Lambda, la base vectorielle et Bedrock, pour ne jamais transiter par l'internet public.

Pour un RAG multi-tenant, l'isolement le plus léger applique un filtrage par métadonnées (identifiant de client) à l'intérieur d'un même index, ce qui suffit pour la majorité des cas. Une exigence réglementaire forte impose en revanche une séparation par compte AWS ou par VPC entier, avec des politiques de ressources qui interdisent toute récupération croisée entre clients.

Ingérer les documents depuis S3

Le pipeline d'ingestion démarre toujours par un bucket S3 structuré par source et, en contexte multi-tenant, par client. Deux chemins existent ensuite selon l'architecture retenue.

Avec Bedrock Knowledge Bases, un job de synchronisation natif (déclenché manuellement, planifié, ou sur événement S3) prend en charge l'extraction, le découpage et l'indexation. Avec une architecture assemblée, une règle EventBridge sur un événement S3 déclenche une fonction Lambda ou une Step Function : extraction du texte (Textract pour les PDF scannés, ou une bibliothèque d'extraction comme Unstructured pour les formats bureautiques), découpage en chunks, appel au modèle d'embedding via Bedrock Runtime, puis insertion dans Qdrant ou OpenSearch avec des métadonnées (identifiant de document, source, client, date de mise à jour).

Un piège fréquent en production : un document supprimé ou déplacé dans S3 n'est jamais automatiquement retiré de l'index vectoriel. Sans un mécanisme explicite de nettoyage basé sur les métadonnées, la base vectorielle continue de renvoyer des réponses sur des documents qui n'existent plus, un cas typique de dérive documentée dans notre article sur les erreurs qui font échouer un projet RAG.

Combien coûte un RAG sur AWS en infrastructure

Les coûts d'infrastructure varient fortement selon l'architecture retenue, avant même de compter le coût des modèles. Le tableau suivant donne des ordres de grandeur à vérifier sur les pages tarifaires officielles au moment du devis, les grilles AWS évoluant régulièrement.

Ces chiffres proviennent d'analyses de tarification 2026 relayées par des acteurs spécialisés du cloud et de la base de données vectorielle, à recouper avec les pages officielles Amazon Bedrock, Amazon OpenSearch Service et Qdrant Cloud avant tout engagement. Pour une vision complète du budget d'un projet RAG, développement compris, notre article sur le coût d'un projet RAG en entreprise détaille les postes au-delà de la seule infrastructure.

Observabilité et un cas réel déjà en production sur AWS

Le suivi infrastructure (latence, taux d'erreur, coût par requête via CloudWatch, logs d'invocation des modèles Bedrock) répond à une question opérationnelle : le système tient-il la charge et le budget ? Il ne répond pas à une question de qualité : le système répond-il correctement ? Cette seconde mesure demande une baseline d'évaluation distincte, réévaluée après chaque changement de modèle, de prompt ou de corpus.

Le projet mené pour l'éditeur de logiciel médical illustre ce qu'une architecture assemblée sur AWS permet de tenir en pratique : une base Qdrant hébergée en Europe pour la documentation et les transcriptions vidéo, une recherche hybride BM25 et vectorielle pour capturer aussi bien l'intention que les termes techniques précis, des LLM hébergés dans des régions AWS européennes (Francfort, Paris) pour respecter les exigences du secteur, et un résultat mesuré de 50 % de tickets support en moins après déploiement.

Quand AWS est le bon choix, et quand ne pas s'y engager

AWS est le bon choix dans trois situations fréquentes. D'abord quand vous y êtes déjà : le reste du système d'information tourne sur AWS, l'équipe DevOps connaît IAM, VPC et ECS, et intégrer le RAG à des services déjà en place (Step Functions, SageMaker, QuickSight) fait gagner du temps plutôt qu'en perdre. Ensuite quand les volumes sont variables et que l'élasticité du cloud managé paie réellement. Enfin quand la donnée n'est pas soumise à une contrainte de souveraineté forte, la région Paris suffisant à répondre à une préférence de résidence des données.

AWS n'est en revanche pas le bon point de départ dans trois cas. Si l'équipe n'a aucune compétence cloud interne, un accompagnement ou une offre plus encadrée ira plus vite. Si les données relèvent d'un secret professionnel strict ou d'une exigence réglementaire de type SecNumCloud, la nuance suivante compte : la région Paris garde les données dans l'UE, mais AWS reste une entité de droit américain soumise au CLOUD Act. Ce mécanisme n'est pas propre à Microsoft, mais documenté publiquement pour tout éditeur américain, y compris lors d'une audition au Sénat le 10 juin 2025 où un dirigeant de Microsoft France a reconnu ne pas pouvoir garantir qu'une donnée hébergée en France échapperait à une réquisition américaine. Pour ces cas, une architecture hébergée en France sur une infrastructure qualifiée IA souveraine, avec un modèle comme Mistral, lève ce risque résiduel, une approche détaillée dans notre article sur le RAG souverain avec Mistral.

Enfin, le choix entre Bedrock Knowledge Bases et une architecture assemblée n'est pas figé au démarrage. Une équipe qui commence en managé pour valider l'usage peut migrer vers Qdrant ou OpenSearch autogéré quand le volume ou le besoin de recherche hybride le justifie, à condition d'avoir conçu son pipeline d'ingestion (métadonnées, découpage) de façon à ne pas tout réécrire au changement de base vectorielle.

C'est ce diagnostic (architecture managée ou assemblée, région, isolement, budget réel) que nous posons avant tout développement RAG sur mesure sur AWS, sur devis, avec un périmètre et des livrables définis en amont selon vos données et vos contraintes.

Questions fréquentes

Articles recommandés

• Guide du RAG en entreprise : les fondamentaux du Retrieval-Augmented Generation avant d'aborder son déploiement sur un cloud précis.
• Coût d'un projet RAG en entreprise : les postes de coût au-delà de la seule infrastructure, du POC à la production.
• Top bases de données vectorielles pour le RAG : Qdrant face à Chroma, Weaviate, pgvector, FAISS, Milvus et Pinecone.
• RAG souverain avec Mistral : l'architecture à privilégier quand la souveraineté n'est pas négociable.
• 5 erreurs qui font échouer un projet RAG : les pièges à éviter, dont l'absence de suivi après déploiement.
• Baseline d'évaluation RAG : mesurer la qualité d'un RAG avant et après chaque changement d'infrastructure.