TL;DR

Se gestisci una Amazon Bedrock Knowledge Base supportata da OpenSearch Serverless (AOSS), stai pagando un minimo di ~$700/mese prima ancora di caricare un singolo documento. Per la maggior parte dei carichi di lavoro RAG di piccole e medie dimensioni, sostituire AOSS con Aurora PostgreSQL Serverless v2 con l'estensione pgvector riduce quel minimo a meno di $50/mese, un risparmio di circa il 90%; rimanendo un vector store completamente supportato e di prima classe per Bedrock Knowledge Bases.

Questo post illustra il perché, i calcoli, i compromessi e il percorso di migrazione, utilizzando un'infrastruttura di produzione reale come implementazione di riferimento.

Il problema: AOSS ha un costo minimo fisso

Quando crei una Bedrock Knowledge Base tramite console o Terraform, AWS ti indirizza verso OpenSearch Serverless come vector store predefinito. Quel default è conveniente, ma nasconde una realtà di pricing facile da trascurare in una proof of concept e dolorosa in produzione.

OpenSearch Serverless fattura in base alle OpenSearch Compute Units (OCU):

• 2 OCU minimi per l'indicizzazione
• 2 OCU minimi per la ricerca
• Più moltiplicatori di ridondanza in modalità produzione

Questo ti dà un minimo di 4 OCU per qualsiasi collection non di sviluppo. Al tasso on-demand di eu-west-1 di circa $0,24 per OCU-ora: 4 OCU × $0,24/OCU-ora × 730 ore/mese ≈ $700/mese

Questo è il costo minimo. Indice vuoto. Nessun traffico. Nessuna query. Solo per far esistere la collection.

Per un caso d'uso RAG leggero, un chatbot per documentazione, un assistente Q&A interno, un bot di deflection del supporto, questo supera di gran lunga tutto il resto dello stack. Le invocazioni del modello Bedrock, Lambda, API Gateway e S3 messi insieme spesso costano meno di $100/mese. OpenSearch rappresenta quindi l'80-90% della bolletta facendo pochissimo lavoro.

Il carico di lavoro di riferimento

I numeri qui sotto provengono da un'infrastruttura AI di produzione (Terraform, eu-west-1) con questa forma:

In altre parole: un carico di lavoro RAG su scala PMI completamente normale. Il tipo per cui OpenSearch Serverless è aggressivamente sovradimensionato.

Perché Aurora Serverless v2 + pgvector è la scelta giusta qui

Amazon Bedrock Knowledge Bases supporta ufficialmente Amazon Aurora PostgreSQL-Compatible come vector store, insieme a OpenSearch Serverless, Pinecone, MongoDB Atlas e Redis Enterprise. Non è un hack o un workaround; è un'integrazione di prima classe documentata da AWS.

Gli ingredienti:

• Aurora Serverless v2 scala la compute in Aurora Capacity Units (ACU) e, dalla fine del 2024, supporta lo scaling a 0 ACU quando inattivo.
• pgvector è l'estensione PostgreSQL standard per la ricerca di similarità vettoriale, con tipi di indice ivfflat e hnsw.
• Bedrock Knowledge Base può utilizzare direttamente un cluster Aurora, a condizione che tabella, colonna vettoriale e indice HNSW siano pre-creati secondo le specifiche AWS.

Per il nostro profilo Titan v2 / 1024 dimensioni / qualche migliaio di chunk, un cluster Aurora Serverless v2 con min_capacity = 0 / max_capacity = 2 gestisce comodamente ingestione e retrieval.

Confronto dei costi

Utilizzando i prezzi on-demand attuali di eu-west-1 come riferimento rappresentativo (rifai sempre i calcoli per la tua regione):

Sì, in cifre tonde, è una riduzione dei costi di 10-15× sulla voce del vector store, ovvero circa $600+/mese risparmiati per ambiente. Moltiplica per dev / staging / prod e i risparmi annuali diventano seri in fretta.

Dove AOSS vince ancora

Questo non è un post "pgvector batte OpenSearch". AOSS rimane la risposta giusta quando:

