On this page · 11 sections
- What AWS announced on 30 June 2026
- What Bedrock Managed Knowledge Base gives you instead
- The 6 features Bedrock Knowledge Bases cannot replace
- The connector gap: 32 down to 7
- What you were paying Kendra
- The code you will rewrite
- A migration sequence that does not break production
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. AWS put Amazon Kendra into maintenance mode on 30 June 2026, and from 30 July 2026 the service stops accepting new customers. The recommended replacement is Amazon Bedrock Managed Knowledge Base, which reached general availability on 17 June 2026. The swap is not like-for-like. Kendra ships 32 native connectors; Bedrock Managed Knowledge Base ships 7. Six Kendra capabilities have no direct equivalent at all: query suggestions, faceted search, custom synonyms, spell checking, incremental learning, and custom document enrichment hooks. AWS documents workarounds for every one of them, and each workaround is code your team now owns. Kendra was not cheap to leave running either, at $1.40 per hour for a Basic Enterprise base index and $2,021.28 per month in AWS's own 150,000-document pricing example. Kendra sat inside a wider clear-out: the same 30 June announcement moved 11 services and 10 Amazon SageMaker AI features into maintenance, including Amazon Q Business and Amazon Bedrock Agents.
If your account has never created a Kendra index, the decision is made for you after 30 July. If you already run one, nothing breaks: AWS continues bug fixes and security updates, and no end-of-life date has been published. What stops is new feature work. That distinction is the whole planning problem, because a service that still runs but no longer improves is the kind of dependency that quietly becomes a rewrite two budget cycles later.
This guide covers what actually changes in the code, what the six gaps cost to rebuild, and a migration sequence that does not take production search down with it.
What AWS announced on 30 June 2026
The AWS service availability update posted on 30 June 2026 grouped changes into three buckets: services moving to maintenance, services entering sunset, and services already at end of support.
Kendra landed in the first bucket. Per the Amazon Kendra availability change notice, maintenance mode took effect on 30 June 2026, with no new feature or capability development from that date, and the service stops accepting new customers on 30 July 2026. Existing customers keep bug fixes and security updates. New feature requests are no longer considered.
The same announcement covered a long list, and three items matter if you run AI workloads on AWS:
- Amazon Kendra moves to maintenance, with Amazon Bedrock Managed Knowledge Base named as the replacement.
- Amazon Bedrock Agents becomes Amazon Bedrock Agents Classic and closes to new customers on 30 July 2026, with Amazon Bedrock AgentCore as the successor.
- Amazon Q Business closes to new customers on 31 July 2026, with Amazon Quick as the successor.
Ten Amazon SageMaker AI features went the same way, among them Clarify, Model Monitor, Ground Truth, Debugger and Profiler. Amazon Cognito Sync, AWS Directory Service Simple AD, AWS Management Console myApplications and AWS Service Catalog Application Registry are on the same list.
Read together, that is AWS retiring most of its pre-2024 managed AI tooling in one announcement and pointing everything at Bedrock. The replacement for Kendra, Bedrock Managed Knowledge Base, only reached general availability on 17 June 2026, thirteen days before Kendra's maintenance notice. The successor is younger than the migration deadline.
What Bedrock Managed Knowledge Base gives you instead
Bedrock Managed Knowledge Base runs the whole retrieval pipeline: ingestion, parsing, chunking, embedding, vector storage and retrieval. You do not provision OpenSearch, Aurora or any other vector store, which removes the largest operational burden in a self-managed setup. We have covered that trade-off in detail in our comparison of Bedrock managed knowledge bases against self-managed RAG.
Embedding models are customer-selectable: Amazon Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4 and Amazon Nova Multimodal Embeddings. All are fixed at 1024 dimensions with float32 vectors, so you cannot trade dimensionality for storage cost the way you can with a self-hosted index. If embedding choice drives your relevance, our RAG embedding model selection guide covers how to benchmark that decision.
Two capabilities are genuinely new against Kendra. The RetrieveAndGenerate API returns a generated answer with citations in one call, so you no longer wire a separate LLM step after retrieval. Agentic retrieval plans queries across knowledge bases and re-ranks intermediate results instead of matching a query to the nearest chunks.
Masahiro Oba, Senior General Manager at Sony Group Corporation, described the appeal of that combination in AWS's announcement: "Our enterprise knowledge is distributed across repositories such as SharePoint, Confluence, and Amazon S3, and includes complex documents such as PDFs, presentations, and spreadsheets with charts and tables. Now that Bedrock Managed Knowledge Base and Web Search are available in AgentCore, we can equip agents with advanced retrieval and live web grounding with a consistent governance model, without building these capabilities from scratch."
That is the upside, and it is real for teams whose Kendra index was already only feeding a RAG chatbot. It is much less compelling for teams who bought Kendra to run enterprise search with a search UI in front of it.
Architecture comparison
| Capability | Amazon Kendra | Bedrock Managed Knowledge Base |
|---|---|---|
| Native connectors | 32+ connectors | 7 connectors |
| Embedding model | Managed internally, not selectable | Selectable: Titan V2, Cohere, Nova |
| Vector store | Managed internally | Fully managed by Bedrock |
| Search mode | Keyword, semantic or hybrid | Hybrid only (keyword plus semantic) |
| RAG generation | Requires external LLM integration | Native RetrieveAndGenerate API |
| Agentic retrieval | Not available | Native multi-iteration retrieval |
| Maximum results | 100 passages (Retrieve API) | 100 results (Retrieve API) |
The row that decides most migrations is search mode. Kendra lets you run keyword-only, semantic-only or hybrid. Bedrock Managed Knowledge Base always runs hybrid and offers no semantic-only mode. If your application deliberately used semantic-only retrieval to suppress literal keyword noise, you cannot reproduce that behaviour by configuration.
The 6 features Bedrock Knowledge Bases cannot replace
AWS names six Kendra features with no direct equivalent. Each has a documented workaround, and each workaround is a service your team builds, deploys and maintains.
| Kendra feature | What breaks | Documented workaround |
|---|---|---|
| Query suggestions | GetQuerySuggestions API has no equivalent | Separate OpenSearch index of common query terms, called from the frontend |
| Faceted search | No facet counts, no Facets parameter | Metadata filters plus a hardcoded filter UI, without dynamic counts |
| Custom synonyms | Thesaurus files are not supported | Query expansion service that appends synonyms before the retrieve call |
| Spell checking | No SpellCorrectionConfiguration | Lambda preprocessing with SymSpell, TextBlob or an LLM correction step |
| Incremental learning | SubmitFeedback click signals are gone | Store click data externally, tune reranking and metadata boosts manually |
| Document enrichment | No pre- and post-extraction Lambda hooks | Step Functions or Lambda pipeline that transforms documents before S3 |
1. Query suggestions
Kendra's GetQuerySuggestions API returns autocomplete based on indexed document vocabulary. Bedrock Managed Knowledge Base has nothing equivalent. AWS suggests maintaining a separate Amazon OpenSearch Service index of common query terms extracted from your corpus and calling its suggest API from the frontend before you invoke retrieval.
Note what that does to the architecture. You migrated away from Kendra partly to stop operating a search cluster. The autocomplete workaround puts one back.
2. Faceted search
Kendra supports document attribute facets through the Facets parameter, showing up to 10 facet values per facet with document counts. Bedrock Managed Knowledge Base has no faceted search.
The workaround is metadata filtering with a filter UI you build from a known metadata schema. You get filtering. You do not get counts, and you do not get facets that adapt to the result set. For a legal or compliance search UI where users narrow by counts, that is a visible downgrade your users will report on day one.
# Simulating faceted navigation with metadata filters
response = bedrock_runtime.retrieve(
knowledgeBaseId="your-kb-id",
retrievalQuery={"text": "security best practices"},
retrievalConfiguration={
"managedSearchConfiguration": {
"numberOfResults": 10,
"filter": {
"andAll": [
{"equals": {"key": "department", "value": "engineering"}},
{"equals": {"key": "doc_type", "value": "policy"}}
]
}
}
}
)
3. Custom synonyms
Kendra lets you upload a thesaurus file mapping business-specific terms. Bedrock Managed Knowledge Base does not support custom synonyms.
AWS recommends a query expansion service: keep the thesaurus in DynamoDB or S3, match the incoming query against it, and append the matched synonyms to the query text before calling Retrieve or RetrieveAndGenerate. A user query of "DNS issues" becomes "DNS Route53 issues". Because retrieval is always hybrid, the appended terms match on both keyword and semantic dimensions, which is the one place where the mandatory hybrid mode works in your favour.
4. Spell checking
Kendra corrects spelling against indexed document vocabulary through SpellCorrectionConfiguration. Bedrock Managed Knowledge Base does not.
The documented approach is a Lambda preprocessing step running SymSpell, TextBlob or an LLM correction call before retrieval. An LLM call adds latency and per-query cost to every search, including the majority that were spelled correctly. A dictionary library keeps latency flat but will not learn your product names the way Kendra's corpus-derived correction did.
5. Incremental learning
Kendra's SubmitFeedback API fed click-through and relevance signals back into ranking. Bedrock Managed Knowledge Base has no equivalent.
AWS suggests storing click and rating signals in DynamoDB and using them to adjust metadata boost weights or reranking parameters, with periodic embedding fine-tuning for longer-term improvement. That is a relevance engineering practice, not a configuration setting. Teams that relied on Kendra quietly improving its own ranking will need to staff that work or accept flat relevance.
6. Custom document enrichment
Kendra supports pre-extraction and post-extraction Lambda hooks that modify content and metadata during ingestion. Bedrock Managed Knowledge Base uses Smart Parsing and exposes no equivalent hooks.
The workaround is a preprocessing pipeline in AWS Step Functions or Lambda that performs content extraction, metadata enrichment, PII redaction or format conversion before documents land in the S3 bucket that the knowledge base reads. For regulated workloads this is the gap that matters most, because PII redaction moves from an ingestion hook you could point an auditor at to a pipeline you have to prove ran on every document.
The connector gap: 32 down to 7
Bedrock Managed Knowledge Base supports seven data source connectors: Amazon S3, Confluence, Microsoft SharePoint, Web Crawler, Google Drive, Microsoft OneDrive, and a Custom connector. Kendra supports 32 or more.
For anything not on that list, the documented pattern is to export content to S3 and configure an S3 data source. In practice that means building an automated pipeline with Lambda, Step Functions or Amazon EventBridge Scheduler that calls the source system's API, writes documents to S3 with .metadata.json sidecar files, and triggers an ingestion job. You are reimplementing the sync behaviour a Kendra connector gave you as a checkbox.
Cost it honestly before you commit. A Salesforce or ServiceNow connector replacement is a scheduled extractor with pagination, incremental change detection, deletion handling, error retries and metadata mapping. A safe planning assumption is two weeks of engineering per non-standard source, and that work never appears in the migration diagram.
Metadata itself moves too. In Kendra, document attributes are defined at index level and attached during ingestion. In Bedrock Managed Knowledge Base, metadata lives in .metadata.json sidecar files stored alongside source documents in S3, capped at 10 KB per file, with each attribute typed STRING, NUMBER or BOOLEAN.
What you were paying Kendra
Kendra billing is provisioned capacity: you pay for storage units and query units from index creation until deletion, whether or not you use them. The Kendra pricing page as of July 2026 lists three index types.
| Component | GenAI Enterprise | Basic Enterprise | Basic Developer |
|---|---|---|---|
| Base index (1 storage + 1 query unit) | $0.32 per hour | $1.40 per hour | $1.125 per hour |
| Documents included | Up to 20,000 or 200MB text | Up to 100,000 or 30GB text | Up to 10,000 or 3GB text |
| Query capacity included | 0.1 QPS, approx 8,000 queries/day | 0.1 QPS, approx 8,000 queries/day | 0.05 QPS, approx 4,000 queries/day |
| Additional storage unit | $0.25 per hour | $0.70 per hour | Not available |
| Additional query unit | $0.07 per hour | $0.70 per hour | Not available |
| Connectors | $30 per index per month flat | $0.35 per sync hour plus $1 per 1M docs scanned | $0.35 per sync hour plus $1 per 1M docs scanned |
AWS's own worked examples make the shape clear. A 15,000-document GenAI Enterprise index with 7,000 searches a day and no connectors costs $230.40 per month. A 200,000-document index with 25,000 daily searches, nine extra storage units and two extra query units costs $1,981.20 per month. A 150,000-document Basic Enterprise index with daily connector syncs costs $2,021.28 per month.
Bedrock Managed Knowledge Base bills differently. AWS describes the model as costs based on the size of the knowledge base ingested, the number of queries performed and the LLM usage, rather than provisioned units. That change is directionally good for spiky or small workloads, since an idle Kendra index still billed at full rate. It is not automatically cheaper for high-volume search, because per-query and generation costs now scale with traffic instead of flattening once you have bought a query unit. Model your actual query distribution against the current Bedrock pricing before you assume a saving. The same trap catches teams comparing long-context prompting against retrieval, which we worked through in our long context versus RAG cost analysis.
The real cost is usually the migration, not the runtime bill.
The code you will rewrite
Two clients change. Index and data source management moves from the kendra client to bedrock-agent. Query-time calls move from kendra to bedrock-agent-runtime.
| Operation | Kendra API | Bedrock Managed Knowledge Base API |
|---|---|---|
| Create index or knowledge base | kendra.create_index() |
bedrock-agent.create_knowledge_base() |
| Add data source | kendra.create_data_source() |
bedrock-agent.create_data_source() |
| Sync or ingest documents | kendra.start_data_source_sync_job() |
bedrock-agent.start_ingestion_job() |
| Batch add documents | kendra.batch_put_document() |
Not supported: upload to S3, then ingest |
| Retrieve passages | kendra.retrieve(QueryText=...) |
bedrock-agent-runtime.retrieve() |
| RAG generation | Not available, external LLM required | bedrock-agent-runtime.retrieve_and_generate() |
The batch_put_document row is the one that breaks applications quietly. If your pipeline pushed documents into Kendra directly from application code, there is no equivalent call. Every document now goes to S3 first and enters the index through an asynchronous ingestion job.
Retrieval itself is a shape change more than a logic change:
# Before: Kendra
response = kendra_client.retrieve(
IndexId="your-kendra-index-id",
QueryText="How do I configure VPC endpoints?",
AttributeFilter={
"EqualsTo": {
"Key": "_category",
"Value": {"StringValue": "networking"}
}
},
PageSize=10
)
# After: Bedrock Managed Knowledge Base
response = bedrock_runtime.retrieve(
knowledgeBaseId="your-kb-id",
retrievalQuery={"text": "How do I configure VPC endpoints?"},
retrievalConfiguration={
"managedSearchConfiguration": {
"numberOfResults": 10,
"filter": {
"equals": {"key": "category", "value": "networking"}
}
}
}
)
Three differences bite in review: the query text moves from a top-level parameter into retrievalQuery.text, AttributeFilter becomes filter nested inside managedSearchConfiguration, and results carry a relevance score field Kendra did not return.
Filter operators that disappear
Most operators map cleanly. EqualsTo becomes equals, GreaterThan becomes greaterThan, AndAllFilters becomes andAll, OrAllFilters becomes orAll.
Two do not exist at all. Bedrock Managed Knowledge Base does not support startsWith or stringContains for managed knowledge bases. If your filters do prefix or substring matching on document attributes, you cannot translate them. You restructure the metadata schema to use exact-match or set-membership values instead, which usually means re-tagging the corpus and re-running ingestion.
ContainsAll is the other trap: it maps only partially, onto in, because Bedrock uses set membership rather than requiring every listed value.
Chunking and embedding decisions Kendra made for you
Kendra chunked internally. Bedrock Managed Knowledge Base makes you choose: Default at approximately 300 tokens, Fixed-size with configurable maxTokens and overlapPercentage, Hierarchical parent-child, or No Chunking. Semantic chunking is not supported for managed knowledge bases.
AWS suggests Fixed-size at 200 tokens with 30% overlap as a migration starting point, and Hierarchical where documents have real chapter and section structure. Treat both as hypotheses to test, not settings to copy. Chunk size is the single largest lever on retrieval quality, and the right value depends on your document shape rather than on a default. The same reasoning applies to vector store selection when you are not on a managed service, which we covered in our pgvector versus dedicated vector database comparison.
One operational detail worth putting in a runbook: CreateDataSource is asynchronous for managed knowledge bases. The status moves from CREATING to AVAILABLE, typically in two to five minutes, and starting ingestion before AVAILABLE fails.
A migration sequence that does not break production
Run both systems in parallel. That is the entire strategy, and the deadline does not change it, because existing Kendra indexes keep running with no published end-of-life date.
- Inventory first. List every index, data source, thesaurus file, enrichment hook and application call site. The six gap features are the ones you will forget, because nobody documents autocomplete.
- Build the knowledge base alongside Kendra. Create the IAM role that lets
bedrock.amazonaws.comreach your S3 buckets and invoke the embedding model, then create the knowledge base and data sources.
- Solve the connector gap before you migrate queries. Non-standard sources need their S3 extraction pipelines running and current, or your relevance comparison measures missing data rather than retrieval quality.
- Compare on a golden query set. Send identical queries to both and measure relevance with NDCG or MRR against a scored answer set, plus p50, p95 and p99 latency, throughput and the percentage of expected documents retrieved. AWS's suggested harness compares top-10 overlap between the two systems, which is a reasonable smoke test but not a relevance measurement.
- Rebuild the gap features against real usage. Instrument which of the six your users actually hit. Autocomplete and spell check usually matter; incremental learning often turns out to have been doing very little.
- Cut over per application, not per index. Move the lowest-risk internal application first and keep Kendra serving the rest.
Do not delete the Kendra index on cutover day. Provisioned capacity means it keeps billing, and a month of overlap at $1,008 for a Basic Enterprise base index is cheap next to an emergency rollback with no index to roll back to.
India-specific considerations
Region availability is the first check, not the last. Confirm that Bedrock Managed Knowledge Base and your chosen embedding model are available in the AWS region you serve from before you commit to a timeline, because a migration that has to cross regions changes the data residency answer you have already given your customers.
For teams handling personal data of Indian residents, the Digital Personal Data Protection Act 2023 engineering obligations make the document enrichment gap the one to plan around. Kendra's pre-extraction Lambda hooks were a defensible place to run PII redaction: one hook, on the ingestion path, easy to evidence. Replacing it with a Step Functions pipeline in front of S3 is workable, and the compliance burden shifts to proving the pipeline ran on every document, including backfills and re-ingestion after a failed job. Build that logging before migration rather than after, because reconstructing it retrospectively across an already-ingested corpus is significantly harder.
Access control deserves the same scrutiny. If your Kendra deployment relied on connector-level access control lists to keep departmental content separated, verify how those permissions survive the move to S3 sidecar metadata, and segment content into separate knowledge bases where the mapping is not exact.
Indian enterprises running Kendra alongside other managed AWS services should also read the 30 June announcement as a portfolio signal rather than a single-service notice. Teams that standardised on Kendra, Q Business and Bedrock Agents together are facing three migrations at once, and sequencing them matters more than starting any one of them quickly.
FAQ
How eCorpIT can help
eCorpIT builds and migrates retrieval systems on AWS for teams facing exactly this kind of forced platform move. Our senior engineering teams run the parallel comparison properly, with a scored query set and measured relevance rather than a top-10 overlap check, and we cost the connector gap before you commit to a date. Where the six missing features matter to your users, we build the replacements as maintainable services rather than migration-week patches. Talk to us about your Kendra migration and we will start with an inventory of what you would actually lose.
References
- AWS Service Availability Updates, 30 June 2026 - Amazon Web Services
- Amazon Kendra availability change - AWS Documentation
- Amazon Bedrock Agents Classic maintenance mode - AWS Documentation
- Amazon Q Business availability change - AWS Documentation
- Amazon Kendra pricing - Amazon Web Services
- New in Amazon Bedrock AgentCore: broader knowledge and continuous learning - AWS Machine Learning Blog, 17 June 2026
- Introducing Amazon Bedrock Managed Knowledge Base - AWS News Blog
- Amazon Bedrock Managed Knowledge Base is now generally available - Amazon Web Services
- Amazon Bedrock Knowledge Bases - Amazon Web Services
- AWS Product Lifecycle - AWS Documentation
- Amazon Bedrock AgentCore developer guide - AWS Documentation
Last updated: 21 July 2026.
