Choosing Between Kendra and a Bedrock Knowledge Base

The situation

A knowledge team wants an internal assistant that answers staff questions from company documents: an HR handbook and policies in S3, engineering runbooks in Confluence, deal notes in Salesforce, and a pile of PDFs on a shared drive. The generation side is settled; a Claude model on Amazon Bedrock will write the answers. What is not settled is the retrieval layer that finds the right passages to feed it.

Two constraints shape the whole build. The document set spans four repositories, each with its own permissions, and the assistant must never surface a passage a given employee is not allowed to read, so an HR investigation note cannot leak into an engineer’s answer. And the team is small, with no appetite to run and tune a vector database by hand if they can avoid it.

A year ago this scenario had a clean answer, and the answer was Amazon Kendra. It brought a large catalogue of enterprise connectors and enforced document-level permissions inside retrieval, which is exactly the two constraints. That answer expired. AWS put Kendra into maintenance mode on 30 June 2026, and on 30 July the service closed to new customers. Existing indexes keep running, and AWS continues to ship bug fixes and security updates for them, but there is no new feature development and no way for this team to create an index at all. AWS’s own guidance is to build new search applications on a Bedrock Knowledge Base.

So there are two live questions now. For a team standing this up today, what carries those two constraints once Kendra is off the table. For a team already running Kendra, what a migration actually costs and how urgent it is.

What actually matters

Both paths end in the same place: a set of relevant passages handed to the model, and an answer generated from them. The difference is everything upstream of that handoff, and the useful way to read Kendra’s exit is to go through what it was doing item by item and check which parts moved onto the team and which the replacement kept.

Kendra was carrying two things worth naming. The first is connector coverage. Kendra crawled and synced more than thirty enterprise sources, and on the ones that supported it, brought the source permissions along with the content. A Bedrock Knowledge Base in its managed form supports seven: S3, Confluence, SharePoint, Google Drive, OneDrive, a web crawler, and a custom connector. Salesforce is not on that list, and neither is a random file server, so anything outside the seven arrives through S3 by way of an export pipeline the team writes and operates.

The second is document-level access control, and this is where the obvious guess is wrong. Kendra filtered on user and group context at query time, so entitlement was enforced inside retrieval rather than by the application. A managed knowledge base does the same job: its connectors ingest the source permissions alongside the content, Retrieve accepts a userContext carrying the caller’s userId, and results come back filtered to what that person is allowed to read. It goes further than Kendra in one respect, checking permissions against the authoritative source at query time on top of the pre-retrieval filtering, so a permission revoked this morning is honoured on the next query instead of at the next crawl. Web Crawler is the exception, because a public URL has no authenticated identity to map to, and anything crawled is readable by everyone with access to the knowledge base.

The catch is that userContext is optional. Leave it off and retrieval runs unfiltered and hands back a perfectly reasonable answer, so the failure looks exactly like success. Exposed through AgentCore, the IAM identity is not passed along as the document-level user either, so the application has to send it explicitly. That is a much smaller job than building an entitlement subsystem, and a much easier one to get wrong without anyone noticing.

What comes back in exchange is control and a native generation path. A Bedrock Knowledge Base lets you choose the embedding model and the chunkingChunkingSplitting documents into retrievable pieces before embedding them – small enough to match precisely, big enough to still make sense. strategy, exposes Retrieve and RetrieveAndGenerate with citations as first-class APIs, and now comes in two shapes: a managed knowledge base where Bedrock runs the vector store as well, and a vector knowledge base where you point it at a store you own. The managed shape is the one that suits a small team with no appetite for operating OpenSearch or Aurora, and it is what AWS points migrating Kendra customers at.

Maintenance mode is worth reading precisely, because it is not a shutdown notice. There is no announced end-of-support date, and an existing index will keep answering queries. The risk it creates is drift: a service that stops gaining features while the rest of the retrieval space keeps moving, sitting under an application that cannot be rebuilt on it if the account ever loses access. That makes migration a planning problem with a long fuse, not an incident. It is the same shape as a model reaching end of life on Bedrock, one layer down the stack.

What we’ll filter on

