TL;DR

Si vous utilisez une Amazon Bedrock Knowledge Base adossee a OpenSearch Serverless (AOSS), vous payez un plancher d'environ 700$/mois avant meme d'ingester un seul document. Pour la plupart des workloads RAG de petite et moyenne taille, remplacer AOSS par Aurora PostgreSQL Serverless v2 avec l'extension pgvector fait tomber ce plancher a moins de 50$/mois, soit une reduction de cout d'environ 90% ; tout en restant un vector store pleinement supporte et de premier ordre pour Bedrock Knowledge Bases.

Ce post detaille le pourquoi, le calcul, les compromis et le chemin de migration, en utilisant une infrastructure de production reelle comme implementation de reference.

Le probleme : AOSS a une facture minimale dure

Lorsque vous creez une Bedrock Knowledge Base via la console ou Terraform, AWS vous oriente vers OpenSearch Serverless comme vector store par defaut. Ce defaut est pratique, mais il cache une realite tarifaire facile a manquer en proof of concept et douloureuse en production.

OpenSearch Serverless facture en OpenSearch Compute Units (OCUs) :

• 2 OCUs minimum pour l'indexation
• 2 OCUs minimum pour la recherche
• Plus les multiplicateurs de redondance en mode production

Cela donne un minimum de 4 OCUs pour toute collection non-dev. Au tarif on-demand de eu-west-1 d'environ 0,24$ par OCU-heure : 4 OCU x 0,24$/OCU-h x 730 h/mois ~ 700$/mois

C'est le plancher. Index vide. Aucun trafic. Aucune requete. Juste pour que la collection existe.

Pour un cas d'usage RAG leger -- un chatbot de documentation, un assistant Q&R interne, un bot de deflection de support ; cela eclipse tout le reste de la stack. Les invocations de modele Bedrock, Lambda, API Gateway et S3 combines coutent souvent moins de 100$/mois. OpenSearch represente alors 80 a 90% de la facture pour un travail minimal.

Le workload de reference

Les chiffres ci-dessous proviennent d'une infrastructure IA de production (Terraform, eu-west-1) avec cette forme :

En d'autres termes : un workload RAG a l'echelle PME tout a fait normal. Le genre pour lequel OpenSearch Serverless est agressivement sur-provisionne.

Pourquoi Aurora Serverless v2 + pgvector est le bon choix ici

Amazon Bedrock Knowledge Bases supporte officiellement Amazon Aurora PostgreSQL-Compatible comme vector store, aux cotes d'OpenSearch Serverless, Pinecone, MongoDB Atlas et Redis Enterprise. Ce n'est pas un hack ou un contournement ; c'est une integration de premier ordre, documentee par AWS.

Les ingredients :

• Aurora Serverless v2 fait evoluer le calcul en Aurora Capacity Units (ACUs) et, depuis fin 2024, supporte le scaling a 0 ACUs au repos.
• pgvector est l'extension PostgreSQL standard pour la recherche de similarite vectorielle, avec les types d'index ivfflat et hnsw.
• Bedrock Knowledge Base peut utiliser un cluster Aurora directement, a condition que la table, la colonne vectorielle et l'index HNSW soient pre-crees selon la spec AWS.

Pour notre profil Titan v2 / 1024 dimensions / quelques milliers de chunks, un cluster Aurora Serverless v2 avec min_capacity = 0 / max_capacity = 2 gere l'ingestion et la recuperation confortablement.

Comparaison des couts

En utilisant les tarifs on-demand actuels de eu-west-1 comme reference representative (refaites toujours le calcul pour votre region) :

Oui -- en chiffres ronds, c'est une reduction de cout de 10 a 15x sur la ligne vector store, soit environ 600$+/mois d'economies par environnement. Multipliez cela a travers dev / staging / prod et les economies annuelles deviennent serieuses rapidement.

Ou AOSS reste gagnant

Ce n'est pas un post "pgvector bat OpenSearch." AOSS reste la bonne reponse quand :

• Vous avez besoin d'un p99 inferieur a 100ms a tres haut QPS avec de grands index.
• Votre corpus fait des dizaines de millions de vecteurs et continue de croitre.
• Vous voulez une recherche hybride mot-cle + vecteur avec les fonctionnalites full-text d'OpenSearch.
• Vous avez besoin des plugins neuronaux, rerankers et pipelines semantiques fournis avec OpenSearch.

Pour tout ce qui est en dessous de ce plafond, soit la plupart des workloads RAG dans la nature ; Aurora + pgvector est largement assez rapide et dramatiquement moins cher.

Plan de migration

La migration est simple mais comporte quelques pieges qu'il vaut mieux connaitre a l'avance.

1. Provisionner Aurora Serverless v2 avec pgvector

