Migration to Amazon Bedrock Managed Knowledge Base: Capabilities, Costs and Control

Introduction to Amazon Bedrock Managed Knowledge Base

Migrating to Amazon Bedrock Managed Knowledge Base moves responsibility for the retrieval infrastructure to AWS while leaving the application and its content with the team. The Agent Toolkit for AWS now includes a migration guide to help a coding agent inspect an existing configuration, prepare a migration plan and, with approval, create a replacement knowledge base or write a migrated infrastructure template.

The important qualification is that this is a staged migration. According to AWS’s migration guide, the original knowledge base continues serving requests while the team prepares and validates its replacement. Ingestion, application changes and the final traffic switch remain the team’s responsibility.

AWS recommends the managed option for its combination of operational simplicity, retrieval capabilities and usage-based pricing. Those are reasons to evaluate a migration, rather than proof that every deployment will become cheaper or more accurate. The supplied AWS account provides capabilities and price comparisons, but no independently verified retrieval benchmark or measured customer savings.

A customer-managed knowledge base uses the VECTOR type and a vector store the team configures. The managed alternative uses MANAGED. Under the customer-managed approach, teams provision and scale the store, tune embedding and index settings, and plan capacity. Under the managed approach, Amazon Bedrock handles ingestion, storage, indexing and retrieval, with automatic storage scaling as content grows.

The decision therefore concerns both functionality and responsibility: which parts of the retrieval system the team wants AWS to operate, and which configuration choices it needs to retain.

Benefits of Migration

The clearest operational benefit is consolidation. AWS describes a managed resource that includes storage, a default embedding model, a foundation model and a reranker. Teams still manage the content and the consuming application, while AWS operates those underlying components. Per-knowledge-base rate limits apply by default.

Hybrid search, combining keyword and semantic matching, is always enabled without an index to configure. A built-in parser handles multimodal file types. Teams can choose their own Amazon Bedrock embedding model when creating the knowledge base, and each retrieval request can use the managed reranker, an Amazon Bedrock reranking model or no reranking. There is a dependency to preserve in planning: the managed reranker requires the managed embedding model.

These capabilities give teams a different retrieval configuration to evaluate. They do not establish an accuracy improvement for a particular corpus. AWS explicitly advises comparing chunking on the team’s own content during validation; a migration plan must account for configuration changes as well as resource creation.

Native connectors can ingest content from sources including Amazon S3, Microsoft SharePoint and Atlassian Confluence. After an initial full synchronization, subsequent syncs process changes, either on demand or on a schedule. A deletion safeguard helps protect against accidental bulk removal of indexed content. Together, these features can reduce the amount of ingestion infrastructure a team needs to operate, although the source does not quantify the work saved.

Permission handling also has an application dependency. Access control list awareness ingests document permissions so retrieval can restrict results to content the signed-in user can access. For supporting connectors, including SharePoint and Confluence, a real-time source check can catch permission changes made since the last synchronization. This feature does not authenticate users: the application must verify and pass their identity.

Agentic retrieval extends the search process by handling multipart questions and retrieving iteratively. It can search multiple knowledge bases within a single request. That is a functional distinction from a single search, but the supplied evidence does not give measured answer-quality results or retrieval-latency comparisons.

AWS also describes an integration with AgentCore Gateway that exposes the knowledge base as a target for clients supporting the Model Context Protocol, with the gateway handling authentication. Resource-based policies support access by applications in other AWS accounts. AWS advises restricting those policies to the calling roles and required actions, such as bedrock:Retrieve.

According to the source, agentic retrieval, AgentCore Gateway integration and resource-based policies are unavailable on customer-managed knowledge bases. These differences can make migration a capability decision as well as an infrastructure decision.

AWS reports higher default quotas for the managed option:

These are the values documented in the supplied source, which qualifies them as current at its writing. They suggest more room to group related data sources or separate knowledge bases by team. The source also flags regional availability and feature exceptions in AWS GovCloud (US-West), without supplying the detailed availability list in the evidence provided here.

Role of the Agent Toolkit for AWS

The migration guide belongs to the toolkit’s amazon-bedrock skill. Its central role is to give a coding agent the context for discovering an existing configuration and mapping it to the managed alternative. It separates planning, optional implementation and the team’s remaining operational steps.

Explore mode supports questions about the managed option and optional read-only inspection. Migration mode follows explicit checkpoints: identify the account and Region, discover the source configuration, produce a plan, optionally implement an approved build, and hand over the results. By default, the agent stops after planning.

