TL;DR

Αν τρέχεις ένα Amazon Bedrock Knowledge Base με OpenSearch Serverless (AOSS), πληρώνεις ένα κατώφλι ~$700/μήνα πριν καν εισάγεις το πρώτο έγγραφο. Για τα περισσότερα μικρά και μεσαία RAG workloads, η αντικατάσταση του AOSS με Aurora PostgreSQL Serverless v2 με το pgvector extension ρίχνει αυτό το κατώφλι κάτω από $50/μήνα, μείωση κόστους ~90%, παραμένοντας ένα πλήρως υποστηριζόμενο, first-class vector store για Bedrock Knowledge Bases.

Αυτό το post εξετάζει το γιατί, τα μαθηματικά, τα trade-offs και τη διαδρομή μετάβασης, χρησιμοποιώντας μια πραγματική production υποδομή ως reference implementation.

Το πρόβλημα: Το AOSS έχει σκληρό ελάχιστο λογαριασμό

Όταν δημιουργείς ένα Bedrock Knowledge Base μέσω console ή Terraform, η AWS σε κατευθύνει προς το OpenSearch Serverless ως το προεπιλεγμένο vector store. Αυτή η προεπιλογή είναι βολική, αλλά κρύβει μια πραγματικότητα τιμολόγησης που είναι εύκολο να χάσεις σε ένα proof of concept και επίπονη στην παραγωγή.

Το OpenSearch Serverless χρεώνει σε OpenSearch Compute Units (OCUs):

• 2 OCUs minimum για indexing
• 2 OCUs minimum για search
• Συν redundancy multipliers σε production mode

Αυτό σου δίνει ένα minimum 4 OCU για κάθε non-dev collection. Με την on-demand τιμή στο eu-west-1 περίπου $0.24 ανά OCU-ώρα: 4 OCU x $0.24/OCU-hr x 730 hr/μήνα = περίπου $700/μήνα

Αυτό είναι το κατώφλι. Άδειο index. Μηδενική κίνηση. Μηδέν queries. Απλά για να υπάρχει το collection.

Για ένα λιτό RAG use case -- ένα documentation chatbot, ένα εσωτερικό Q&A assistant, ένα support deflection bot -- αυτό επισκιάζει όλα τα υπόλοιπα στο stack. Τα Bedrock model invocations, Lambda, API Gateway και S3 μαζί συχνά κοστίζουν κάτω από $100/μήνα. Το OpenSearch τότε αντιπροσωπεύει το 80-90% του λογαριασμού ενώ κάνει ελάχιστη δουλειά.

Το reference workload

Οι αριθμοί παρακάτω προέρχονται από μια production AI υποδομή (Terraform, eu-west-1) με αυτή τη μορφή:

Με άλλα λόγια: ένα απολύτως φυσιολογικό SMB-scale RAG workload. Ο τύπος για τον οποίο το OpenSearch Serverless είναι επιθετικά over-provisioned.

Γιατί το Aurora Serverless v2 + pgvector είναι η σωστή επιλογή εδώ

Το Amazon Bedrock Knowledge Bases υποστηρίζει επίσημα το Amazon Aurora PostgreSQL-Compatible ως vector store, παράλληλα με OpenSearch Serverless, Pinecone, MongoDB Atlas και Redis Enterprise. Δεν είναι hack ή workaround· είναι μια first-class, τεκμηριωμένη από την AWS ενσωμάτωση.

Τα συστατικά:

• To Aurora Serverless v2 κλιμακώνει το compute σε Aurora Capacity Units (ACUs) και, από τα τέλη του 2024, υποστηρίζει κλιμάκωση σε 0 ACUs όταν είναι idle.
• Το pgvector είναι το standard PostgreSQL extension για vector similarity search, με ivfflat και hnsw index types.
• Το Bedrock Knowledge Base μπορεί να χρησιμοποιήσει ένα Aurora cluster απευθείας, εφόσον το table, το vector column και το HNSW index έχουν προδημιουργηθεί σύμφωνα με τις προδιαγραφές της AWS.

Για το προφίλ μας με Titan v2 / 1024-διαστάσεις / μερικές χιλιάδες chunks, ένα min_capacity = 0 / max_capacity = 2 Aurora Serverless v2 cluster διαχειρίζεται άνετα το ingestion και το retrieval.

Σύγκριση κόστους

Χρησιμοποιώντας τις τρέχουσες on-demand τιμές στο eu-west-1 ως αντιπροσωπευτική βάση (πάντα ξαναϋπολόγισε τα νούμερα για το δικό σου region):

Ναι -- σε στρογγυλούς αριθμούς, αυτό σημαίνει μείωση κόστους 10-15x στη γραμμή του vector store, ή περίπου $600+/μήνα εξοικονόμηση ανά environment. Πολλαπλασίασε το σε dev / staging / prod και η ετήσια εξοικονόμηση γίνεται σοβαρή γρήγορα.

Πού το AOSS εξακολουθεί να κερδίζει

Αυτό δεν είναι ένα post «το pgvector νικάει το OpenSearch». Το AOSS παραμένει η σωστή απάντηση όταν:

