Choosing the vector layer
Lesson 1 of 3 in Vector Stores at Professional Scale.
Under every RAG answer sits a vector store, and the exam tests whether you can pick one like an architect instead of a tourist. The managed path: Bedrock Knowledge Bases quick-creates an Amazon OpenSearch Serverless index and owns chunking, embedding, storage, and retrieval end to end. The bring-your-own path keeps the same Knowledge Bases front door but supplies the store: OpenSearch (Serverless or managed cluster — highest sustained-QPS serving, hybrid and neural search via the Neural plugin), Aurora PostgreSQL with pgvector (vectors beside relational data — SQL joins and filters in the same engine), Amazon S3 Vectors (dramatically cheaper storage for huge or cold corpora at modest query rates), or partner stores (Pinecone, Redis, MongoDB Atlas) where a contract already exists.
The AIP-C01 exam guide adds two professional wrinkles. Amazon RDS with S3 document repositories: the pattern where vectors and metadata live in the database while the authoritative documents stay in S3, joined by URI. And DynamoDB with vector databases: DynamoDB is not the vector index — it is the millisecond key-value companion holding per-document metadata, sync state, and session context beside whichever store holds the embeddings.
Pick the vector layer
Interactive decision tree — outcomes:
- Knowledge Bases quick-create (OpenSearch Serverless)
Bedrock creates and manages the vector index and the whole ingest-retrieve loop. Exam cues: "minimal operational overhead", "no vector infrastructure to manage".
- OpenSearch Service (Serverless or managed cluster)
The high-performance serving choice: k-NN at scale, neural and hybrid queries, sharding and multi-index control. Both deployment modes are supported Knowledge Bases backends.
- Aurora PostgreSQL + pgvector
IVFFlat/HNSW indexes and distance operators inside PostgreSQL — one engine for similarity plus the relational joins and filters your application already needs.
- Amazon S3 Vectors
Vector buckets with native indexes: sub-second queries at a fraction of dedicated-store cost. The fit is big, cost-sensitive, lower-QPS corpora — not hot-path serving at thousands of QPS.
- Partner store (Pinecone, Redis, MongoDB Atlas)
Knowledge Bases connects to these too — legitimate when the estate already runs one; rarely the exam's "most operationally efficient" pick on AWS-native stems.
| Store | Strengths | Watch out | Exam cue |
|---|---|---|---|
Knowledge Bases quick-create (OpenSearch Serverless) | Fully managed ingest → chunk → embed → retrieve | Less control over engine internals | "Minimal operational overhead" + RAG |
OpenSearch Service | High-QPS k-NN, hybrid/neural queries, sharding & multi-index control | You own sizing (cluster) or capacity-unit economics (serverless) | "High sustained query volume", "hybrid search" |
Aurora PostgreSQL + pgvector | Similarity + SQL joins/filters in one engine; IVFFlat & HNSW | Vector QPS competes with relational load | "Combine vectors with relational/business data" |
Cheapest at-rest vectors; elastic; sub-second queries | Not built for sustained thousands of QPS | "Massive corpus, cost-sensitive, moderate traffic" | |
DynamoDB (companion) | Millisecond metadata, sync state, session context beside the vectors | It is not the similarity index itself | "Metadata and embeddings" paired architecture |
Interactive checkpoint quiz (4 questions) — open this page in a browser to take it.