• Hai bisogno di p99 sotto i 100ms a QPS molto elevato con indici grandi.
• Il tuo corpus è di decine di milioni di vettori e in crescita.
• Vuoi la ricerca ibrida keyword + vettoriale con le funzionalità full-text di OpenSearch.
• Hai bisogno dei neural plugin, reranker e pipeline semantiche forniti con OpenSearch.

Per tutto ciò che sta sotto quel tetto, ovvero la maggior parte dei carichi di lavoro RAG reali, Aurora + pgvector è più che sufficiente e drasticamente più economico.

Schema di migrazione

La migrazione è semplice ma ha alcune insidie che vale la pena conoscere in anticipo.

1. Provisioning di Aurora Serverless v2 con 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 quando inattivo
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
}

Poi, alla prima connessione:

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));

I nomi e i tipi delle colonne (id, embedding, chunks, metadata) sono obbligatori per Bedrock Knowledge Base; segui esattamente le specifiche AWS.

2. Memorizzare le credenziali del database in Secrets Manager

Bedrock KB legge le credenziali del database da un segreto di Secrets Manager. Se usi manage_master_user_password = true sul cluster, Aurora gestisce quel segreto per te: passa semplicemente il suo ARN alla configurazione della Knowledge Base.

3. Puntare la Knowledge Base ad Aurora invece di OpenSearch

In Terraform, sostituisci il blocco 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"
    }
  }
}

Tutto ciò che sta a monte, la sorgente dati S3, la strategia di chunking, il modello di embedding, la Lambda di ingestione, rimane identico.

4. Re-ingestione

Avvia un job di ingestione completo sulla nuova Knowledge Base. Gli embedding vengono ricalcolati da S3, quindi non c'è nessun passo di migrazione dati da AOSS ad Aurora: ricostruisci l'indice dalla sorgente di verità.

5. Dismettere la collection OpenSearch

Solo dopo aver validato le risposte sulla nuova KB. Mantieni la vecchia collection per una o due settimane; il costo di quella sovrapposizione è irrilevante rispetto a un rollback sbagliato.

Avvertenze per la produzione

Alcune cose da segnalare prima di andare in produzione:

• Cold start. Aurora Serverless v2 scale-to-zero si riattiva in circa 10-15 secondi. Se il tuo chatbot ha SLA p99 stringenti, imposta min_capacity = 0.5 invece di 0; risparmi comunque circa l'85% rispetto ad AOSS.
• Tuning HNSW. I default vanno bene per iniziare. Se il recall degrada a scala, regola m e ef_construction sull'indice, e hnsw.ef_search al momento della query.
• Backup. I backup e gli snapshot di Aurora sono ora una tua responsabilità. Lo snapshotting di OpenSearch Serverless era automatico.
• VPC. Bedrock KB verso Aurora passa attraverso la VPC. Assicurati che subnet, security group e il ruolo di servizio Bedrock siano configurati correttamente. Questa è la fonte numero 1 di bug del tipo "funziona in console ma fallisce nell'ingestione".
• Limite di scalabilità. A circa 1M+ vettori con QPS elevato e sostenuto, rivaluta. pgvector + HNSW è eccellente, ma AOSS e i vector DB specializzati prendono il sopravvento in quel regime.

Conclusione

Per la stragrande maggioranza delle applicazioni RAG basate su Bedrock, bot di documentazione, assistenti di conoscenza, automazione del supporto, Q&A interni, OpenSearch Serverless è sovradimensionato e troppo costoso. Aurora Serverless v2 con pgvector è un'alternativa supportata e production-grade che costa un ordine di grandezza in meno a scala medio-piccola, con una migrazione che si misura in ore anziché settimane.

Se il tuo team FinOps ha chiesto perché un "chatbot leggero" costa $800+/mese su AWS, la risposta è quasi certamente nella voce OpenSearch della bolletta. Sostituisci il vector store, mantieni tutto il resto e recupera il budget.

Scritto dall'esperienza di produzione nella gestione di Bedrock Knowledge Bases in eu-west-1. Prezzi e configurazioni riflettono AWS ad aprile 2026, verifica sempre i prezzi correnti e i limiti di servizio per la tua regione prima di impegnarti in una migrazione.