• Χρειάζεσαι sub-100ms p99 σε πολύ υψηλό QPS με μεγάλα indexes.
• Το corpus σου είναι δεκάδες εκατομμύρια vectors και αυξάνεται.
• Θέλεις hybrid keyword + vector search με τα full text features του OpenSearch.
• Χρειάζεσαι τα neural plugins, rerankers και semantic pipelines που συνοδεύουν το OpenSearch.

Για οτιδήποτε κάτω από αυτό το ταβάνι -- που είναι τα περισσότερα RAG workloads στην πράξη -- το Aurora + pgvector είναι υπεραρκετά γρήγορο και δραματικά φθηνότερο.

Περίγραμμα μετάβασης

Η μετάβαση είναι απλή αλλά έχει μερικές παγίδες που αξίζει να γνωρίζεις εκ των προτέρων.

1. Provision Aurora Serverless v2 με 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 όταν idle
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
}

Στη συνέχεια, κατά την πρώτη σύνδεση:

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

Τα ονόματα και οι τύποι στηλών (id, embedding, chunks, metadata) είναι υποχρεωτικά από το Bedrock Knowledge Base· ακολούθησε ακριβώς τις προδιαγραφές της AWS.

2. Αποθήκευσε τα DB credentials στο Secrets Manager

Το Bedrock KB διαβάζει τα database credentials από ένα Secrets Manager secret. Αν χρησιμοποιείς manage_master_user_password = true στο cluster, η Aurora διαχειρίζεται αυτό το secret για σένα -- απλά δώσε το ARN του στη διαμόρφωση του Knowledge Base.

3. Στρέψε το Knowledge Base στο Aurora αντί για OpenSearch

Στο Terraform, αντικατέστησε το storage_configuration block:

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

Όλα τα upstream -- το S3 data source, η chunking strategy, το embedding model, το ingestion Lambda -- παραμένουν ίδια.

4. Re-ingest

Ενεργοποίησε ένα full ingestion job στο νέο Knowledge Base. Τα embeddings υπολογίζονται εκ νέου από το S3, επομένως δεν υπάρχει βήμα data migration από το AOSS στο Aurora -- ξαναχτίζεις το index από το source of truth.

5. Απενεργοποίησε το OpenSearch collection

Μόνο αφού έχεις επικυρώσει τις απαντήσεις στο νέο KB. Κράτησε το παλιό collection για μία ή δύο εβδομάδες· το κόστος αυτής της επικάλυψης είναι αμελητέο σε σύγκριση με ένα κακό rollback.

Production caveats

Μερικά πράγματα που αξίζει να επισημάνω πριν το στείλεις:

• Cold starts. Το Aurora Serverless v2 scale-to-zero επανέρχεται σε περίπου 10-15 δευτερόλεπτα. Αν το chatbot σου έχει αυστηρά p99 SLAs, όρισε min_capacity = 0.5 αντί για 0· εξακολουθείς να εξοικονομείς ~85% σε σχέση με το AOSS.
• HNSW tuning. Οι προεπιλογές είναι εντάξει για αρχή. Αν το recall υποβαθμιστεί σε κλίμακα, ρύθμισε τα m και ef_construction στο index, και το hnsw.ef_search κατά το query time.
• Backups. Τα Aurora backups και snapshots είναι πλέον δική σου ευθύνη. Το OpenSearch Serverless snapshotting ήταν αυτόματο.
• VPC. Το Bedrock KB προς Aurora τρέχει μέσω VPC. Βεβαιώσου ότι τα subnets, security groups και ο Bedrock service role είναι σωστά συνδεδεμένα. Αυτή είναι η #1 πηγή σφαλμάτων τύπου «δουλεύει στο console αλλά αποτυγχάνει στο ingestion».
• Scaling ceiling. Σε ~1M+ vectors με σταθερά υψηλό QPS, επαναξιολόγησε. Το pgvector + HNSW είναι εξαιρετικό, αλλά το AOSS και τα purpose-built vector DBs προηγούνται σε αυτό το εύρος.

Συμπέρασμα

Για τη συντριπτική πλειοψηφία των Bedrock-powered RAG εφαρμογών -- documentation bots, knowledge assistants, support automation, εσωτερικό Q&A -- το OpenSearch Serverless είναι υπερβολικά σχεδιασμένο και υπερτιμημένο. Το Aurora Serverless v2 με pgvector είναι μια υποστηριζόμενη, production-grade εναλλακτική που κοστίζει μια τάξη μεγέθους λιγότερο σε μικρή-μεσαία κλίμακα, με μετάβαση που μετριέται σε ώρες αντί για εβδομάδες.

Αν η ομάδα FinOps σου ρωτάει γιατί ένα «ελαφρύ chatbot» κοστίζει $800+/μήνα στο AWS, η απάντηση σχεδόν σίγουρα βρίσκεται στη γραμμή του OpenSearch στον λογαριασμό σου. Άλλαξε το vector store, κράτησε όλα τα υπόλοιπα ίδια, και πάρε πίσω τον προϋπολογισμό.

Γραμμένο από εμπειρία παραγωγής τρέχοντας Bedrock Knowledge Bases στο eu-west-1. Οι τιμές και οι διαμορφώσεις αντικατοπτρίζουν το AWS τον Απρίλιο του 2026 -- πάντα επικύρωνε την τρέχουσα τιμολόγηση και τα service limits για το region σου πριν δεσμευτείς σε μια μετάβαση.