1. Availability, can a team create the service today at all, or is it closed to new customers?
2. Connector coverage, how much of the content is reachable through a managed connector rather than an export pipeline you write?
3. Document-level access control, does retrieval enforce per-user entitlement itself, and does that cover the sources this content actually lives in?
4. Pipeline control, does the team want to choose the embedding model, chunking, and vector store, or would it rather those be decided for it?
5. Cost shape, does the usage pattern suit a provisioned index with an hourly floor, or a bill that tracks corpus size and query volume?
6. Migration cost, for a team already on Kendra, how much of the application has to be rewritten?

The retriever landscape

Bedrock managed knowledge base. The path AWS points migrating Kendra customers at, created with CreateKnowledgeBase and a type of MANAGED. Bedrock runs the whole pipeline including the vector store, so there is no OpenSearch collection or Aurora cluster to provision, size, or patch. You pick an embedding model from a fixed set (Titan Text Embeddings V2, Cohere Embed English v3, Cohere Embed Multilingual v3, Cohere Embed v4, Amazon Nova Multimodal Embeddings), all at 1,024 dimensions with float32 vectors, and a chunking strategy from default, fixed-size, hierarchical, or none. Retrieval is always hybridHybrid searchRunning a keyword match alongside a vector search and fusing the two rankings, so exact identifiers survive that meaning-based search would blur away. , combining keyword and semantic matching, with no semantic-only mode. Ingestion runs smart parsing over the documents. On top of Retrieve and RetrieveAndGenerate there is an agentic retrieval API that does multi-step reasoning across several knowledge bases. Seven native connectors, and metadata arrives as .metadata.json sidecar files next to the documents in S3, capped at 10 KB each, with attributes typed string, number, or boolean. Document-level access control is built in: the connectors ingest source permissions, and passing a userContext on the retrieval call filters results to that user, with a real-time check against the source layered on top of the pre-retrieval filtering. Web Crawler is the one connector outside it.

Bedrock knowledge base with a vector store you choose. The older shape, and still the one that gives you the most levers. You configure a data source, an embedding model, a chunking strategy including semantic chunking, and a vector store to hold the embeddings, with managed options spanning Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, S3 Vectors, and third-party stores such as Pinecone. Same Retrieve and RetrieveAndGenerate surface. The cost is that the store is now something you size and operate, which is the thing the small team in this scenario was trying to avoid. Picking between the stores is its own decision.

Amazon Kendra, for teams that already have it. A managed intelligent-search service with 32-plus connectors, mature relevance ranking, and token-based user-context filtering that enforces document-level access control at query time. In maintenance mode since 30 June 2026 and closed to new customers since 30 July, so this is only on the table for an account that already runs an index. Existing indexes are fully supported and keep receiving bug fixes and security updates, with no end-of-support date announced.

A Kendra GenAI index behind a Bedrock knowledge base. A Kendra GenAI index can serve as the retrieval source for a Bedrock knowledge base, which lets an existing Kendra customer keep the connectors and access control while driving retrieval through the Bedrock API and RetrieveAndGenerate. It was the interesting middle ground when both services were open, and it is now a useful staging post during a migration rather than a destination, because the Kendra half still sits in maintenance mode.

Amazon Quick above all of them. The fully-managed assistant layer. It bundles integrations, retrieval, access control, and generation into a ready-made application, so a team whose goal is an internal assistant rather than a retrieval component can reach for Quick and skip assembling the layer underneath. It trades build-time control for a finished product, and with Kendra’s connectors and entitlement filtering gone from the menu it is a more serious option for this scenario than it used to be.

Side by side

Reading the table against the scenario: of the two columns that used to decide this, only one moved. Document-level access control survived, and survived in better shape, so the compliance-shaped requirement is still handled inside retrieval rather than by the application. Managed connectors did not survive, and that is where the work lands: four repositories, two of them covered natively, and the rest arriving through S3 on a pipeline the team writes and operates.

The picks in depth

For a new build, a managed knowledge base is the fit, and the reason is the constraint the team stated rather than the one they didn’t. They have no appetite for operating a vector database, and the managed shape removes that entirely: no collection to size, no OCU floor to reason about, no index tuning. The generation path is native, so RetrieveAndGenerate returns a grounded answer with citations without a separate orchestration step. What they give up against a vector knowledge base is semantic chunking, embedding dimensions other than 1,024, and a semantic-only search mode, and none of those are load-bearing for an internal document assistant.

