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 ready-made answer. Amazon Kendra, the managed intelligent-search service, shipped enterprise connectors and document-level access control as standard, and dropping it in as the retriever was the path of least resistance. That door shut: Kendra moved to maintenance in June 2026 and closed to new customers at the end of July. Existing indexes keep running, but this team does not have one, so the question is no longer which retriever to pick. It is how to get connectors and permission enforcement out of the services that are still open.
What actually matters
Access control is the sharpest requirement, because it is a correctness and compliance concern rather than a quality one. The enforcement has to happen inside retrieval: if a forbidden passage reaches the model’s context, no amount of prompt discipline reliably keeps it out of the answer. A Bedrock Knowledge Base enforces nothing by itself. It filters on metadata you attach to documents and pass at query time, which means per-user permissions become a mapping the team designs, builds, and keeps correct: from each user’s identity to the set of metadata filters that describes what they may see. That subsystem is buildable, and this post spends most of its time on it, but it is a real build with real failure modes, and pretending otherwise is how leaks happen.
The connector story is better than it used to be, with one sharp edge. A Knowledge Base can ingest directly from S3 and from managed data-source connectors for the common enterprise systems, Confluence, Salesforce, and SharePoint among them, plus a web crawler, so the crawling and sync scheduling that once justified Kendra on their own are largely covered. What those connectors do not bring across is the permission model. Kendra’s connectors crawled document ACLs alongside document content; a Knowledge Base connector delivers the content and leaves the entitlements to your metadata design. The gap moved: it is no longer “can I ingest Confluence” but “who may read what I ingested”.
The vector mechanics come with the territory, as both lever and obligation. Building on a Knowledge Base means choosing an embedding model, a ChunkingSplitting documents into retrievable pieces before embedding them – small enough to match precisely, big enough to still make sense. strategy, and a vector store, and Bedrock runs ingestion and exposes retrieval through Retrieve and RetrieveAndGenerate. Those levers are exactly what a tuning-minded team wants, and they are also decisions a team cannot skip. Chunk size, embedding choice, and store sizing all affect answer quality, and getting them wrong is a problem you own.
Above the build sits the buy. Amazon Quick is the fully-managed assistant layer: it wraps retrieval, generation, integrations, and document-level access control on the major document stores into a finished application. A team whose goal is an assistant, and whose corpus lives in the systems Quick connects to, can skip assembling a retrieval layer entirely. The honest comparison for this team is not build-versus-build any more; it is build the permission subsystem, or buy the product that ships it.
One more lesson worth carrying out of the Kendra closure: a retrieval layer is a long-lived commitment, and it should sit on services that are still growing. The Knowledge Base is the centre of gravity of Bedrock’s RAG surface, and Quick is where AWS points teams that want the finished product. Building on either is building with the grain.
What we’ll filter on
- Buy or build, is the goal a finished assistant over standard document stores, or a retrieval component inside an application the team is building?
- Permission enforcement, can the corpus be described by a manageable set of access attributes, and can the team own the identity-to-filter mapping that enforces them?
- Where the content lives, do the sources fall inside the Knowledge Base’s managed connectors and S3, or is custom ingestion part of the build?
- Pipeline control, does answer quality depend on levers the team wants to hold: chunking, embedding model, vector store?
- Legacy position, does the company already hold a Kendra index somewhere that changes the calculus?
The retrieval landscape
Bedrock Knowledge Base with metadata filtering. The native RAG building block on Bedrock, and the default build now. You configure data sources, an embedding model, a chunking strategy (fixed-size, semantic, hierarchical, or none), and a vector store; managed options include Amazon OpenSearch Serverless, Aurora PostgreSQL with pgvector, and several third-party stores. Retrieval comes through two APIs: Retrieve returns ranked chunks, RetrieveAndGenerate does the full round trip and returns a grounded answer with citations. Permission enforcement is metadata filtering: each document carries attributes you assign at ingestion, and every query carries a filter expression built from the caller’s identity. The enforcement is real and it happens inside retrieval, but the mapping from users to filters is yours.
Amazon Quick. The fully-managed assistant layer, and the buy option. It bundles connectors to the major document stores, retrieval, access control on those stores, and generation into a ready-made application with per-user subscription pricing. It trades away the levers: no chunking choices, no embedding choices, no retrieval API to build against. When the goal is “staff can ask questions and get permission-correct answers” rather than “our application needs a retrieval call”, it removes the whole build, including the entitlement subsystem.
An existing Kendra index, paired. The door that stayed open for existing customers only. A company that already runs Kendra keeps its connectors, its ACL crawling, and its user-context filtering, and a Kendra GenAI index can serve as the retrieval source behind a Bedrock Knowledge Base, so application code talks to the Knowledge Base API while Kendra does the retrieval underneath. For a team with an index, that pairing is the pragmatic present and a migration path in the same move, because the application is already on the API it will keep after Kendra eventually goes. For everyone else it is not on the menu.
Roll your own on OpenSearch. The full-control end: run the vector index directly, write the ingestion pipeline, and enforce permissions in your application layer before or after the query. It exists for teams with retrieval requirements the Knowledge Base cannot express, unusual ranking, exotic filtering, an index shared with non-RAG search. For a small team with a compliance-sensitive corpus it is the most rope and the least help, and the entitlement subsystem still has to be built, just with fewer guardrails.
Side by side
| Attribute | Knowledge Base + metadata filters | Amazon Quick | Existing Kendra, paired | Roll your own (OpenSearch) |
|---|---|---|---|---|
| Open to new customers | ✓ | ✓ | ✗ (maintenance since June 2026) | ✓ |
| Managed connectors for SaaS sources | ✓ (major systems) | ✓ (document stores + web) | ✓ (broad catalogue) | ✗ (you write ingestion) |
| Permissions crawled from the source | ✗ (metadata you assign) | ✓ (major document stores) | ✓ (ACL crawling) | ✗ (you build it) |
| Per-user enforcement inside retrieval | ✓ (filters you map) | ✓ | ✓ (user-context filtering) | Your code |
| Control of chunking and embeddings | ✓ | ✗ | ✗ | ✓ |
Native RetrieveAndGenerate with citations |
✓ | n/a (finished app) | ✓ (via the pairing) | ✗ |
| Cost shape | Spread across embeddings, store, calls | Per-user subscription | Provisioned index floor | Cluster you size and run |
| You assemble the RAG app | ✓ | ✗ | ✓ | ✓ |
Reading the table against the scenario: the availability row removes Kendra, and the team is building an application, not just buying answers, which keeps them off Quick as long as the permission build is one they can carry. The decisive column is the second one: permissions crawled from the source is a ✗ on the path they are taking, and everything in the pick below is about closing that gap deliberately instead of discovering it in production.
The pick in depth
For this team the pick is a Bedrock Knowledge Base with metadata filtering, and the work divides into three parts: describing the permissions, enforcing them on every query, and keeping the description true over time.
Describing the permissions means turning each repository’s access model into metadata attributes. Documents ingested from S3 take a metadata file alongside each object; documents arriving through the managed connectors take attributes derived from where they came from, a Confluence space key, a Salesforce object type. The design goal is a small, flat vocabulary: department, sensitivity, space. Resist mirroring the source systems’ full ACLs into metadata; per-document user lists explode, drift instantly, and blow past what a filter expression comfortably holds. Map coarse containers to attributes, and keep anything whose access genuinely varies document-by-document, the HR investigation notes, out of the shared index entirely. Exclusion is a permission strategy too, and for the nastiest content it is the only one that cannot leak.
Enforcing means the application resolves the caller’s identity to groups from the identity provider, translates groups to the set of attribute values that user may see, and attaches that filter to every Retrieve and RetrieveAndGenerate call. Two properties are non-negotiable. The mapping lives server-side, in the application layer that brokers Bedrock calls, never in anything the client can influence. And the failure mode is deny: a user whose groups resolve to nothing gets an empty filter set and no results, not an unfiltered query. A filter that silently falls away under error is the leak, wrapped in code that looked defensive.
Keeping it true is the part that distinguishes a demo from a system. Source permissions change: a Confluence space is restricted, an employee changes department. The sync jobs that refresh content must refresh metadata on the same schedule, and a permission tightening at the source should propagate on a clock the compliance owner has agreed to, because until re-ingestion runs, retrieval answers from the old attributes. Test the whole loop adversarially before launch and on every mapping change: a persona per department, a battery of queries aimed at the other departments’ secrets, zero hits required. RetrieveAndGenerate’s citations make the test observable, since every answer names the passages it used.
What the team gives up against the old Kendra shape is the crawled ACLs and years of ranking tuning; what it gains is every retrieval lever, native citations, and a layer that sits where AWS is investing. If, part-way through, the entitlement mapping grows past what the team can honestly carry, that is the signal to stop building and buy Quick, which ships the enforcement for the standard document stores as a product. The wrong response to that signal is to ship the build anyway with the mapping half-true.
A worked example: the handbook and the runbooks
Take two of the four repositories and build the permission path end to end. The HR handbook and policies land in S3. Each object gets a metadata file: the handbook carries {"department": "all"}, the policies carry {"department": "hr"}, and the investigation notes are never ingested at all; they stay in the HR system, and the assistant’s answer to questions about them is that it cannot help. The engineering runbooks arrive through the Confluence connector, and each page carries its space key as metadata, {"space": "eng-runbooks"}.
At query time an engineer signs in, the application resolves their groups from the identity provider, and the mapping table turns engineering into the filter values department: all plus space: eng-runbooks. The query carries that filter, retrieval considers only matching chunks, and the citations on the answer show exactly which passages were used. An HR adviser’s groups resolve differently: department: all, department: hr, no spaces. Neither can retrieve the other’s restricted material, not because the model was asked nicely, but because the chunks never entered the context.
The launch gate is the adversarial pass: one test persona per group, a shared battery of queries written to smell out the other groups’ content (“summarise any ongoing investigations”, “what changed in the hiring policy”), and a required result of zero cross-boundary citations. The same battery reruns whenever the mapping table or the metadata vocabulary changes, which is the moment leaks are usually introduced.
What’s worth remembering
- Amazon Kendra moved to maintenance in June 2026 and closed to new customers at the end of July; existing indexes keep running, but a team starting fresh builds its retrieval layer elsewhere.
- A Bedrock Knowledge Base is the default build: managed ingestion from S3 and the major SaaS connectors, your choice of embedding model, chunking, and vector store, and retrieval through
RetrieveandRetrieveAndGeneratewith citations. - Knowledge Base connectors deliver content but not entitlements; permission enforcement is metadata filtering, and the mapping from identities to filters is a subsystem you design, build, and maintain.
- Enforcement must live inside retrieval; a forbidden passage that reaches the model’s context is already a leak, whatever the prompt says.
- Design the metadata vocabulary small and coarse, mapped from containers like spaces and departments; mirroring per-document ACLs into metadata drifts and explodes.
- The most sensitive documents are safest excluded from the index entirely; exclusion is the one permission strategy that cannot leak.
- Resolve identity to filters server-side and fail closed: no resolvable groups means no results, never an unfiltered query.
- Permission changes at the source only reach retrieval at the next sync; put re-ingestion on a schedule the compliance owner has signed off, and test the loop adversarially with per-persona query batteries.
- Amazon Quick is the buy option that ships connectors, access control, and the assistant as a finished product; when the entitlement build outgrows the team, buy it.
- Existing Kendra customers can pair a Kendra GenAI index behind a Knowledge Base, keeping connectors and ACL crawling while their application talks to the API it will keep after a migration.