resource "aws_rds_cluster" "kb" {
  engine                      = "aurora-postgresql"
  engine_mode                 = "provisioned"
  engine_version              = "15.5"
  database_name               = "kb"
  master_username             = "kb_admin"
  manage_master_user_password = true
  storage_encrypted           = true
serverlessv2_scaling_configuration {
min_capacity = 0      # scale-to-zero au repos
max_capacity = 2
}
}
resource “aws_rds_cluster_instance” “kb” {
cluster_identifier = aws_rds_cluster.kb.id
instance_class     = “db.serverless”
engine             = aws_rds_cluster.kb.engine
engine_version     = aws_rds_cluster.kb.engine_version
}

Ensuite, a la premiere connexion :

CREATE EXTENSION IF NOT EXISTS vector;
CREATE SCHEMA bedrock_integration;
CREATE TABLE bedrock_integration.bedrock_kb (
id        uuid PRIMARY KEY,
embedding vector(1024),
chunks    text,
metadata  json
);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON bedrock_integration.bedrock_kb
USING gin (to_tsvector(‘simple’, chunks));

Les noms et types de colonnes (id, embedding, chunks, metadata) sont obligatoires pour Bedrock Knowledge Base ; suivez la spec AWS exactement.

2. Stocker les identifiants DB dans Secrets Manager

Bedrock KB lit les identifiants de base de donnees depuis un secret Secrets Manager. Si vous utilisez manage_master_user_password = true sur le cluster, Aurora gere ce secret pour vous -- transmettez simplement son ARN a la configuration de la Knowledge Base.

3. Pointer la Knowledge Base vers Aurora au lieu d'OpenSearch

Dans Terraform, echangez le bloc storage_configuration :

storage_configuration {
  type = "RDS"
  rds_configuration {
    resource_arn           = aws_rds_cluster.kb.arn
    credentials_secret_arn = aws_rds_cluster.kb.master_user_secret[0].secret_arn
    database_name          = aws_rds_cluster.kb.database_name
    table_name             = "bedrock_integration.bedrock_kb"
    field_mapping {
      primary_key_field = "id"
      vector_field      = "embedding"
      text_field        = "chunks"
      metadata_field    = "metadata"
    }
  }
}

Tout ce qui est en amont -- la source de donnees S3, la strategie de chunking, le modele d'embedding, la Lambda d'ingestion -- reste identique.

4. Re-ingester

Declenchez un job d'ingestion complet sur la nouvelle Knowledge Base. Les embeddings sont re-calcules depuis S3, donc il n'y a aucune etape de migration de donnees d'AOSS vers Aurora, vous reconstruisez l'index depuis la source de verite.

5. Desactiver la collection OpenSearch

Seulement apres avoir valide les reponses sur la nouvelle KB. Gardez l'ancienne collection pendant une semaine ou deux ; le cout de ce chevauchement est trivial compare a un mauvais rollback.

Reserves de production

Quelques points a signaler avant de mettre cela en production :

• Demarrages a froid. La reprise du scale-to-zero d'Aurora Serverless v2 prend environ 10 a 15 secondes. Si votre chatbot a des SLAs stricts de p99, mettez min_capacity = 0.5 au lieu de 0 ; vous economisez toujours ~85% par rapport a AOSS.
• Reglage HNSW. Les valeurs par defaut sont bonnes pour commencer. Si le rappel se degrade a l'echelle, ajustez m et ef_construction sur l'index, et hnsw.ef_search au moment de la requete.
• Sauvegardes. Les sauvegardes et snapshots Aurora sont desormais sous votre responsabilite. La snapshot automatique d'OpenSearch Serverless etait automatique.
• VPC. Bedrock KB vers Aurora passe par le VPC. Assurez-vous que les subnets, les security groups et le role de service Bedrock sont correctement configures. C'est la source n1 des bugs de type "ca marche dans la console mais echoue a l'ingestion."
• Plafond de scaling. A partir d'environ 1M+ de vecteurs avec un QPS eleve soutenu, reevaluez. pgvector + HNSW est excellent, mais AOSS et les bases vectorielles specialisees prennent l'avantage dans ce regime.

En conclusion

Pour la grande majorite des applications RAG basees sur Bedrock -- bots de documentation, assistants de connaissance, automatisation du support, Q&R interne -- OpenSearch Serverless est sur-concu et hors de prix. Aurora Serverless v2 avec pgvector est une alternative supportee, de qualite production, qui coute un ordre de grandeur de moins a echelle petite a moyenne, avec une migration qui se mesure en heures plutot qu'en semaines.

Si votre equipe FinOps vous demande pourquoi un "chatbot leger" coute 800$+/mois sur AWS, la reponse se trouve presque certainement dans votre ligne de facturation OpenSearch. Changez le vector store, gardez tout le reste, et recuperez le budget.

Ecrit a partir d'une experience de production avec des Bedrock Knowledge Bases dans eu-west-1. Les prix et configurations refletent AWS en date d'avril 2026 -- validez toujours les prix actuels et les limites de service pour votre region avant de vous engager dans une migration.