On June 17, 2026, AWS launched Amazon Bedrock Managed Knowledge Base, a fully managed retrieval-augmented generation (RAG) service. It is useful when:
Keep a custom RAG pipeline when you need full control over indexing, chunking, retrieval algorithms, re-ranking models, infrastructure placement, or cross-cloud portability.
| Capability | Custom RAG | Managed Knowledge Base |
|---|---|---|
| Data ingestion | Build and maintain connectors | Configure supported connectors and sync schedules |
| Parsing | Combine custom code, Textract, Transcribe, and file-specific libraries | Use Smart Parsing |
| Chunking | Design and test chunking per document type | Start with managed defaults and override when needed |
| Embeddings | Select a model, generate vectors, and handle version consistency | Use managed embeddings or bring your own model |
| Vector storage | Provision, scale, secure, and monitor a vector database | Use managed storage or connect your own backend |
| Retrieval | Implement semantic, keyword, or hybrid search | Use managed hybrid or semantic retrieval |
| Re-ranking | Add and operate a separate re-ranking model | Use the managed re-ranker or provide your own |
| Multi-hop retrieval | Build orchestration with an agent framework | Use Agentic Retrieval |
| Access control | Add metadata filtering and identity-aware retrieval | Use connector ACLs and pass user context |
| Sync operations | Build refresh, retry, and re-index workflows | Configure scheduled synchronization |
This doesn't mean there's no work left. It means the work shifts toward application behavior and away from undifferentiated retrieval infrastructure.
Managed Knowledge Base ships with connectors for:
They support scheduled synchronization, so the index stays current without a separate ingestion app. Document-level access control works for the enterprise connectors but not the Web Crawler, so treat the crawler as a fit for public content.
Before building a custom connector, check that your source and its permission model aren't already covered. A custom connector still earns its place for internal platforms, domain-specific preprocessing, unusual source APIs, pre-ingestion validation, or authorization models that can't be mapped directly.
Real enterprise content is rarely clean text, so Smart Parsing picks a processing strategy per file type, using two managed capabilities:
| Format | Processing path | Developer consideration |
|---|---|---|
| BDA or foundation model parser | Best fit for preserving tables, images, and reading order | |
| DOCX | BDA | Converted internally before parsing |
| PPTX | Smart Parsing | BDA does not process PPTX directly |
| JPG and PNG | Nova Multimodal Embeddings | Maximum image size is 3.75 MB |
| MP3, WAV, M4A, FLAC, and OGG | BDA | Use transcription for spoken content |
| MP4, MOV, and M4V | BDA and Nova Multimodal | Audio and visual content are processed separately |
| TXT, Markdown, HTML, CSV, XLS, and XLSX | Default parser | No additional parsing model cost |
| Scanned documents | BDA | OCR is applied before chunking |
Smart Parsing selects these paths automatically. On a Managed Knowledge Base it's the only parsing strategy, so you don't choose a parser or supply a parsing prompt. If you need a configurable foundation-model parser with a custom extraction prompt, that's only available with a customer-managed knowledge base.
In a custom AWS pipeline this usually means Lambda, Amazon Textract, Amazon Transcribe, format-specific libraries, orchestration, retries, and intermediate storage. Smart Parsing puts that behind a managed workflow.
Still, test it against your own documents, including the messy ones like scanned PDFs, complex tables, and diagrams. The question isn't whether a file made it in, but whether the retrieved chunks still carry enough meaning to answer a real question.
Use Retrieve
when a query can usually be answered in a single pass ("What is the travel reimbursement limit?", "What is the audit-log retention period?"). Standard retrieval supports hybrid search, combining semantic vector search with keyword matching, because neither is enough alone: semantic search handles meaning and paraphrasing, while keyword search handles exact identifiers, product names, error codes, and policy terms.
Initial results can be re-scored before they reach the application, which helps when many chunks look relevant but only a few answer the question. A common custom design:
query -> retrieve top 20 chunks -> re-rank -> send best 5 to the model
Managed Knowledge Base performs this step with a managed model. You can use the managed re-ranker, supply your own, or disable re-ranking.
Use AgenticRetrieveStream
when an answer spans multiple documents or policies. Consider: "What is the ML platform team's infrastructure budget, and does the expense policy allow prepaying annual commitments?" A single retrieval may find the budget but miss the policy. Agentic retrieval decomposes the question, retrieves iteratively, evaluates whether it has enough context, and produces a citation-backed response, removing the need to build that loop in LangGraph or a similar framework. It does not remove the need for application-level validation, authorization, observability, and evaluation.
Quotas exist at two levels: a broad Managed Knowledge Base service quota and operation-specific defaults. The operation-specific limit can be stricter, so confirm the active values in Service Quotas for your account and Region and design around the tightest one.
| Constraint | Value |
|---|---|
| Managed KB query length | 10,000 characters |
| Managed KB storage | 10 TB per knowledge base |
| Managed KB service quota | 300 Retrieve or AgenticRetrieveStream requests per minute |
AgenticRetrieveStream operation-specific default |
|
| 1 request per second per account | |
Retrieve operation-specific default |
|
| 100 requests per second per account and 5 per second per knowledge base | |
RetrieveAndGenerate support |
|
| Not supported for Managed Knowledge Bases | |
| Supported retrieval APIs | |
Retrieve and AgenticRetrieveStream |
|
Because agentic retrieval is more expensive and more quota-constrained, route by query type:
Simple factual query -> Retrieve
Complex multi-document -> AgenticRetrieveStream
Handle ThrottlingException
and ServiceQuotaExceededException
with bounded retries, exponential backoff with jitter, and a user-safe fallback.
Managed Knowledge Base integrates with Amazon Bedrock AgentCore and can be exposed through AgentCore Gateway as MCP-compatible tools for both Retrieve
and AgenticRetrieveStream
. Supported frameworks include Strands Agents, LangChain, CrewAI, LlamaIndex, and LangGraph, giving a standard tool interface without locking the whole application into one framework. The security requirement is unchanged: pass userContext
explicitly when document-level permissions apply.
If you take one thing from this section, make it this: identity propagation is on you. When Managed Knowledge Base is exposed through AgentCore Gateway, IAM identity is not automatically passed along as the document-level user identity. If document permissions are enabled, your application has to send userContext
explicitly, or the retrieval layer may quietly skip the per-user filtering you were counting on.
A safe request flow: authenticate the user, resolve their enterprise identity and groups, map that to the knowledge base ACL format, add it to userContext
, call Retrieve
or AgenticRetrieveStream
, and log the authorization decision without logging sensitive content. Application access and document access are separate concerns; don't let IAM, OAuth, or your IdP stand in for document ACLs.
Make permission checks part of CI or release validation: a permitted user can retrieve a document, a non-permitted user cannot, group-based access works, removed access is reflected after synchronization, public content stays available, and a missing userContext
fails safe.
ACL filtering answers who may retrieve a document. Guardrails address a different problem: unsafe or disallowed content. Treat retrieved documents as untrusted input, because they can carry prompt-injection instructions, malicious links, outdated procedures, or sensitive values embedded in otherwise permitted files.
For standard Retrieve
, the request accepts a guardrail configuration. For agentic retrieval, AgenticRetrieveStream
accepts policyConfiguration
with an Amazon Bedrock Guardrail; AWS currently supports the BLOCK
action on this path, not MASK
. A production design combines document-level authorization through userContext
, metadata filtering, guardrails, a clear separation between system instructions and retrieved content, output validation for high-risk actions, and human approval before an agent performs irreversible operations.
Amazon Bedrock Knowledge Bases now offers two architectures.
With a Managed Knowledge Base, Bedrock handles ingestion, parsing and chunking, embeddings, vector storage, index scaling, retrieval optimization, and managed re-ranking. You don't choose OpenSearch, Aurora, Pinecone, or another external vector store as the backend for this type.
With a customer-managed knowledge base, you keep direct control of the vector backend, choosing among services such as Amazon OpenSearch Serverless, Aurora with pgvector
, Neptune Analytics, Amazon S3 Vectors, Pinecone, or Redis Enterprise Cloud. Bedrock still provides ingestion and retrieval integration, but your team owns the datastore's provisioning, scaling, security, availability, and cost.
| Architecture | Use it when | Primary trade-off |
|---|---|---|
| Managed Knowledge Base | You want the fastest production path and do not need direct vector-store control | Fewer infrastructure choices |
| Customer-managed Knowledge Base | You need a specific datastore, existing vector estate, custom index control, or data-placement requirement | More operational responsibility |
| Fully custom RAG | Retrieval behavior is a differentiating product capability | Maximum control and maximum engineering ownership |
An external vector database is not an optional backend inside a Managed Knowledge Base; it's a different architecture, and that matters when you estimate cost and effort.
Pricing is pay-per-use with no minimum commitment.
| Component | Price |
|---|---|
| Index storage | $5.00 per GB per month |
| Standard retrieval | $1.00 per 1,000 calls |
| Agentic retrieval | $4.00 per 1,000 agentic calls, plus $1.00 per 1,000 retrieval calls |
| Smart Parsing | Free with managed models |
| Managed embeddings | Free |
| Managed re-ranking | Free |
| Custom models | Standard Amazon Bedrock model pricing |
As a rough estimate, 10 GB of indexed data plus 10,000 standard retrieval calls per month lands near $60. For a small or medium workload, the managed service can come in below the cost of operating a dedicated vector platform once engineering and operational effort are counted. Still, model document size, index growth, sync frequency, retrieval volume, the share of agentic queries, foundation model inference, and observability cost, plus customer-managed vector-store cost if you're comparing architectures.
Managed Knowledge Base configuration is represented in the AWS CloudFormation resource specification. The ManagedKnowledgeBaseConfiguration
type supports EmbeddingModelType: MANAGED
or CUSTOM
, a custom embedding model ARN, embedding model configuration, and server-side encryption configuration. Several of these require resource replacement when changed, so treat model and encryption choices as architecture decisions, not routine runtime settings.
On AWS CDK, expect to use CfnKnowledgeBase
until higher-level constructs cover the managed configuration. Pin the CDK version in CI, review the synthesized template to confirm the expected configuration is emitted, and test replacement behavior in a non-production account before changing embedding or encryption properties. Keep any escape-hatch code isolated so it's easy to remove once the CDK L2 surface catches up.
Managed does not mean automatic. Your team still owns the decisions that shape application quality and safety.
| Decision | What the team must define |
|---|---|
| Application authorization | How users and groups map to userContext |
| Knowledge base selection | Which data should be searched for each request |
| Embedding model | Managed or custom, with the same model used for ingestion and inference |
| Re-ranking | Managed, custom, or disabled |
| Knowledge-base architecture | Managed, customer-managed, or fully custom RAG |
| Chunking | Managed defaults or document-specific overrides |
| Agentic iteration limit | |
maxAgentIteration based on quality, latency, and cost |
|
| Evaluation | A repeatable set of queries, expected sources, and answer criteria |
| Observability | Latency, empty results, permission failures, retrieval quality, and cost |
| Failure handling | Timeouts, throttling, source sync failures, and fallback behavior |
| User experience | Citations, confidence cues, feedback, and escalation paths |
A managed retrieval service reduces code, but it can't define what a correct answer means for your users.
Managed Knowledge Base publishes runtime metrics to CloudWatch under the AWS/Bedrock/KnowledgeBases
namespace.
| Metric | What it tells you |
|---|---|
Invocations |
|
| Total requests, including failed requests | |
ClientErrors |
|
Non-throttling HTTP 4xx responses |
|
ServerErrors |
|
HTTP 5xx responses |
|
Throttles |
|
HTTP 429 responses |
|
TotalIterationCount |
|
Agentic retrieval iterations for successful AgenticRetrieveStream requests |
|
RawDataSize |
|
| Raw source-data size after ingestion completes |
The publishing identity needs cloudwatch:PutMetricData
for that namespace. Metric delivery is best effort, so a missing permission silently drops telemetry rather than failing the retrieval request.
Ingestion logs can be delivered to Amazon CloudWatch Logs, Amazon S3, or Amazon Data Firehose, covering crawl, synchronization, indexing, chunk creation, deletion, and failures. Retrieve
can also emit AWS X-Ray traces; use traces for latency and ingestion logs when a document was expected but not returned. Alarm on sustained Throttles
, a rising ClientErrors
rate, any material ServerErrors
rate, unexpected TotalIterationCount
growth, failed ingestion events, and rapid RawDataSize
growth.
As of the June 17, 2026 general-availability announcement, Managed Knowledge Base was available in US East (N. Virginia), US West (Oregon), Asia Pacific (Sydney, Tokyo), Europe (Dublin, Frankfurt, London), and AWS GovCloud (US-West). Availability changes over time, so confirm support in your target Region before committing to data-residency, networking, disaster-recovery, or latency assumptions.
On June 30, 2026, AWS placed Amazon Kendra into Maintenance Mode, meaning no new features or capabilities, and the service stops accepting new customers on July 30, 2026; existing customers can continue to use it. AWS points to Amazon Bedrock Knowledge Bases for similar capabilities. Treat this as a migration assessment rather than an API-compatible replacement: inventory Kendra indexes, connectors, metadata, ACL behavior, and relevance tuning; rebuild an evaluation set from real Kendra queries; compare retrieval quality and permission behavior; and recalculate cost and operational ownership before planning API changes.
You don't need to migrate the whole RAG platform at once.
The TL;DR covers when Managed Knowledge Base fits. Keep or build a custom pipeline when retrieval is a core part of the product, you need a proprietary indexing strategy or custom chunk generation and enrichment, you require a specialized re-ranking model or direct access to every vector and metadata operation, the application must run across multiple clouds, your data can't be processed by the managed service, or agentic quotas don't meet the workload. In short, when portability and control matter more than managed integration.
Managed Knowledge Base doesn't make RAG architecture disappear; it clears away a large share of the infrastructure that used to surround it. For a lot of teams, that's a trade worth making: less time babysitting connectors, parsers, embedding jobs, retrieval plumbing, and vector databases, and more time on the things users actually notice, like secure access, useful answers, citations, and evaluation. It shines when retrieval is a capability inside your product. When retrieval is the product, a custom stack still gives you the room to differentiate.
Whatever you decide, don't start with a full migration. Start with a small, honest test: real documents, real permissions, real queries. Compare retrieval quality, latency, security behavior, engineering effort, and cost, and let that tell you which parts of the stack are worth keeping custom.
| Topic | Source |
|---|---|
| General availability, connectors, capabilities, and launch Regions | |
AgenticRetrieveStream
request and response modelRetrieve
request shape and userContext