TL;DR

Wenn du eine Amazon Bedrock Knowledge Base mit OpenSearch Serverless (AOSS) als Backend betreibst, zahlst du eine ~$700/Monat-Untergrenze, bevor du ein einziges Dokument aufnimmst. Fur die meisten kleinen und mittleren RAG-Workloads senkt der Austausch von AOSS gegen Aurora PostgreSQL Serverless v2 mit der pgvector-Erweiterung diese Untergrenze auf unter $50/Monat -- eine ~90% Kostenreduktion; und bleibt dabei ein voll unterstutzter, erstklassiger Vector Store fur Bedrock Knowledge Bases.

Dieser Beitrag geht das Warum, die Rechnung, die Trade-offs und den Migrationspfad durch, unter Verwendung einer echten Produktionsinfrastruktur als Referenzimplementierung.

Das Problem: AOSS hat eine harte Mindestrechnung

Wenn du eine Bedrock Knowledge Base uber die Konsole oder Terraform erstellst, lenkt AWS dich in Richtung OpenSearch Serverless als Standard-Vector-Store. Dieser Standard ist bequem, verbirgt aber eine Preisrealitat, die in einem Proof of Concept leicht zu ubersehen und in der Produktion schmerzhaft ist.

OpenSearch Serverless rechnet nach OpenSearch Compute Units (OCUs) ab:

• 2 OCUs Minimum fur Indexierung
• 2 OCUs Minimum fur Suche
• Plus Redundanz-Multiplikatoren im Produktionsmodus

Das ergibt ein 4 OCU Minimum fur jede Nicht-Dev-Collection. Beim eu-west-1 On-Demand-Tarif von etwa $0,24 pro OCU-Stunde: 4 OCU x $0,24/OCU-Std. x 730 Std./Monat = ~$700/Monat

Das ist die Untergrenze. Leerer Index. Kein Traffic. Keine Queries. Nur dafur, dass die Collection existiert.

Fur einen schlanken RAG-Anwendungsfall -- einen Dokumentations-Chatbot, einen internen Q&A-Assistenten, einen Support-Entlastungs-Bot -- ubertrifft dies alles andere im Stack bei weitem. Bedrock-Modellaufrufe, Lambda, API Gateway und S3 zusammen kommen oft auf unter $100/Monat. OpenSearch macht dann 80-90% der Rechnung aus, wahrend es sehr wenig Arbeit leistet.

Der Referenz-Workload

Die folgenden Zahlen stammen aus einer Produktions-KI-Infrastruktur (Terraform, eu-west-1) mit dieser Form:

Mit anderen Worten: ein vollig normaler SMB-RAG-Workload. Die Art, fur die OpenSearch Serverless aggressiv uberdimensioniert ist.

Warum Aurora Serverless v2 + pgvector hier die richtige Wahl ist

Amazon Bedrock Knowledge Bases unterstutzt offiziell Amazon Aurora PostgreSQL-Compatible als Vector Store, neben OpenSearch Serverless, Pinecone, MongoDB Atlas und Redis Enterprise. Das ist kein Hack oder Workaround, sondern eine erstklassige, von AWS dokumentierte Integration.

Die Zutaten:

• Aurora Serverless v2 skaliert Rechenleistung in Aurora Capacity Units (ACUs) und unterstutzt seit Ende 2024 Skalierung auf 0 ACUs im Leerlauf.
• pgvector ist die Standard-PostgreSQL-Erweiterung fur Vektor-Ahnlichkeitssuche, mit ivfflat- und hnsw-Indextypen.
• Bedrock Knowledge Base kann einen Aurora-Cluster direkt nutzen, vorausgesetzt, Tabelle, Vektorspalte und HNSW-Index sind gemaas der AWS-Spezifikation vorab erstellt.

Fur unser Titan v2 / 1024-Dimensionen / einige-tausend-Chunks-Profil bewaltigt ein min_capacity = 0 / max_capacity = 2 Aurora Serverless v2-Cluster die Aufnahme und Abfrage problemlos.

Kostenvergleich

Unter Verwendung der aktuellen eu-west-1 On-Demand-Preise als reprasentative Basis (rechne die Zahlen immer fur deine Region neu):

Ja -- in runden Zahlen ist das eine 10-15x Kostenreduktion beim Vector-Store-Posten, oder etwa $600+/Monat Ersparnis pro Umgebung. Multipliziere das uber Dev / Staging / Prod und die jahrlichen Einsparungen werden schnell ernsthaft.

Wo AOSS immer noch gewinnt

Dies ist kein "pgvector schlagt OpenSearch"-Beitrag. AOSS bleibt die richtige Antwort, wenn:

• Du sub-100ms p99 bei sehr hohem QPS mit grossen Indizes brauchst.
• Dein Korpus zig Millionen Vektoren umfasst und wachst.
• Du hybride Keyword- + Vektorsuche mit den Full-Text-Features von OpenSearch mochtest.
• Du die Neural Plugins, Reranker und semantischen Pipelines brauchst, die mit OpenSearch ausgeliefert werden.

Fur alles unterhalb dieser Grenze -- und das sind die meisten RAG-Workloads in der Praxis -- ist Aurora + pgvector mehr als schnell genug und dramatisch gunstiger.

Migrationsuberblick

Die Migration ist unkompliziert, hat aber ein paar Fallstricke, die man vorher kennen sollte.

1. Aurora Serverless v2 mit pgvector bereitstellen

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 im Leerlauf
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
}

Dann, beim ersten Verbinden:

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

Die Spaltennamen und -typen (id, embedding, chunks, metadata) sind von Bedrock Knowledge Base vorgeschrieben; halte dich genau an die AWS-Spezifikation.

2. Die DB-Anmeldedaten in Secrets Manager speichern

Bedrock KB liest Datenbank-Anmeldedaten aus einem Secrets Manager-Secret. Wenn du manage_master_user_password = true am Cluster verwendest, verwaltet Aurora dieses Secret fur dich -- ubergib einfach dessen ARN an die Knowledge Base-Konfiguration.

3. Die Knowledge Base auf Aurora statt OpenSearch ausrichten

In Terraform tauscht man den storage_configuration-Block aus:

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"
    }
  }
}

Alles Upstream -- die S3-Datenquelle, die Chunking-Strategie, das Embedding-Modell, die Ingestion-Lambda -- bleibt identisch.

4. Neu aufnehmen

Stosse einen vollstandigen Ingestion-Job gegen die neue Knowledge Base an. Embeddings werden aus S3 neu berechnet, es gibt also keinen Datenmigrationsschritt von AOSS zu Aurora -- du baust den Index aus der Source of Truth neu auf.

5. Die OpenSearch-Collection stilllegen

Erst nachdem du die Antworten auf der neuen KB validiert hast. Behalte die alte Collection ein oder zwei Wochen; die Kosten dieser Uberlappung sind trivial im Vergleich zu einem fehlgeschlagenen Rollback.

Produktionshinweise

Ein paar Dinge, die man beachten sollte, bevor man das in Produktion nimmt:

• Cold Starts. Aurora Serverless v2 Scale-to-Zero benotigt etwa 10-15 Sekunden zum Wiederaufwachen. Wenn dein Chatbot strenge p99-SLAs hat, setze min_capacity = 0.5 statt 0; du sparst immer noch ~85% gegenuber AOSS.
• HNSW-Tuning. Die Standardwerte sind fur den Anfang in Ordnung. Wenn der Recall bei Skalierung nachlasst, passe m und ef_construction am Index sowie hnsw.ef_search zur Query-Zeit an.
• Backups. Aurora-Backups und Snapshots liegen jetzt in deiner Verantwortung. OpenSearch Serverless-Snapshots waren automatisch.
• VPC. Bedrock KB zu Aurora lauft uber die VPC. Stelle sicher, dass Subnetze, Security Groups und die Bedrock-Service-Rolle korrekt verdrahtet sind. Das ist die haufigste Ursache fur "es funktioniert in der Konsole, scheitert aber bei der Aufnahme"-Fehler.
• Skalierungsobergrenze. Bei etwa 1M+ Vektoren mit anhaltend hohem QPS solltest du neu bewerten. pgvector + HNSW ist exzellent, aber AOSS und dedizierte Vector DBs ziehen in diesem Bereich davon.

Fazit

Fur die uberwiegende Mehrheit der Bedrock-basierten RAG-Anwendungen -- Dokumentations-Bots, Wissensassistenten, Support-Automatisierung, interne Q&A -- ist OpenSearch Serverless uberentwickelt und uberteuert. Aurora Serverless v2 mit pgvector ist eine unterstutzte, produktionsreife Alternative, die im kleinen bis mittleren Masstab eine Grosenordnung weniger kostet, mit einer Migration, die in Stunden statt Wochen gemessen wird.

Wenn dein FinOps-Team gefragt hat, warum ein "leichtgewichtiger Chatbot" uber $800/Monat auf AWS kostet, liegt die Antwort mit ziemlicher Sicherheit in deiner OpenSearch-Abrechnungszeile. Tausche den Vector Store aus, behalte alles andere bei und hole dir das Budget zuruck.

Geschrieben aus Produktionserfahrung beim Betrieb von Bedrock Knowledge Bases in eu-west-1. Preise und Konfigurationen entsprechen AWS Stand April 2026 -- validiere immer die aktuellen Preise und Service-Limits fur deine Region, bevor du dich fur eine Migration entscheidest.