2.1 Managed RAG Architecture with Bedrock Knowledge Bases

Key Takeaways

  • Use Retrieve when evidence needs custom DLP, authorization, or reranking before model invocation.
  • Do not invent a session ID on the first RetrieveAndGenerate request; Bedrock returns it for later turns.
  • Custom citation prompts must preserve the documented output-format-instructions placeholder and other model-specific requirements.
Last updated: September 2026

2.1 Managed RAG Architecture with Bedrock Knowledge Bases

Retrieval-augmented generation (RAG) supplies a foundation model with external evidence at request time. Amazon Bedrock Knowledge Bases can manage data-source ingestion, parsing, chunking, embeddings, vector storage integration, retrieval, response generation, and citations. The developer still owns source authorization, data quality, synchronization policy, retrieval evaluation, and the application controls around the managed workflow.

Ingestion and runtime are separate planes

During ingestion, a data source is read, parsed, divided into chunks, embedded with the configured embedding model, and written with metadata to a supported vector store. Source and vector-store support changes over time, so verify the current Region and connector documentation rather than treating a memorized list as universal.

Ingestion is asynchronous. Adding an object to a source does not itself prove that the new content is searchable. Start and monitor an ingestion job, check failed-document statistics, and confirm that deleted or changed source records are reflected as intended. For event-driven freshness, an application can debounce source events and start synchronization safely; it should not launch one overlapping job for every object in a large upload.

At runtime, the system embeds or transforms the query, applies filters, retrieves candidate passages, optionally reranks or reformulates, and either returns the passages or sends them to a generation model. Metadata filters are part of authorization design, but they do not replace source-system access controls. For strict tenant isolation, use defense in depth: separate resources where required, enforce application identity, validate filters server-side, and test for cross-tenant retrieval.

Retrieve versus RetrieveAndGenerate

API pathWhat Bedrock returnsChoose it when
RetrieveRetrieved content, locations, metadata, and scoresThe application needs custom reranking, DLP inspection, prompt construction, or a nonstandard generator
RetrieveAndGenerateA generated response plus citation informationA managed end-to-end RAG path meets the workflow requirements

Retrieve exposes the intermediate evidence. That makes it suitable when passages must pass through a proprietary authorization check, data-loss-prevention scanner, or custom cross-encoder before generation. RetrieveAndGenerate reduces application code but offers fewer custom interception points.

For RetrieveAndGenerate, do not invent a session identifier on the first request. Bedrock generates the session ID, and the client returns it on later turns when it wants the same conversational session. Store it as sensitive application state and do not mix it among tenants.

Generation prompt placeholders and citations

A custom generation prompt must include the search-results placeholder. Placeholder requirements vary by model and prompt type. Current Knowledge Bases documentation also states that the output-format-instructions placeholder is required for citations to appear in the response. The query placeholder is required for some models and automatically included for others. Therefore, copy the current template requirements for the selected model rather than assuming that search results and query are the only required variables.

A safe custom template distinguishes instructions, retrieved evidence, and user input. It tells the model to acknowledge insufficient evidence, but wording alone does not enforce factuality. Preserve the output-format instructions when citations are required, validate the returned citation spans, and render source links only after applying authorization rules.

Worked authorization path

Consider a human-resources assistant serving several subsidiaries. The application authenticates the employee, resolves subsidiary and role claims server-side, and constructs an allowlisted metadata filter. Retrieve returns candidate passages and source locations. The application rejects any passage whose metadata does not satisfy the claims, applies a DLP scan, reranks the remaining evidence, and calls Converse with a validated prompt. Citations are mapped back to an authorized document route rather than exposing a raw storage URL.

This flow makes trust boundaries explicit. The browser cannot choose its own tenant filter. The model never grants access. Retrieved text is untrusted content and is delimited so instructions inside it are not treated as system policy. Logs store request and document identifiers with controlled access rather than copying sensitive paragraphs.

For a lower-risk public documentation assistant, RetrieveAndGenerate may be the better managed path. The decision is driven by interception and control requirements, not an assumption that custom code is always more secure.

Session boundary

Treat the Bedrock-generated session identifier as tenant-scoped state. Bind it to the authenticated conversation, expire it with the application session, and reject a client-supplied identifier that belongs to another user. Multi-turn convenience does not replace the application's own authorization and retention policy.

Loading diagram...
Bedrock Knowledge Bases Dual-Pipeline Architecture
Test Your Knowledge

A company must run retrieved passages through a proprietary DLP scanner before generation. Which Knowledge Bases API path provides the needed interception point?

A
B
C
D