The access-control requirement, which looks like the hard part, is mostly handled for you. The connectors bring the source permissions in with the content, the application passes the caller’s identifier as userContext on every retrieval call, and Bedrock returns only what that person can read, re-checking against the source as it goes. That is closer to what Kendra did than a reading of the migration guide’s feature-gap section suggests, and better in one respect: Kendra’s permissions were crawled into the index and drifted between syncs, while a real-time check means a revocation lands on the next query.

What is left is making sure the call is never made without it, because userContext is optional and a query without it returns unfiltered results and a plausible answer. That belongs in a single server-side retrieval wrapper that resolves the authenticated caller and refuses to issue a query without one, rather than scattered across call sites, and it wants a test that asserts a document the caller should not see does not come back. The related trap is Web Crawler, which has no document-level access control at all, so crawled content is readable by anyone with access to the knowledge base and has no business sharing one with restricted material. The hard boundary is the same one worked through in a citations-required RAG over an access-controlled corpus: identity is resolved server-side, and nothing in the request path lets a caller name themselves as somebody else.

Metadata filters are still worth understanding, they are just not carrying entitlement any more. They do the ordinary narrowing by department, document type, or date range, and two constraints shape them. Managed knowledge bases have no startsWith or stringContains, so prefix or substring matching over a path or a classification string has to be restructured into exact-match or set-membership attributes. And sidecars are capped at 10 KB with attributes typed string, number, or boolean.

The connector gap is where the real scoped work is, and it is worth taking seriously precisely because the access-control work turned out smaller than expected. S3 and Confluence are covered natively. Salesforce is not, so the deal notes need a scheduled export: something on EventBridge Scheduler driving a Lambda or Step Functions workflow that pulls from the Salesforce API, writes documents to S3, and starts an ingestion job. That reproduces the periodic sync a Kendra connector did for free, and it is now code the team owns, monitors, and fixes when the source API changes. Whether the shared-drive PDFs need the same treatment depends on where they actually live; on SharePoint, OneDrive, or Google Drive there is a native connector, and on a file server there is not.

Exported content is also where the entitlement story gets thinner. S3 is among the connectors that enforce document-level access control, so material landing there can still be permission-filtered, but the pipeline has to translate the source system’s sharing rules into what the S3 side expects and keep them current. That translation used to be the connector’s job. For anything with sharing rules as involved as Salesforce’s, it is worth deciding early whether the export carries entitlement at all or whether that content belongs in a separate knowledge base with a coarser boundary.

A vector knowledge base is the better answer when retrieval quality depends on a lever the managed shape does not expose: a specific embedding model or dimension count, semantic chunking, or a vector store the team already runs and already has the ops muscle for. Amazon Quick is the better answer when what the business actually wants is the assistant rather than the retrieval component, and the gap has narrowed less than Kendra’s exit first suggests, because the retrieval layer underneath still handles entitlement on its own.

For a team already running Kendra, the sequencing matters more than the destination. There is no forced date, the index keeps working, and a rushed migration that gets entitlement wrong is far worse than a planned one. Scope it by finding what has no direct equivalent: faceted search, query suggestions from GetQuerySuggestions, custom synonyms from a thesaurus file, spell correction, relevance feedback through SubmitFeedback, and the pre- and post-extraction Lambda hooks used for document enrichment. Each has a workaround, and each workaround is a component the team then runs. Enrichment hooks become a preprocessing pipeline that transforms documents on the way into S3. Synonyms become query expansion in front of the retrieval call, which works reasonably well because the search is always hybrid and the added terms match on both dimensions. Facets become metadata filters driven by a schema the application already knows, without the dynamic counts. Run both retrievers side by side against a golden query set and compare result overlap before moving any traffic.

Cost is the last thing to check rather than the first. Kendra billed largely on a provisioned index with an hourly floor whether or not anyone queried it, which made a lightly used assistant over a small corpus look expensive per question. A managed knowledge base bills on the size of the corpus ingested, the number of queries, and the model usage for generation, so the floor mostly goes away and the bill tracks activity. For a small internal assistant that is a favourable trade, and it partly offsets the connector and entitlement work that moved onto the team.

A worked example: the same corpus, built now

Take the four sources and walk them onto a managed knowledge base, because that is where the work actually shows up.

