Start with a retrieval contract, not a product list
A retrieval store is part of an evidence contract. Define the corpus, permission filter, query types, update and deletion behaviour, citation identity, recovery objectives, and evaluation set before selecting a service.
Store-selection decision record
| Question | Evidence to collect |
|---|---|
| Can a managed path meet the contract? | Representative queries, filters, citations, Region availability |
| What control is missing if it cannot? | Precise query, ranking, index, topology, or integration requirement |
| Can the team operate the exception? | Backups, restore drill, monitoring, upgrade, and incident ownership |
Choose managed first when it is sufficient
For a greenfield cited-answer workload, begin by testing Amazon Bedrock Knowledge Bases. It can cover ingestion and retrieval with less platform ownership. Move to a customer-managed Knowledge Base configuration or fully custom retrieval only when a required control, integration, or operating model cannot be met and verified.
Evidence-led retrieval ownership escalation
Loading diagram...
Custom retrieval transfers responsibility for ingestion, schema, relevance tuning, scaling, security, backup, observability, and recovery. Record that transfer as an operational commitment.
Compare store families against query and operations shape
Workload-oriented fit matrix
| Pattern | Consider when | Verify before adoption |
|---|---|---|
| S3 Vectors | Vector-native storage fits and semantic-only KB retrieval is sufficient | Integration limits, filters, Region, indexing and retrieval measurements |
| OpenSearch | Hybrid lexical and vector retrieval, filtering, and search tuning are central | Ranking design, capacity, operations, backup and failure behaviour |
| Aurora PostgreSQL with pgvector | Relational data, transactional updates, joins, and vector search share a boundary | Index design, concurrency, restore, scale and relevance |
S3 Vectors does not turn a semantic-only Knowledge Bases integration into hybrid retrieval. OpenSearch can be useful for hybrid control, while a relational store can fit a transactional corpus. None is a universal winner.
Turn the AWS service landscape into a workload decision
AWS Prescriptive Guidance groups vector options by the operational and data shape they serve. Use that landscape to form candidates, then make the choice with observed workload evidence rather than a copied comparison row.
Stable selection dimensions before volatile service figures
| Workload evidence | Candidate implication | Proof before adoption |
|---|---|---|
| Existing relational transactions and joins are authoritative | A relational vector design may reduce cross-system consistency work | Compare query semantics, index behaviour, contention, restore, and citation identity |
| Relationship paths and multi-hop constraints decide the answer | A graph-capable candidate is worth a GraphRAG experiment | Measure traversal scope, graph freshness, authorization propagation, and hybrid-baseline lift |
| Lexical terms, filters, and semantic matches all matter | A search-oriented candidate may justify a hybrid retrieval trial | Use intent slices, negative permission tests, and relevance/citation comparisons |
| The team needs a managed RAG path with a bounded control contract | Test a Bedrock Knowledge Base baseline before taking on database operations | Verify source lifecycle, filters, citations, recoverability, and target Region support |
Choose the knowledge-base pattern from the question contract
Three AWS patterns can all sit behind a chat experience, but they answer different kinds of questions. Start with the shape of evidence that must be retrieved: passages with related meaning, enterprise search results from connected repositories, or exact rows produced by joins and aggregations.
Course-synthesis decision map: three AWS knowledge-base patterns
Loading diagram...
The architecture boundary that changes the implementation
| Pattern | Retrieval or query boundary | Use it when | Do not assume |
|---|---|---|---|
| Unstructured KB with a vector store | Embed query and passages, then retrieve similar chunks from a selected vector index. | Semantic document retrieval, custom metadata, or control over the vector-store design is central. | Similarity retrieval is a substitute for exact calculations, relational joins, or an enterprise connector strategy. |
| Unstructured KB with Kendra GenAI Index | A managed enterprise index retrieves ranked excerpts from connected repositories. | Connector-led enterprise search and a managed hybrid search retriever are the priority. | It is a customer-operated vector database or that every source authorization model transfers unchanged. |
| Structured-data Knowledge Base | Generate SQL from synchronized schema metadata and execute it through the Redshift query engine. | The answer needs current rows, filters, joins, aggregates, or business metrics. | Tables are embedded for semantic nearest-neighbour search or that generated SQL can bypass data permissions. |
Architecture 1: unstructured documents plus a vector-store Knowledge Base
This pattern turns approved unstructured content into chunks and embeddings, writes those embeddings to a vector store, then embeds each user question to retrieve similar evidence. The selected chunks augment the model prompt. It is the clearest fit when related meaning across documents matters more than exact SQL-style computation.
Make the vector-store architecture usable
| Decision | Why it changes the result | First proof |
|---|---|---|
| Chunking, parser, and embedding representation | They decide what evidence can be retrieved together and compared. | Compare permitted-evidence recall and citation quality on a fixed golden set. |
| Vector-store and metadata-filter design | They decide whether query, tenant, classification, and lifecycle constraints remain expressible. | Run positive and negative scope tests under representative load. |
| Source synchronization and deletion path | An embedding index is derived data that can become stale or retain removed evidence. | Observe create, update, delete, resync, and restore behaviour against a source manifest. |
Architecture 2: unstructured enterprise content plus a Kendra GenAI Index
Amazon Kendra GenAI Enterprise Edition is a managed retriever for RAG and intelligent search. It uses hybrid keyword and vector search, semantic embeddings, and reranking behind a managed index. Choose it when a connector-led enterprise search boundary and managed retrieval are more important than selecting and operating every vector-store component yourself.
What the managed Kendra boundary changes
| You receive | You still own | Verify before use |
|---|---|---|
| A managed hybrid search and retrieval index, with connector-led enterprise ingestion and ranking capabilities. | Source choice, index configuration, relevance evaluation, user experience, and the application authorization boundary. | The supported connector, source lifecycle, metadata filters, capacity, Region, and query behaviour for the target workload. |
| A retriever that can supply excerpts to an application or Bedrock Knowledge Base flow. | The answer policy, citation presentation, observability, and response evaluation after retrieval. | Whether the retrieval API and returned evidence fit the required application interaction. |
Architecture 3: structured data plus a managed NL-to-SQL Knowledge Base
Structured-data retrieval is a different contract. Amazon Bedrock Knowledge Bases synchronizes schema metadata, generates SQL from a natural-language question, and uses the Amazon Redshift query engine to query structured sources. It does not turn every table row into an embedding for nearest-neighbour retrieval.
Course-synthesis runtime: inspect NL-to-SQL as a governed query path
Loading diagram...
The first structured-data proof is a query review, not a relevance score
| Question class | Expected evidence | Control to test |
|---|---|---|
| Exact metric, filter, or join | Generated SQL and returned rows or aggregate. | Schema metadata, joins, database grants, and expected-result tests. |
| Narrated analytical answer | Generated SQL, result set, and the answer that summarizes it. | Query inspection plus faithfulness to the returned result, not document-citation recall alone. |
Use graph retrieval when relationships are the missing evidence
A graph-oriented design is justified when an answer depends on traversing explicit relationships, provenance paths, or multi-hop constraints that a strong hybrid baseline cannot recover reliably. It adds modelling and operational complexity, so compare it with the baseline on actual questions.
Architecture decision record excerpt
A workload-owned record that makes the retrieval boundary testable.
Click on an annotation to highlight it in the JSON
For every candidate, test high availability, backup and restore, disaster recovery, residency, scale, update lag, filter enforcement, and reproducibility from a retained index version.
Select with an experiment and an exit plan
- Freeze a representative corpus, permission cases, and question set.
- Run the managed baseline and each justified alternative with the same evaluation and load profile.
- Compare permitted-evidence recall, citation quality, latency distribution, update and delete behaviour, operator effort, and recovery evidence.
- Adopt only a material improvement that preserves the control contract and retains a rollback path.
Turn store choice into a weighted decision record
A store selection is defensible only when its criteria reflect the workload. Start with a baseline option, then weight evidence quality, permission enforcement, update/delete behaviour, operations, recovery, and workload economics according to the product’s actual risks. The weights are owned by the product team, not supplied by a benchmark.
Illustrative weighted decision record
A local decision artifact. Scores are placeholders that must be replaced with observed evidence.
Click on an annotation to highlight it in the JSON
Amazon Bedrock Knowledge Bases converts source content into embeddings, requires a vector store, and must be resynced after source changes. That makes sync, delete, citation, and restore behaviour first-class selection criteria, even where the initial question is only about search relevance.
Use a workload packet instead of generic service comparisons
Create a small, representative packet: labelled documents, update and deletion events, queries by intent, identity cases, expected citations, concurrency shape, and recovery scenario. A candidate has to process the same packet with the same decision rules. This exposes whether a claimed feature survives your access pattern and operating responsibilities.
Proof-of-fit packet
| Packet item | Why it changes the choice | Evidence |
|---|---|---|
| Sparse and frequent queries | Throughput and latency shape differ | Measured distribution, not a copied SLA |
| Exact IDs plus paraphrases | May require hybrid or lexical capability | Slice-level permitted-evidence recall |
| Metadata and tenant cases | Filtering must remain correct under load | Negative cross-scope test |
| Update, deletion, restore | Evidence lifecycle is product behaviour | Observed sync and recovery drill |
S3 Vectors is a workload-based option: AWS positions it for vector storage and lower-throughput or sporadic queries, while its OpenSearch integration supports advanced search needs such as hybrid search, aggregations, and advanced filtering. Use those descriptions as hypotheses to test, not as universal price or latency conclusions.
Prove fit before migration and preserve an exit
A migration starts with a measurable gap, such as a required hybrid query pattern, an unverified recovery requirement, or an update path that fails the workload packet. Keep the existing index as the control while shadowing the candidate. Compare source identity, permission decisions, selected evidence, output citations, operational events, and recovery evidence before changing traffic.
- Capture a source-to-chunk manifest and immutable corpus version before copying or rebuilding an index.
- Run the candidate in shadow mode against the fixed packet, including deletion and cross-scope negative cases.
- Reconcile counts and sample source IDs; investigate any missing, duplicate, or differently scoped evidence.
- Run a restore or rebuild exercise and record elapsed work, owners, and the user-visible fallback.
- Cut over progressively only after the release gate passes; retain the previous configuration until rollback evidence expires.
Primary reference: S3 Vectors integration choices
AWS describes S3 Vectors integrations and distinguishes lower-throughput or sporadic querying from advanced OpenSearch search functions. Verified 2026-08-25; validate fit in the target workload and Region.
AWS S3: use S3 Vectors with other AWS servicesPrimary reference: AWS vector database options for RAG
AWS Prescriptive Guidance surveys managed and individual vector-database options by data model, query pattern, integration, and operational fit. Its live comparisons are a candidate-discovery input, not a substitute for workload measurements or target-Region verification.
Read AWS vector database options for RAGApply a critical-control gate before comparing weighted totals
A store can score well on convenience or retrieval quality and still be ineligible for the workload. Put non-negotiable controls before the weighted comparison: supported ingestion and source lifecycle, identity and metadata enforcement, evidence traceability, recovery ownership, and a target-environment availability review. A candidate that cannot demonstrate one required control is a rejected fit, not a lower-ranked winner.
Critical-control gate
| Gate | Pass evidence | If it fails |
|---|---|---|
| Ingestion lifecycle | Source change, deletion, and resync/rebuild are observed | Keep baseline; define remediation |
| Scoped retrieval | Negative tenant and metadata tests pass | Reject candidate for this workload |
| Recoverability | Restorable source/index manifest and drill owner | Do not cut over |
| Operational ownership | Monitoring, incident, and upgrade responsibility accepted | Reduce scope or stay managed |
Amazon Bedrock documents that source modifications require a resync, and its managed Knowledge Base path is recommended for a managed experience and retrieval accuracy. Those are starting points for a proof, not a reason to skip the workload gate or to assume an alternative is unsafe by default.
Migrate indexes and metadata as a compatibility contract
Migration failures commonly come from a source-to-chunk or metadata mismatch rather than the vector engine itself. Define a canonical source ID, chunk ID, tenant and classification fields, lifecycle state, embedding version, and citation location. Then prove that every required filter remains expressible and that result identities match before routing users to the candidate index.
Index compatibility manifest
An illustrative contract for dual-running a baseline and candidate index.
Click on an annotation to highlight it in the JSON
Run dual reads using the same query, trusted filter, and corpus manifest. Reconcile missing or duplicate source IDs, filter outcomes, citations, and deletion handling. If an incompatibility affects a critical slice, stop the migration, keep the baseline active, correct the mapping, and repeat the proof-of-fit rather than hand-editing production results.
Choose an organisational knowledge architecture by boundary, not by RAG label
An organisational knowledge system can be a managed enterprise search product, a scoped RAG application, a tenant-isolated SaaS feature, or a hybrid edge workload. The deciding question is not “is it RAG?” but where identities, data residency, connectors, retrieval, and operational ownership must live. These AWS examples show materially different boundaries.
Use the architecture boundary to choose the next experiment
| Published AWS pattern | Primary boundary | First proof to collect |
|---|---|---|
| Amazon Q Business enterprise connector path | Managed enterprise data connections and existing permissions. | Connector scope, source lifecycle, permission behavior, user experience, and evaluation workflow. |
| JWT plus OpenSearch multi-tenant RAG | Tenant identity reaching the retrieval and storage path. | Cross-tenant negative tests over candidates, citations, logs, caches, and tool calls. |
| Hybrid and edge RAG | Data residency and where data, embeddings, inference, and orchestration are allowed to run. | Data-flow diagram, location-specific service validation, failure behavior, and access review. |
Glossary: terms first introduced here
These are the technical terms introduced in this step. Later modules build on them rather than redefining them from scratch.
New vocabulary for this step
| Term | Plain-language meaning | Why it matters here |
|---|---|---|
| Vector database | A database or index designed to store embeddings and retrieve similar vectors efficiently. | It is one architectural option, not the whole knowledge-system design. |
| Knowledge graph | A connected representation of entities and relationships, with links back to supporting source evidence. | It can help relationship-heavy questions but creates extracted data that needs lineage and evaluation. |
| Managed knowledge base | An AWS-managed retrieval capability that reduces some integration and index-management work. | A managed path still needs workload-specific evaluation, access controls, and current configuration checks. |
| Amazon Kendra GenAI Enterprise Edition index | A managed Amazon Kendra index type for RAG and intelligent search that provides hybrid keyword and semantic retrieval over connected enterprise content. | It is a managed enterprise retriever, not a customer-operated vector database, so its connector, filtering, edition, and access-control contract must be verified separately. |
| NL-to-SQL (natural-language to SQL) | A capability that converts a natural-language analytical question into a Structured Query Language statement for a governed relational or analytical data store. | It changes the assurance work from nearest-neighbour relevance to schema quality, generated-query review, data permissions, and correct row-level results. |
Knowledge Check
Test your understanding with this quiz. You need to answer all questions correctly to mark this section as complete.