AWS published a migration guide on November 12, 2026, for moving customer-managed Amazon Bedrock knowledge bases to Amazon Bedrock Managed Knowledge Base. Delivered through the amazon-bedrock skill in the Agent Toolkit for AWS, it gives a coding agent instructions for inspecting an existing deployment, preparing a migration plan, and optionally creating replacement resources.
The update is operational guidance, not a new foundation model or service launch. Its most consequential detail is the boundary around automation: the agent starts with read-only discovery, presents a plan for review, and needs approval before creating resources. Customers retain control over ingestion, application retrieval changes, validation, and traffic switching, according to AWS’s migration guide.
That separation makes the guide useful beyond generating configuration. A replacement knowledge base can exist successfully while still being unready for production queries. Infrastructure creation and application readiness need separate acceptance checks.
Discovery and Approval Come Before Implementation
AWS describes a staged workflow that keeps implementation optional:
- Discover the existing configuration. The coding agent begins with read-only inspection of the customer-managed knowledge base.
- Produce a migration plan. The customer reviews the proposed move line by line before approving implementation.
- Choose an implementation path. The agent can create a new managed knowledge base and its data sources alongside the original, or produce a migrated infrastructure-as-code template for the customer’s pipeline.
- Complete migration under customer control. Ingestion, application updates, retrieval validation, and cutover remain separate tasks.
The infrastructure-as-code path matters for teams whose production changes must pass through a deployment pipeline. They can use the agent’s output as a reviewable artifact without authorizing it to create the replacement directly.
The parallel-resource path provides a different benefit: the original knowledge base remains available while the replacement is prepared. That supports comparison before traffic moves, although maintaining two environments can also mean overlapping costs once the replacement is populated.
I’d treat the reviewed migration plan as a change-control document. It should make clear what will be created, which configuration choices need a decision, and what must pass validation before the application changes. AWS’s approval checkpoint is useful only if the review resolves those questions.
Prerequisites: Check the Target and the Application
The guide’s entry point is the amazon-bedrock skill in the Agent Toolkit for AWS. AWS’s post covers prerequisites and skill installation; teams should follow those instructions for their chosen coding-agent environment.
Preparation also needs to extend beyond installing the skill. The following readiness checks follow from the workflow and service differences AWS documents:
- Target Region and features: Confirm Managed Knowledge Base availability and the capabilities required by the application. AWS notes regional differences, including unsupported features in AWS GovCloud (US-West).
- Discovery access: Ensure the agent can inspect the existing configuration. Separately decide how resource creation or template deployment will be authorized.
- Configuration decisions: Resolve unsupported or blocked mappings before approving implementation, particularly where the existing deployment depends on direct vector-store control.
- Application ownership: Identify who will update retrieval calls, handle identity information, run validation, and approve cutover.
These are planning recommendations derived from the documented migration boundaries, not evidence that a generated plan automatically resolves every compatibility issue.
Higher Quotas Change How Content Can Be Organized
AWS’s guide lists substantially higher default quotas for managed knowledge bases:
| Default quota | Customer-managed | Managed |
|---|---|---|
| Knowledge bases per account, per Region | 100 | 10,000 |
| Data sources per knowledge base | 5 | 200 |
| Concurrent ingestion jobs per knowledge base | 1 | 50 |
| Query input characters | 1,000 | 10,000 |
These are the defaults reported in the November 12 guide, not guaranteed account-specific allocations or performance measurements.
The organizational implications are significant. The knowledge-base count rises by 100 times, while the data-source count rises by 40 times. A team could consolidate related sources into one knowledge base, or separate knowledge bases by product or team without reaching the old account limit as quickly.
Neither approach is automatically better. I’d choose boundaries around ownership, permissions, and retrieval needs before using the larger quotas to consolidate content. Agentic retrieval can search multiple knowledge bases in one request, so consolidation is no longer the only way to query across related collections.
The concurrency increase also needs careful interpretation. Permission to run 50 ingestion jobs concurrently is a quota difference, not evidence that a particular migration will ingest content 50 times faster.
Retrieval Behavior Changes Along With Storage Management
Managed Knowledge Base takes over ingestion, storage, indexing, and retrieval infrastructure. AWS says hybrid search, combining keyword and semantic matching, is always enabled, with no index to configure. The service also includes a managed embedding model, managed reranking, and a built-in parser for multimodal file types.
The embedding and reranking choices have an important dependency:
- Customers can select their own Amazon Bedrock embedding model when creating the knowledge base.
- Each retrieval request can use the managed reranker, an Amazon Bedrock reranking model, or no reranking.
- The managed reranker requires the managed embedding model.
That last condition belongs in the migration plan. Retaining a particular embedding model can constrain the available reranking configuration. A successful resource deployment alone will not establish that retrieval behaves as the application expects.
AWS also lists agentic retrieval, AgentCore Gateway integration, and resource-based policies as capabilities unavailable on customer-managed knowledge bases. Agentic retrieval handles multipart questions through iterative retrieval and can search more than one knowledge base. AgentCore Gateway can expose the knowledge base to clients supporting the Model Context Protocol, or MCP. Resource-based policies let applications in other AWS accounts access a team’s knowledge base.
For cross-account access, AWS recommends scoping policies to specific calling roles and granting only the actions they use, such as bedrock:Retrieve.
ACL Awareness Still Needs Verified User Identity
Managed connectors can ingest document permissions along with content. For supported connectors, including Microsoft SharePoint and Atlassian Confluence, AWS says real-time source checks can also catch permission changes made since the last synchronization.
But ACL awareness does not authenticate users. The application must verify and pass the user’s identity.
This is the clearest reason to treat the migration as application work as well as infrastructure work. A functioning connector and a populated index are insufficient if the retrieval request lacks the identity needed to enforce document access. Gateway authentication and document-level authorization must both fit the application’s access design.
These capabilities are documented by AWS; the supplied evidence contains no independent retrieval-quality measurements or verified cost savings.
The Customer’s Work Starts Before Cutover
Frequently Asked Questions
3 questions
1Does the Agent Automatically Switch Production Traffic?
No. AWS leaves ingestion, application retrieval updates, validation, and traffic switching under customer control.