The HR handbook and policies in S3 connect through the native S3 connector, with .metadata.json sidecars carrying the ordinary filtering attributes: department, document type, review date. The engineering runbooks in Confluence connect through the native Confluence connector, which brings the space and page permissions in with the pages. The Salesforce deal notes have no native connector, so they need an export: EventBridge Scheduler triggers a Lambda on a schedule, the Lambda pulls records through the Salesforce API, writes them to S3 as documents, and starts an ingestion job. The shared-drive PDFs go the same way unless they live somewhere with a connector, in which case they do not.

Then the part that looked like a rebuild and mostly is not. At query time the application resolves the authenticated caller server-side and passes their identifier as userContext on the retrieval call, and Bedrock returns only the documents that person can read, checking against the source as it goes. Nothing in the request path lets a caller name themselves as someone else. When an engineer is removed from an HR space in Confluence, the next query reflects it, rather than waiting on a crawl or a sidecar rewrite. The exported Salesforce content is the piece that needs its own answer, because its entitlement is only ever as current as the pipeline that last wrote it.

For a team migrating rather than building fresh, the application-side change is mostly a call translation. The Kendra version:

kendra = boto3.client("kendra")

response = kendra.retrieve(
    IndexId="your-kendra-index-id",
    QueryText="What is the parental leave policy?",
    AttributeFilter={
        "EqualsTo": {
            "Key": "_category",
            "Value": {"StringValue": "hr-policy"},
        }
    },
    PageSize=10,
)

And the managed knowledge base version:

bedrock = boto3.client("bedrock-agent-runtime")

response = bedrock.retrieve(
    knowledgeBaseId="your-kb-id",
    retrievalQuery={"text": "What is the parental leave policy?"},
    retrievalConfiguration={
        "managedSearchConfiguration": {
            "numberOfResults": 10,
            "filter": {"equals": {"key": "category", "value": "hr-policy"}},
        }
    },
)

The query text moves into a nested retrievalQuery.text, AttributeFilter becomes filter inside managedSearchConfiguration, the operator names lower-case, and results come back with a relevance score and a source location. Kendra’s user-context token becomes a top-level userContext on the same call. That part is an afternoon. The export pipelines for sources with no connector are the actual migration.

Same corpus, same model, same finished answer. What changed is that the connector catalogue is now a component with an owner and needs to be in the estimate. The permission enforcement, which is the part everyone expects to be the expensive one, largely came along for the ride.

What’s worth remembering

1. Amazon Kendra went into maintenance mode on 30 June 2026 and closed to new customers on 30 July 2026, so a new build cannot pick it. Existing indexes keep running with bug fixes and security updates, and no end-of-support date has been announced.
2. AWS’s guidance for both new search applications and Kendra migrations is a Bedrock managed knowledge base, created with CreateKnowledgeBase and a type of MANAGED.
3. A managed knowledge base runs the vector store for you, fixes embeddings at 1,024 dimensions across five models, offers default, fixed-size, hierarchical, and no-chunking strategies, and always searches hybrid. A vector knowledge base points at a store you choose and operate, and keeps more levers including semantic chunking.
4. The connector gap is the real cost of Kendra’s exit: 32-plus native connectors down to seven. Anything outside them arrives through S3 by way of a scheduled export pipeline you write and operate.
5. Document-level access control survived the move. A managed knowledge base ingests source permissions through its connectors and filters retrieval by the userContext you pass, so entitlement is still enforced inside retrieval rather than by the application.
6. It is fresher than Kendra’s was, too. Permissions are checked against the authoritative source at query time on top of the pre-retrieval filtering, so a revocation lands on the next query instead of at the next crawl.
7. userContext is optional, and a query without it returns unfiltered results and a plausible answer. Put the caller resolution in one server-side wrapper that refuses to query without a user, and note that through AgentCore the IAM identity is not passed through as the document-level user.
8. Web Crawler has no document-level access control, so crawled content is readable by everyone with access to the knowledge base and should not share one with restricted material.
9. Features with no direct equivalent are faceted search, query suggestions, custom synonyms, spell correction, relevance feedback through SubmitFeedback, and the document-enrichment Lambda hooks. Each has a workaround, and each workaround is a component you then run.
10. Maintenance mode is not a shutdown notice, so migration is a planning problem rather than an incident. Run both retrievers against a golden query set and compare before moving traffic.