The short answer
Migrating from Kendra to Bedrock Managed Knowledge Base is two projects, not one: re-ingesting every data source, and rewriting your application against new APIs. AWS says so itself. The retrieval call maps over cleanly. What does not map are the 25 connectors you lose, plus faceted search, query suggestions, custom synonyms, spell checking, incremental learning and custom document enrichment, all six of which AWS explicitly lists as needing workarounds you build. Kendra ships 32 native connectors; the managed knowledge base ships 7.
Last updated: July 2026. Source: AWS, Amazon Kendra availability change and migration guidance.
If you have read that Amazon Kendra is in maintenance mode and decided to follow AWS's advice onto Bedrock Managed Knowledge Base, this is the article for the next question: what is the actual work?
AWS deserves credit here. Its migration guidance is unusually honest for vendor documentation, and it does not pretend this is a drop-in swap. The trouble is that the honesty is distributed across a long page in calm language, so the total size of the job is easy to underestimate. This is that job, collected in one place.
AWS's own summary is the right place to start, quoted directly: "Migrating from Amazon Kendra to Amazon Bedrock Managed Knowledge Base (BMKB) requires two primary efforts: re-ingesting data sources into BMKB and rewriting application code to use BMKB APIs."
The part that is genuinely easy
Start with the good news, because there is real good news and a fair assessment has to include it.
The core retrieval call maps almost one to one. kendra.retrieve() becomes bedrock-agent-runtime.retrieve(). create_index becomes create_knowledge_base. start_data_source_sync_job becomes start_ingestion_job. Your filter operators translate directly too: EqualsTo becomes equals, ContainsAny becomes in, and so on down the list. An engineer who knows the Kendra API will find the Bedrock one familiar within a day.
Setup is four steps: create the IAM roles, call create_knowledge_base with type MANAGED, call create_data_source, then start_ingestion_job and poll until the status reaches AVAILABLE, typically two to five minutes.
And on generation, Bedrock is a real upgrade. Kendra returned ranked passages and left you to bolt on a language model to turn them into prose. Bedrock does that natively through RetrieveAndGenerate, includes multimodal document parsing, embeddings and re-ranking at no extra cost, and adds agentic multi-step retrieval. If your Kendra deployment was a retrieval layer feeding your own LLM, you are deleting code, not writing it.
The part that is not easy: 25 missing connectors
This is the item that decides your timeline, and the numbers are AWS's own, from its own comparison table.
| Kendra feature | In Bedrock Managed KB? | AWS's prescribed workaround |
|---|---|---|
| 32 native connectors | No, 7 only | Export content to S3 via a pipeline you build and schedule |
| Faceted search | No | Simulate with metadata filters; AWS concedes no dynamic facet counts |
| Query suggestions | No | Stand up a separate OpenSearch index, or an LLM completion layer |
| Custom synonyms | No | Build a query-expansion service over a DynamoDB or S3 dictionary |
| Spell checking | No | A Lambda running SymSpell or an LLM call before retrieval |
| Incremental learning | No | Store click signals in DynamoDB and hand-tune reranking |
| Custom document enrichment | No | A Step Functions or Lambda preprocessing pipeline before S3 |
startsWith / stringContains filters | No | Restructure your metadata schema |
BatchPutDocument | No direct equivalent | S3 upload plus ingestion job |
The managed knowledge base supports seven data sources: S3, Confluence, SharePoint, Google Drive, OneDrive, a Web Crawler, and a Custom connector. That is it. If your Kendra index pulled from Salesforce, ServiceNow, Jira, Slack, Box, Dropbox, an RDS database, or any of the other two dozen systems Kendra spoke to natively, none of them are there.
AWS's answer to this is worth quoting in full, because it is the most consequential sentence in the whole migration guide. For unsupported sources, AWS recommends building "an automated pipeline (using AWS Lambda, Step Functions, or Amazon EventBridge Scheduler) that periodically extracts content from the source system via its API, writes documents to an S3 bucket with appropriate metadata JSON sidecar files, and triggers a BMKB ingestion job." And then, plainly: "This replicates the periodic sync behavior of Kendra connectors."
Read that again. AWS is telling you, in its own documentation, to hand-rebuild the connectors it used to manage for you. That is not a criticism of AWS, which is being straight with its customers. It is a statement about what you are signing up for. Each of those pipelines is a service with credentials to rotate, rate limits to respect, pagination to handle, deletions to propagate, failures to alert on, and an on-call owner. One is a sprint. Six is a team's quarter, and then it is a permanent maintenance obligation.
If you are staffing this, the API rewrite is the part an engineer can move through quickly, and modern tooling helps: an AI coding agent that plans a refactor across a codebase handles a mechanical call-site migration like retrieve() to retrieve() well. The connector fleet is the part that no tool shortcuts, because it is not code translation, it is new systems that did not exist before.
The details that bite later
Metadata becomes sidecar files. Kendra's index-level attributes become .metadata.json files sitting next to each document in S3, capped at 10 KB each, typed as STRING, NUMBER or BOOLEAN. If your filtering logic leaned on wildcard or substring matching, note the missing startsWith and stringContains operators above: AWS's guidance is that you "will need to restructure your metadata schema." That is a data modelling exercise, not a config change.
You now choose a chunking strategy. Kendra handled this internally. Bedrock asks you to decide, and the decision affects retrieval quality directly. AWS suggests a fixed-size strategy at 200 tokens with 30% overlap as a migration starting point. Semantic chunking is not available for managed knowledge bases, and embeddings are fixed at 1024 dimensions, float32.
There is no semantic-only mode. BMKB always performs hybrid search. For most workloads that is fine or better. If you had tuned Kendra toward a specific retrieval behaviour, verify before you assume.
Validate with numbers, not vibes. AWS's recommendation is sound and worth following: run Kendra and BMKB in parallel, compare them on NDCG and MRR against a golden set of real queries, and check p50, p95 and p99 latency. Build that golden set from your actual query logs before you switch anything off, because after the cutover you have lost the baseline.
The pricing model changes shape entirely
This is not a cheaper-or-pricier question, because the two services bill on incommensurable units, and anyone showing you a single headline comparison number is guessing.
Kendra bills provisioned capacity by the hour, from index creation until deletion, whether or not anyone searches. GenAI Enterprise Edition runs $0.32 per hour, roughly $230 a month. Basic Enterprise Edition runs $1.40 per hour, roughly $1,008 a month. That is your floor before a single query.
Bedrock Managed Knowledge Base bills consumption: $5.00 per GB of raw data per month for storage, and $1.00 per 1,000 retrieval API calls, with agentic retrieval at $4.00 per 1,000 calls on top. Model inference for generation is billed separately at standard rates.
So the direction of travel depends entirely on your shape. A large corpus that is rarely queried was well served by Kendra's flat rate and may cost more on storage-plus-calls. A small corpus under heavy query load likely gets cheaper. Model your own two or three scenarios with stated assumptions before you promise anyone a saving.
So should you migrate?
If search is a component inside a product you ship, yes, and Bedrock is the right destination. You get a better generation story, a modern RAG stack, consumption pricing, and AWS's active investment. The connector work is real but it is work in service of something you were always going to own.
The question worth pausing on is the other case. A lot of Kendra indexes were never a product feature. They existed so that employees could find things: the policy document, the runbook, last quarter's deck, the answer somebody already gave in a ticket. If that is what your index is for, then the migration ahead of you is six connector pipelines, a metadata redesign, a chunking strategy, a synonym service, a spell checker, a feedback loop and a frontend, and at the end of it you will have rebuilt a product category that you could have bought.
That is the honest fork, and it is worth naming before the sprint planning starts. InSearch is the buy side of it: you connect Google Drive, Slack, Notion, Confluence, Gmail, Jira and Salesforce, and your team gets a written answer with inline citations back to the source document. Permissions are inherited from each app and enforced at query time, so nobody sees anything they could not already open. There is no index to provision, no chunking strategy to pick, no sidecar schema to design, and nothing to keep running at 2am. It never trains on your data.
Build if search is your product. Buy if search is your plumbing. The migration guide is long enough to make that distinction worth ten minutes of thought.
Frequently asked questions
Is Bedrock Knowledge Bases a drop-in replacement for Kendra?
No, and AWS does not claim it is. Its migration guidance states the move "requires two primary efforts: re-ingesting data sources into BMKB and rewriting application code to use BMKB APIs," and lists six Kendra features that need workarounds you implement yourself. The retrieval API maps over cleanly; the connectors and the enterprise search features do not.
How many connectors does Bedrock Managed Knowledge Base have?
Seven: Amazon S3, Confluence, SharePoint, Google Drive, OneDrive, Web Crawler, and a Custom connector. Amazon Kendra ships 32 native connectors. For any source not on that list of seven, AWS's recommended pattern is to build your own scheduled pipeline that extracts content via the source API, writes it to S3 with metadata sidecar files, and triggers an ingestion job.
What does Kendra do that Bedrock Managed Knowledge Base cannot?
AWS names six features requiring workarounds: faceted search, query suggestions, custom synonyms, spell checking, incremental learning and custom document enrichment. Beyond those, the startsWith and stringContains filter operators are gone, BatchPutDocument has no direct equivalent, and there is no semantic-only search mode.
Is Bedrock Managed Knowledge Base cheaper than Kendra?
It depends on your corpus size and query volume, and the two price on different units. Kendra bills provisioned capacity hourly, roughly $230 a month for GenAI Enterprise Edition or roughly $1,008 for Basic Enterprise Edition, regardless of usage. Bedrock bills consumption: $5.00 per GB per month plus $1.00 per 1,000 retrieval calls, with generation billed separately. Large-corpus low-query workloads may get more expensive; small-corpus high-query workloads usually get cheaper.
How long does a Kendra to Bedrock migration take?
The API rewrite is usually days for an engineer who knows the Kendra SDK, since most calls map directly. The timeline is driven almost entirely by connectors: every source outside Bedrock's seven becomes a pipeline you build, schedule, monitor and maintain. Count your sources first, because that number, not the API surface, is your project plan.