Migrate to Amazon Bedrock Managed Knowledge Base with your coding agent

Amazon Web Services added a knowledge base migration guide to the `amazon-bedrock` skill in its Agent Toolkit for AWS, giving coding agents context to plan a move from customer-managed knowledge bases to Amazon Bedrock Managed Knowledge Base. The guide starts with read-only discovery and a line-by-line reviewable plan; on approval the agent creates the new knowledge base and data sources alongside the original or writes a migrated infrastructure-as-code template, while ingestion and updating the application's `Retrieve` calls remain with the customer. AWS recommends the managed option because Bedrock handles ingestion, storage, indexing and retrieval with hybrid search always on, plus a managed embedding model, managed reranker, native connectors for Amazon S3, Microsoft SharePoint and Atlassian Confluence, ACL-aware retrieval, and agentic retrieval across multiple knowledge bases.

Artificial Intelligence https://aws.amazon.com/blogs/machine-learning/ Migrate to Amazon Bedrock Managed Knowledge Base with your coding agent With a customer-managed knowledge base on Amazon Bedrock https://aws.amazon.com/bedrock/ , you provision and scale the vector store, tune the embedding model and index settings, and plan capacity for each new data source. The migration guide in the Agent Toolkit for AWS helps you migrate to Amazon Bedrock Managed Knowledge Base https://docs.aws.amazon.com/bedrock/latest/userguide/kb-build-managed.html . Managed Knowledge Base takes over that work and adds new retrieval capabilities, and your team keeps control of the content and the application that uses it. Moving a production knowledge base means your team maps its configuration, creates the replacement, ingests content, updates the application’s retrieval call, and validates retrieval before switching traffic. To help, we added a knowledge base migration guide to the amazon-bedrock skill in the Agent Toolkit for AWS https://docs.aws.amazon.com/agent-toolkit/latest/userguide/skills.html . The guide gives your coding agent the context to plan the migration with you, starting with read-only discovery and a plan you review line by line. On your approval, the agent creates the new knowledge base and its data sources alongside the original, or writes a migrated infrastructure as code IaC template for your pipeline. Ingestion and updating your application’s Retrieve calls stay with you, and your agent can walk you through both. In this post, we explain why we recommend the move and how the migration guide works, review the prerequisites, install the skill, plan a migration, update the application’s retrieval call, and validate retrieval before cutover. Why move to Managed Knowledge Base We recommend Managed Knowledge Base because it balances ease of use, retrieval accuracy, and cost. AWS runs the store With a Managed Knowledge Base, Amazon Bedrock handles ingestion, storage, indexing, and retrieval, and the store scales automatically as your content grows. Hybrid search, which combines keyword and semantic matching, is always on, with no index to configure. The knowledge base includes a managed embedding model, a managed reranker, and a built-in parser for multimodal file types. You can still bring your own Amazon Bedrock embedding model when you create the knowledge base. On each retrieval request, you choose the managed reranker, an Amazon Bedrock reranking model, or no reranking. The managed reranker requires the managed embedding model. Built-in capabilities Managed Knowledge Base includes capabilities you’d otherwise build yourself: - Native connectors ingest content directly from sources such as Amazon Simple Storage Service Amazon S3 , Microsoft SharePoint, and Atlassian Confluence. For the current list, see supported connectors https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-create.html kb-managed-connectors . After the first full sync, later syncs pick up only changes, on demand or on a schedule. The Managed Knowledge Base includes a deletion safeguard to help protect against accidental bulk removal of indexed content. - Access control list ACL awareness https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.html ingests document permissions with the content, so retrieval returns only what the signed-in user can access. For connectors that support it, such as Microsoft SharePoint and Atlassian Confluence, a real-time check against the source also catches permission changes since the last sync. ACL awareness doesn’t authenticate users, so your application must verify and pass the user’s identity. - Agentic retrieval https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-agentic-retrieve.html answers questions that a single search can’t by handling multi-part questions and retrieving iteratively. It can search more than one knowledge base in a single request. - Integration with AgentCore Gateway https://docs.aws.amazon.com/bedrock/latest/userguide/kb-gateway-target.html , a capability of Amazon Bedrock AgentCore, exposes your knowledge base as a target. Any client that supports the Model Context Protocol MCP can then query the knowledge base, and the gateway handles authentication. - Resource-based policies https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-cross-account.html let applications in other AWS accounts use one team’s knowledge base. Scope each policy to the specific roles that call the knowledge base, and grant only the actions they use, such as bedrock:Retrieve . Agentic retrieval, AgentCore Gateway integration, and resource-based policies are not available on customer-managed knowledge bases. For the AWS Regions where managed knowledge bases are available, and the features that AWS GovCloud US-West doesn’t support, see Supported AWS Regions https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-regions.html . Higher quotas As of this writing, higher default quotas change how you can organize content. With 200 data sources per knowledge base, you can group related content in one knowledge base. With 10,000 knowledge bases per account, per Region, each team or product line can use a separate knowledge base. | 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 | For current values, see Amazon Bedrock endpoints and quotas https://docs.aws.amazon.com/general/latest/gr/bedrock.html limits bedrock and Service quotas for managed knowledge bases https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-quotas.html . Pay for what you store and retrieve Cost is one of three things teams weigh when they consider this move, alongside customizability and direct control of the vector store. On a customer-managed knowledge base https://docs.aws.amazon.com/bedrock/latest/userguide/kb-build-managed.html , you choose, provision, scale, and update the vector and text stores, and pay separately for the infrastructure you select. On a Managed Knowledge Base, those stages are part of the service, and storage and retrieval are metered directly. The pricing models can differ too. With a customer-managed knowledge base, storage and retrieval charges depend on the vector store you choose. Some stores charge for provisioned or minimum capacity, and others, such as Amazon S3 Vectors, a capability of Amazon S3, charge only for what you use. A Managed Knowledge Base is priced on what you store and retrieve, so cost follows real usage. Usage-based pricing can fit enterprise question-answering, policy, and support knowledge bases that run at low utilization. For current rates, see Amazon Bedrock pricing https://aws.amazon.com/bedrock/pricing/ . For the parsers available on a customer-managed knowledge base and how each is billed, see Parsing options for your data source https://docs.aws.amazon.com/bedrock/latest/userguide/kb-advanced-parsing.html . | Cost driver | Customer-managed knowledge base | Managed Knowledge Base | | Vector storage | Priced separately by your chosen store. A provisioned retrieval service can have a minimum idle cost even at low volume | Included in the base storage rate of $5 per GB per month | | Multimodal document parsing | Requires Amazon Bedrock Data Automation, billed by page or image, or a foundation model, billed by token. Text-only parsing is free. | Included | | Embedding generation | Billed separately at your embedding model’s rate | Included with the default model. Charges apply only if you choose a custom model | | Ingestion, sync, and re-sync compute | Re-embedding, orchestration code, and indexing compute spikes on each sync add recurring cost | Included, with incremental sync that processes only new and changed content | | Connectors | Building and running custom connectors can add compute cost | Native connectors are included | | Standard retrieval | No Amazon Bedrock charge per query. Your vector store can charge per query, as Amazon S3 Vectors does. | $1 per 1,000 retrieval requests | | Reranking | Amazon Rerank is charged at $1 per 1,000 queries. A custom reranking model is billed at its own rate | Included in the $1 per 1,000 retrieval requests | | Agentic retrieval | You build the agentic workflow on a Bedrock model, which can cost roughly $18 to $24 per 1,000 queries before development and maintenance. Because model usage is billed by token, the price per query varies. | Agentic retrieval costs an additional $4 per 1,000 queries on top of the underlying retrieval calls, including multi-shot retrieval, reranking, and answer generation. Depending on the number of underlying retrieval calls, the total can range from roughly $6 to $9 per 1,000 queries. | Rates are only part of the total cost of ownership. On a customer-managed knowledge base, your team provisions, scales, and operates each stage as a separate resource. A Managed Knowledge Base consolidates them into one resource, with a default embedding model, foundation model, and reranker, and with per-knowledge-base rate limits by default. You manage the content and the application that uses it, and Amazon Bedrock operates the managed storage, embedding model, foundation model, and reranker. Solution overview A customer-managed knowledge base uses the VECTOR type, with a vector store you configure. A Managed Knowledge Base uses the MANAGED type. The migration guide directs your agent to create a new MANAGED knowledge base alongside the original without modifying or deleting the original during migration. Using the guide’s map, your agent writes a plan that lists which settings remain unchanged, which Managed handles differently, and which application changes you need to make. As Figure 1 shows, the original keeps serving every request while your team ingests content, validates, and cuts over. How the migration guide works The guide separates planning from implementation. In Explore mode, your agent answers questions about Managed Knowledge Base and can inspect your configuration with read-only calls, so you can estimate the effort. In Migration mode, the guide takes your agent through checkpoints: 1. Introduce and choose. Your agent explains what it will and won’t touch. Choose the mode, a live knowledge base or IaC source, and a plain default or technical explanation style. 2. Identify. Confirm the account and AWS Region. Your agent flags over-broad credentials, asks whether you want a cost analysis, and creates an output directory. 3. Discover. Your agent reads the knowledge base and data sources with read-only calls, or reads your template files. 4. Plan. Review the plan and application changes. By default, your agent stops here. 5. Implement, if requested. For a live build, approve the exact preview of the provisioning script, and approve again if it changes. For IaC, your agent writes a migrated template and reports which schema checks ran. 6. Handoff. Review what was produced and your team’s remaining steps. As Figure 2 shows, resource creation stays separate from ingestion and cutover. Review the configuration mapping The guide maps each setting to preserve your data sources, filters, and chunking behavior when the managed type uses a different configuration. The plan classifies each setting: - 1:1. The new knowledge base uses the same setting. - Adjusted. Managed uses a different setting for the same outcome, and the plan applies the substitution. - Blocked. There is no managed path today. Your agent excludes that knowledge base from the build, explains why, and points you to AWS Support. Other knowledge bases in the same run can proceed. Compare chunking on your own content when you validate. Review the permissions and generated changes Discovery, planning, and the entire IaC path nee