ExamPark
Course menuAIP-C01

Exams / AIP-C01 / Study guide / Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases)

Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases): AIP-C01 study notes and practice questions

What to know about Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases) for the AIP-C01 exam, from the Foundation Model Integration, Data Management, and Compliance domain (31% of the exam guide), then 1 free question to test it. Part of the AIP-C01 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

These questions give the existing data location, expected vector count, query rate and whether keyword search is also needed. Pick the store that fits without building infrastructure that AWS already runs.

Managed or bring your own

  • Amazon Bedrock Managed Knowledge Base has Bedrock run the vector store, handle ingestion and provide hybrid keyword plus semantic search. Choose it for the least operations work and the standard connectors.
  • Bring your own store when you need a specific index, an existing database or a feature the managed option does not expose. A Bedrock knowledge base can use a store you own, such as OpenSearch Serverless or Aurora.

Choose the store

Store Fits
OpenSearch Serverless vector collection Hybrid search at scale with no cluster sizing
OpenSearch Service managed domain Existing OpenSearch estate and control over sharding and instance types
Aurora PostgreSQL with pgvector Vectors beside relational data already in Aurora, with SQL joins
Amazon S3 Vectors Very large vector sets, infrequent queries, lowest storage cost
Neptune Analytics Graph traversal across entity relationships (GraphRAG)

Index and sizing

  • HNSW gives fast approximate search with good recall. Higher build and search settings improve recall but use more memory and build time.
  • IVFFlat in pgvector builds faster with less memory but needs tuning for recall.
  • Dimensions multiply memory and storage. Titan Text Embeddings V2 can produce 256, 512 or 1024 dimensions. Smaller vectors cut cost, with a quality trade-off you should measure.
  • Shards in a managed OpenSearch domain spread the index across nodes. Too many small shards waste resources. Multiple indexes in one domain isolate data types but add overhead.
  • Changing the embedding model means re-embedding the whole corpus.

How to choose

Scenario wording Choose
“Existing Aurora app adds semantic search” Aurora PostgreSQL with pgvector
“Billions of archived vectors, rarely queried, lowest cost” S3 Vectors
“Hybrid keyword and semantic search at scale, no cluster to run” OpenSearch Serverless vector collection
“Least operations, standard connectors” Managed knowledge base
“Relationships between entities must be traversed” Neptune Analytics for GraphRAG

Common traps

  • Building a dedicated cluster for a small or infrequent workload that S3 Vectors or Aurora handles.
  • Adding a new database when the data already lives in Aurora.
  • Ignoring how dimensions change memory and cost.
  • Changing the embedding model without re-embedding existing vectors.
  • Expecting interactive chat latency from a store built for cheap, infrequent queries.

See also metadata filtering and data connectors and sync.

Try the 1 practice question

Practice Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases)Take the free practice exam

Question 1

Medium ·Link to this question (question 1)

A four-person IT team at a mid-sized accounting firm is building a search assistant over about 80 GB of client-approved guides stored in Amazon S3 and a SharePoint library.

The team wants the assistant live within a few weeks and does not want to run, patch or tune a vector database. Staff often search for exact form numbers, so the search must combine keyword matching with meaning.

The documents change weekly, and the team wants the index kept up to date without writing sync code.

Which solution meets these requirements?

Choose one answer.

  1. A. Run a self-managed OpenSearch cluster with k-NN indexes, write a Lambda function that chunks, embeds and indexes each document, and expose a query API that the assistant calls.
  2. B. Create an Aurora PostgreSQL cluster with pgvector, run a scheduled job that embeds changed files into a table, and connect the assistant to it for similarity queries.
  3. C. Store the embeddings in Amazon S3 Vectors, which costs little at this scale, and write a retrieval Lambda function along with the connectors and sync logic for SharePoint and S3.
  4. D. Create an Amazon Bedrock Managed Knowledge Base with the built-in S3 and SharePoint connectors, let Bedrock manage the vector store, and rely on its hybrid keyword and semantic search.
Show the answer and explanation

Answer: D

  • A. Wrong: The cluster, the Lambda pipeline and the query API would all need to be built, tuned and patched by a small team. That misses the short timeline and the no-administration goal.
  • B. Wrong: Aurora with pgvector works well for vector search, but the team would own the database, the scheduled job and the change detection. It also needs extra work to combine exact form number matching with meaning. Learn more: Using Aurora PostgreSQL as a knowledge base for Amazon Bedrock (opens in a new tab)
  • C. Wrong: S3 Vectors is inexpensive for large vector collections, but it provides no SharePoint connector or sync logic, so the team would write both. It also leaves keyword matching for form numbers to the team, so the approach misses the setup goal. Learn more: Working with S3 Vectors (opens in a new tab)
  • D. Right: The managed knowledge base provides connectors and incremental sync, so the index updates without sync code, and Bedrock runs the vector store. Its built-in hybrid search matches form numbers as well as meaning, which meets every requirement. Learn more: Build a managed knowledge base (opens in a new tab)

Explanation

A managed knowledge base removes the vector database work and provides the S3 and SharePoint connectors with incremental sync. Its hybrid search handles exact form numbers alongside meaning. The self-managed, Aurora and S3 Vectors options each leave the team building sync, search or database operations.

Retrieval augmented generation with a knowledge base Sync: documents from S3 and other connectors are split into chunks, turned into embeddings, and stored in a vector store. Query: a user question retrieves the best matching chunks from the vector store, and the model writes an answer from them with citations. Sync Documents S3, connectors Chunk + embed embeddings Vector store managed or own Query User question from the app Retrieve best chunks Model answers with citations
The built-in connectors and a Bedrock-managed vector store mean the small team runs no search infrastructure.

Study

Want more on Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases)? The 5 full-length practice sets have 6 more Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study Choosing and scaling vector stores (OpenSearch, Aurora pgvector, S3 Vectors, managed knowledge bases)

More Foundation Model Integration, Data Management, and Compliance topics