Study guide
2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores
AWS Certified Generative AI Developer - Professional AIP-C01
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview & Foundation Model Fundamentals
1.1 AIP-C01 Exam Structure, Logistics & Passing Strategy 1.2 AIP-C01 Scoring & Professional Decision Strategy 1.3 Foundation Model Landscape & Model Selection on Amazon Bedrock 1.4 Model Abstraction, Controlled Switching & Resilience 1.5 Customization Spectrum: Prompting vs RAG vs Fine-Tuning vs Continued Pre-training 1.6 Custom Model Deployment & Lifecycle Management
2 Chapter 2: Bedrock Knowledge Bases & RAG Architectures
2.1 Managed RAG Architecture with Bedrock Knowledge Bases 2.2 Knowledge Source Integration, Synchronization & Freshness 2.3 Data Ingestion, Parsing & Chunking Strategies 2.4 Embedding Models & Vector Representations 2.5 Vector Index Scale, Migration & Retrieval Evaluation 2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores 2.7 Vector Store Security, Multi-Tenancy & Connectivity
3 Chapter 3: Advanced Vector Search, Indexing & Data Compliance
3.1 Hybrid Search, Metadata Filtering & Semantic Reranking 3.2 Metadata Filtering, Reranking & Query Transformation 3.3 Fine-Tuning & Continued Pre-Training Data Pipeline Engineering 3.4 Data Validation, Multimodal Processing & Model Formatting 3.5 Data Privacy, Data Residency & Compliance Governance 3.6 Privacy Preservation, Source Lineage & Audit Evidence
4 Chapter 4: Prompt Engineering & Bedrock Runtime APIs
4.1 Advanced Prompt Engineering Techniques & Inference Parameters 4.2 Inference Parameters, Prompt Governance & Regression 4.3 Converse API vs InvokeModel API & Message Formatting 4.4 Tool Calling, FM API Resilience & Model Routing 4.5 Streaming Architectures & Asynchronous Event Processing 4.6 Resilient Streaming, Deployment & Asynchronous Processing
5 Chapter 5: Amazon Bedrock Agents & Tool Integration
5.1 Agentic Architecture, ReAct Reasoning Loops & Orchestration 5.2 Agent Frameworks, MCP & Lifecycle Management 5.3 Action Groups, OpenAPI Schemas & AWS Lambda Integration 5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns 5.5 Persistent State & Multi-Agent Coordination 5.6 Advanced Agent Prompt Templates & Flow Customization 5.7 Agent Safeguards, Tool Reliability & Cost Control
6 Chapter 6: Workflow Orchestration & Application Integration
6.1 Amazon Bedrock Prompt Flows & Visual Orchestration 6.2 Step Functions Orchestration & Human-in-the-Loop Workflows 6.3 Enterprise Integration: API Gateway, AppSync, and EventBridge 6.4 Hybrid Integration, GenAI Gateways & CI/CD Tooling
7 Chapter 7: AI Safety & Guardrails for Amazon Bedrock
7.1 Guardrails Architecture, Denied Topics & Content Filters 7.2 Content Safety, Defense in Depth & Threat Detection 7.3 Sensitive Information Filters & PII Redaction/Masking 7.4 Contextual Grounding Checks & Hallucination Prevention
8 Chapter 8: Security, Access Control & Network Architecture
8.1 IAM Least Privilege & Resource Policies for Bedrock 8.2 PrivateLink VPC Endpoints & Network Isolation 8.3 Encryption with AWS KMS & Cross-Account Access Patterns
9 Chapter 9: Governance, Auditing & Operational Logging
9.1 SageMaker Model Cards & AI Governance Frameworks 9.2 Lineage, Fairness, Transparency & Continuous Governance 9.3 Invocation Logging, CloudTrail Auditing & Observability 9.4 Responsible AI, Bias Mitigation & Red Teaming Methodologies
10 Chapter 10: Performance, Throughput & Cost Optimization
10.1 On-Demand vs Provisioned Throughput & Capacity Planning 10.2 Capacity Measurement, Scaling Patterns & Resilience 10.3 Batch Inference & Bedrock Intelligent Prompt Routing 10.4 Intelligent Prompt Routing & Application Eligibility 10.5 Prompt Caching, Token Optimization & Latency Reduction
11 Chapter 11: Testing, Evaluation & Troubleshooting GenAI Solutions
11.1 Amazon Bedrock Model Evaluation (Automatic & Human Workflows) 11.2 Human, RAG & Continuous Evaluation 11.3 Evaluation Metrics & RAG Quality Benchmarking (Ragas, ROUGE, BLEU) 11.4 RAG and Agent Performance Evaluation 11.5 CloudWatch Metrics, Throttling & Operational Observability 11.6 Quota Diagnosis, Retry Control & Operational Troubleshooting 11.7 Troubleshooting Common GenAI Failure Modes & Agent Traces 11.8 Prompt Maintenance, Content Handling & Deployment Validation
2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores
Key Takeaways Explain This Topic AI
Amazon OpenSearch Serverless (Vector Engine) is the default fully managed, serverless vector store for Bedrock Knowledge Bases, auto-scaling compute via OpenSearch Compute Units (OCUs) without cluster administration.
Amazon Aurora PostgreSQL with the pgvector extension enables hybrid workloads where vector similarity search is combined with ACID-compliant relational SQL queries, table joins, and row-level security.
The HNSW index algorithm prioritizes high query recall and low search latency at the expense of higher memory usage and slower index build times, whereas IVFFlat provides faster indexing and lower RAM overhead at the expense of lower recall and required retraining.
Third-party managed vector databases supported by Bedrock Knowledge Bases include Pinecone, MongoDB Atlas, and Redis Enterprise Cloud, connecting securely via AWS Secrets Manager.
Multi-tenant vector architectures must choose between metadata filtering (shared index with tenant ID filtering) for cost-efficiency and index/table isolation for strict regulatory data partitioning.
Last updated: September 2026
2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores
Amazon Bedrock Knowledge Bases separates retrieval orchestration from vector storage. The correct store is therefore not simply the one with the highest advertised benchmark. It is the supported backend that satisfies the workload's retrieval modes, metadata filters, scale, availability, security boundary, operational model, and cost constraints in the required Region.
Current supported storage types
The Bedrock StorageConfiguration API currently lists eight vector-store types: OpenSearch Serverless, Pinecone, Redis Enterprise Cloud, Amazon RDS, MongoDB Atlas, Neptune Analytics, OpenSearch managed clusters, and Amazon S3 Vectors. In the RDS path, Bedrock Knowledge Bases commonly uses Amazon Aurora PostgreSQL-Compatible Edition with pgvector. Support and feature combinations can differ by Region, data type, and creation workflow, so confirm the current table for the selected architecture.
Store Strong fit Important tradeoff to evaluate
OpenSearch Serverless Managed semantic and hybrid search with AWS-native policies and automatic capacity management Collection generation, OCU limits, cold-start behavior, network policy, and maximum-cost controls
OpenSearch managed cluster Teams that need cluster-level OpenSearch control or already operate compatible domains Instance, shard, patching, and scaling responsibility
Aurora PostgreSQL with pgvector Vector retrieval combined with relational joins, transactions, and row-level security Database sizing, connection management, index maintenance, and SQL tuning
Amazon S3 Vectors Durable, cost-oriented vector storage for supported retrieval workloads Verify query features, latency needs, metadata support, and Region availability
Neptune Analytics Graph-aware retrieval where relationships are central to the question Graph modeling and workload-specific operational cost
Pinecone An existing Pinecone platform or a managed multi-cloud vector strategy External service credentials, network path, tenancy, and vendor operations
MongoDB Atlas Documents and vectors managed with an existing Atlas document model External service configuration, network path, and index feature compatibility
Redis Enterprise Cloud Workloads already using Redis vector capabilities and requiring its access patterns Memory-oriented economics, persistence design, and external service management
This list describes supported storage configuration types, not feature equivalence. For example, a backend can support vector retrieval while differing on hybrid search, filtering operators, binary vectors, multimodal data, or managed creation. Test the exact combination instead of transferring a capability from one store to all stores.
OpenSearch Serverless capacity is generation dependent
OpenSearch Serverless measures compute in OpenSearch Compute Units. Current next-generation collection groups can set independent minimum and maximum indexing and search capacity, and a minimum of zero enables scale to zero. Classic collections follow different rules. A next-generation group that has been idle can add first-request latency while workers resume, so zero idle cost and consistently warm latency are different objectives.
Set maximum capacity as a cost boundary and monitor indexing and search OCU use. Do not memorize the older four-OCU floor as a universal rule. Also account for collection grouping, encryption keys, and workload isolation when estimating shared capacity. The exam-worthy reasoning is to identify the collection generation and requirements before calculating cost.
Aurora pgvector decision pattern
Aurora is attractive when vector similarity must be combined with authoritative relational predicates. A bank might retrieve semantically relevant loan clauses while joining customer, region, and active-contract tables in one controlled database path. PostgreSQL row-level security can reinforce tenant rules, although the application must still set and test the correct database identity.
Index choice is empirical. HNSW often favors query recall and latency at the cost of memory and build work; IVFFlat exposes different build, probe, and recall tradeoffs. Neither has a universal recall percentage. Benchmark with the actual corpus, update pattern, filters, top-k, and concurrency. Migration requires re-embedding when the embedding contract changes, dual-read or replay controls, and a measured cutover.
Security and lifecycle checks
For every candidate store, map the complete path: Bedrock service role, secrets or database credentials, KMS keys, network policy, data-access policy, tenant filter, backup or durability behavior, deletion workflow, and audit evidence. A vector-store filter is not the sole authorization boundary. Resolve identity in trusted application code, constrain queries server-side, and run negative cross-tenant tests.
Estimate cost with representative vector count, dimension and type, metadata volume, index build traffic, query rate, idle periods, replicas or availability settings, and data transfer. Benchmark quality and tail latency under filtered queries, not only unfiltered nearest-neighbor search. Select the simplest backend that meets the verified contract, then record the support and pricing assumptions so a future service change triggers review.