Kendra vs OpenSearch Cost: Migrating Off Kendra in 2026

If you run Amazon Kendra, you have probably already read the notice. AWS put Kendra into Maintenance Mode on June 30, 2026, and since July 30, 2026 the service is closed to new customers. Your index still works, AWS still ships security fixes, and nobody has set a shutdown date. But no new features are coming, and at some point somebody in the platform team gets asked the budget question: do we move to OpenSearch, and what will it cost?

This article answers that question with AWS's own published prices, and it answers the part most comparisons skip, which is what Kendra was doing for you that OpenSearch will not. We sell a managed workplace search product, so we have a view on where teams should land. We have tried to keep that to the last section and to be straight about where AWS options are the better fit.

Is Amazon Kendra being discontinued?

Not on any published date. Kendra is in Maintenance Mode, which AWS defines as "fully supported" with "bug fixes and security updates for existing customers", but "new feature requests will no longer be considered." The Kendra availability page gives two dates: Maintenance Mode "effective June 30, 2026", and "as of July 30, 2026, the service is no longer open to new customers." It does not give an end-of-support date, and we could not find one anywhere in AWS documentation.

That matters for planning. You are not facing a forced migration next quarter, so there is time to do this properly. You are, however, running a service that will not gain anything new while every alternative keeps shipping, and every Kendra doc page now carries a banner pointing new customers to Amazon Bedrock Knowledge Bases. Treat it as a migration with a flexible deadline, not an emergency.

Does AWS recommend OpenSearch as the Kendra replacement?

No. AWS's recommendation, in its own words, is to "migrate their Kendra applications and implement any new search applications on Amazon Bedrock Managed Knowledge Base (BMKB)." OpenSearch appears in the Kendra migration guidance only as a workaround: for autocomplete, AWS suggests you "implement a custom autocomplete layer using Amazon OpenSearch Service with its built-in suggester functionality", because BMKB does not have Kendra's query suggestions.

So the honest framing is three options, not two. You can stay on Kendra while it is supported, move to BMKB as AWS suggests, or build on OpenSearch yourself. Most "Kendra vs OpenSearch" comparisons online predate the Maintenance Mode notice and treat the two as peers. In 2026 they are not: one is the managed product you already have, and the other is the engine you would build a replacement on.

What does Kendra cost compared with OpenSearch?

On infrastructure alone, OpenSearch's floor is lower. A classic Serverless collection bills at least 2 OCUs at $0.24 per OCU-hour, roughly $350 a month, and half that in dev-test mode. Kendra GenAI Enterprise starts at $0.32 an hour for the base index, and Basic Enterprise at $1.40 an hour. Both then grow with volume, and Kendra adds a per-index connector fee. The table uses AWS's published us-east-1 rates.

The monthly floors for OpenSearch are our arithmetic from AWS's hourly rates, using about 730 hours a month. The Kendra and BMKB figures in bold are AWS's own worked examples. One billing detail on the Kendra side is easy to miss: "you are charged for storage unit and query unit hours from the time an index is created until it is deleted", so an index nobody queries still bills in full.

If the comparison stopped here, OpenSearch would win clearly. A team paying about $2,000 a month for a 200,000 document GenAI index could run the same corpus on Serverless for a fraction of that. The reason most teams do not see that saving in practice is the next section.

Does OpenSearch have connectors like Kendra?

Mostly no. AWS counts "32 native connectors" for Kendra, including SharePoint, Google Drive, OneDrive, Box, Salesforce, ServiceNow, Slack, Gmail, Jira and Confluence. OpenSearch Ingestion's documented sources are DocumentDB, DynamoDB, HTTP, Kafka, Kinesis, OpenSearch, OpenTelemetry and S3, plus an Atlassian plugin for Jira and Confluence. There is nothing native for SharePoint, Salesforce, Google Drive, Slack or OneDrive.

The Atlassian plugin is worth reading carefully before you rely on it. AWS documents a limitation in plain terms: "User delete actions won't be synced. Data once recorded in the sink will remain in the sink." For a search index that means a page someone deleted in Confluence can keep appearing in results until you build your own cleanup.

You will also see OpenSearch "ML connectors" mentioned in migration threads. Those connect OpenSearch to embedding and model providers such as Cohere. They are model connectors, not data connectors, and they do not pull content out of your business apps.