The guide supports two implementation paths. For a live knowledge base, the agent reads the existing knowledge base and data sources and can create a managed replacement alongside them. For infrastructure as code, it reads an AWS CloudFormation template, an AWS CDK synthesized template or Terraform configuration, then produces a migrated file in the same format. The team’s pipeline deploys that file; the agent does not deploy it through this path.

The configuration mapping is a particularly important review artifact. It classifies settings into three categories:

• 1:1: The replacement uses the same setting.
• Adjusted: The managed option uses a different setting to achieve the same outcome, and the plan applies that substitution.
• Blocked: No managed migration path exists for that setting. The agent excludes the affected knowledge base from the build, explains the issue and directs the team to AWS Support.

Other knowledge bases in the same run can proceed when one is blocked. This prevents a plan from silently treating an unsupported configuration as equivalent. The guide aims to preserve data sources, filters and chunking behavior, but the mappings still require review and subsequent validation.

Discovery, planning and the entire infrastructure-as-code path need only read-only credentials. A live build requires a separate, scoped build profile, an IAM service role for the new knowledge base, and Python 3 with boto3 for the generated provisioning script. Other prerequisites include a compatible development environment with the toolkit, a configured AWS CLI read-only profile, and access to the original configuration or infrastructure files.

For resource creation, the guide directs the agent to propose a scoped policy that explicitly denies changes to the original knowledge base. It also directs the agent to avoid administrator or full-access permissions, change only resources it created, reference secrets by ARN and ignore instructions contained in data it reads.

Those instructions support a controlled workflow; generated changes still need inspection. A live build requires approval of the exact provisioning-script preview, with renewed approval if it changes. The infrastructure path produces a diff and reports the schema checks performed. After a live build, AWS recommends checking CloudTrail event history, which retains 90 days of management events and records the API call and calling identity.

The handoff is consequential. Creating a resource and its data sources does not finish the migration. The team runs ingestion, updates the application’s Retrieve calls, validates retrieval and switches traffic. The supplied source ends partway through its infrastructure-as-code instructions, so it does not support reproducing a complete command sequence or application payload here.

Cost Considerations

AWS presents usage-based pricing as a potential fit for enterprise question-answering, policy and support knowledge bases with low utilization. The economic case depends on the current store, retrieval volume, model choices and operational effort. Customer-managed stores do not all share the same pricing model: some have provisioned or minimum capacity charges, while Amazon S3 Vectors charges for usage.

The rates below come from the supplied AWS source. They are evidence for its comparison, rather than independently checked current prices.

Agentic retrieval needs separate treatment because an answered question can involve multiple underlying retrieval calls. AWS lists an additional $4 per 1,000 agentic queries on top of those calls, including multi-shot retrieval, reranking and answer generation. Depending on the underlying call count, AWS estimates a total of roughly $6 to $9 per 1,000 queries.

For a customer-managed implementation, the same source estimates roughly $18 to $24 per 1,000 queries for an agentic workflow on a Bedrock model, before development and maintenance. It qualifies that estimate because model usage is billed by token and the cost per query varies. These figures are vendor estimates with workload-dependent conditions, not a controlled cost benchmark or a guaranteed saving.

Storage and query rates also capture only part of the decision. Consolidating components can reduce the resources a team operates, but it changes customizability and direct control over the vector store. Those trade-offs deserve the same attention as the bill, particularly where existing settings receive an adjusted or blocked migration mapping.

The toolkit offers an optional cost analysis using read-only inputs such as CloudWatch metrics, S3 object sizes and AWS Cost Explorer. The guide calls for comparing existing spending with a managed estimate using current AWS prices, and labeling each figure as measured, supplied by the team or estimated. That distinction makes the estimate reviewable: a measured storage footprint and an assumed query volume should not carry the same evidentiary weight.

Conclusion

Amazon Bedrock Managed Knowledge Base offers a documented shift in responsibility and retrieval capabilities: AWS operates more of the underlying system, while teams retain their content and application responsibilities. The Agent Toolkit for AWS makes that shift easier to assess through read-only discovery, explicit configuration mappings and optional creation of a replacement alongside the original.

The evidence supports evaluating reduced operational work, additional retrieval features and a different cost structure. It does not establish universal cost reductions or improved accuracy for every knowledge base. A credible migration decision rests on the configuration mapping, an estimate grounded in the existing workload, and retrieval validation on the team’s content before traffic moves.