The practical path for every other source is the one AWS itself suggests for BMKB gaps: export the content to S3 and index it from there. That works, and it is also a pipeline your team now owns, schedules and monitors. If those exports arrive as messy spreadsheets from several systems, it pays to dedupe and normalize the exported CSV files before they reach the index, because duplicate records turn into duplicate search results.

Does OpenSearch respect document permissions like Kendra?

OpenSearch can restrict documents, but it does not import permissions from your source systems. Its document-level security works by role: "When creating a role, specify an index pattern and an OpenSearch query." Kendra works the other way round. AWS states that when a document is indexed, "a corresponding access control list (ACL) is ingested for most documents", and Kendra "can extract the user or group information associated with each document for most data sources."

In practice, this is the largest hidden cost of the move. With Kendra, a SharePoint file restricted to the finance group stays restricted in search, because the connector brought the ACL along. With OpenSearch, you have to fetch those ACLs yourself, store them on each document, map them to your identity provider's groups, keep them current as people change teams, and filter every query. Getting that slightly wrong is how an internal search tool shows a salary spreadsheet to the wrong person.

BMKB does sync ACLs, at least for SharePoint, and "verifies each user's permissions at query time". AWS adds two cautions on the same page that belong in any security review: BMKB "provides ACL-aware filtering, not a security boundary", and "ACL configuration is permanent." We explain why query-time permission checks matter in more detail on permission-aware AI search.

What changes on September 30, 2026?

From September 30, 2026, AWS stops allowing new Confluence, SharePoint, Salesforce and Web Crawler connectors on customer-managed Bedrock knowledge bases. The documentation reads: "Starting September 30, 2026, the creation of new connectors for Confluence, Microsoft SharePoint, Salesforce, and Web Crawler will no longer be supported on customer-managed knowledge bases. Existing connectors of these types will continue to function."

This affects a common middle path, where a team builds a Bedrock knowledge base on an OpenSearch Serverless vector collection and uses Bedrock's connectors to fill it. After that date, new SaaS connectors on that setup are gone, and the managed BMKB is the only Bedrock option that keeps them. Salesforce is not among BMKB's seven connectors at all, so a Kendra index that leans on Salesforce content has no AWS-managed destination for it. We walked through the BMKB side of this migration in Bedrock Knowledge Base vs Kendra.

Is Kendra vs Elasticsearch any different?

The engine story is the same, and the connector story is worse than it used to be. Elastic retired Workplace Search, the product that gave Elasticsearch its SaaS content connectors, and removed it in version 9.0. The packaged workplace search experience that competed with Kendra is gone from current versions, and Elastic lists end of maintenance on January 15, 2027 for deployments that still run it. The costs and remaining options are on Elastic Enterprise Search pricing, and Coveo vs Elasticsearch cost covers the managed commercial alternative.

If your organization already runs Elastic Cloud for logging, adding a search index there can make sense. Budget for the same work as with OpenSearch: connectors, permission sync and the relevance tuning Kendra did out of the box.

What does the migration really cost?

Infrastructure is the small number. The large one is rebuilding what Kendra bundled: connectors for each source, permission sync, chunking and embeddings, query suggestions, synonyms and spell checking. AWS lists "Query Suggestions, Faceted Search, Custom Synonyms, Spell Checking, Incremental Learning, and Document Enrichment" as features that "require workarounds" even on BMKB. On OpenSearch you own every one of them.

A reasonable way to size it is to list the sources your Kendra index actually uses, then sort them into three groups: sources OpenSearch Ingestion reads natively (S3, DynamoDB and similar AWS stores), sources with a documented plugin (Jira and Confluence, with the delete caveat), and everything else, which needs a custom export job and an ACL mapping. The third group is usually where Kendra was earning its fee. If it holds SharePoint, Google Drive and Salesforce, you are looking at three integrations to build and keep running for as long as the index exists.

Which should you choose?

The last row is where we fit, so here is the honest version. InSearch connects to your business apps, keeps each source's permissions, and answers employee questions with citations, which covers the use case many companies bought Kendra for. It is priced per person, $20 per seat per month on the Team plan billed annually, which you can check on our pricing page. For 200 employees that is $48,000 a year, which is more than the $23,774 a year implied by AWS's 200,000 document Kendra example. It is also a lot less than the engineering time to build and maintain three SaaS connectors and an ACL sync on OpenSearch. If your index serves an application rather than employees, OpenSearch or BMKB is the better answer, and we would say so.

For the wider picture of where Kendra customers are landing, see Amazon Kendra alternatives and our earlier breakdown of what Kendra Maintenance Mode means for migration cost.