The situation
A mid-sized enterprise wants an internal assistant that answers staff questions from company knowledge. HR policies sit in SharePoint. Deal notes are in Google Drive, engineering docs in Confluence, and a pile of PDFs and spreadsheets in Amazon S3. The ask sounds simple, but two constraints make it real. Answers have to respect who is asking, so a support agent never sees the compensation spreadsheet just because it contains the phrase they searched for. And leadership wants something staff can use in weeks, not a quarter-long build.
The team has two shapes of solution in front of them. One is Amazon Quick, the managed AI assistant that grew out of Amazon QuickSight. It connects to those data sources through built-in integrations, indexes and retrieves the content, and signs staff in through IAM Identity Center or IAM Federation. The other is a custom retrieval application on Amazon Bedrock Knowledge Bases, where the team owns the ChunkingSplitting documents into retrievable pieces before embedding them – small enough to match precisely, big enough to still make sense., the embeddings, the vector store, the model, the prompts, and the front end.
The instinct is to reach for the custom build, because that is the interesting engineering. The choice underneath is narrower. Is the requirement standard enough that the managed product already does the hard part?
What actually matters
Both options do retrieval-augmented generation. Both chunk documents, embed them, store the vectors, retrieve passages at query time, and hand those passages to a model to ground the answer. The difference is which layers the team builds and operates, and which ones arrive already working.
Start with identity, because it used to settle this decision on its own and no longer does. Quick authenticates staff itself, through IAM Identity Center or IAM Federation. It then enforces access at several layers: permissions in the source system, permissions on the integration, permissions on the knowledge base, and a per-document check when a user queries. AWS describes the knowledge-base layer as coarse-grained access control, so the fine filtering rests on that per-document check.
Bedrock has closed most of the gap. A Bedrock Managed Knowledge Base supports ACL-aware retrieval. At ingestion it crawls allowed and denied users and groups alongside the content, and at query time it returns only the documents the supplied user is permitted to see. For SharePoint, OneDrive, Google Drive and Confluence it also calls the source system in real time, catching permission changes made since the last sync. Deny overrides allow, and the pipeline fails closed on any error. S3 and custom sources use an ACL configuration file you write, with no real-time verification. Web Crawler has no ACL support at all.
The catch is the distinction AWS draws carefully. ACL awareness is filtering, not authorization. Bedrock authenticates nobody; your application does that and passes a verified identity context. Matching is on email, exactly as spelled in every connected source, with no alias resolution across identity providers. If an email address is reassigned after someone leaves, you have to catch it before the query. So identity is no longer a build-it-all-yourself axis. It is a question of whether you want to own the sign-in and the identity context.
Data-source coverage has moved too. Quick offers six integrations: S3, SharePoint, OneDrive, Google Drive, Confluence, and a web crawler. A Bedrock Managed Knowledge Base offers the same six plus a custom source. A Customer-managed Knowledge Base, the shape where you bring your own vector store, is limited to S3 and custom. Coverage now separates the two Bedrock shapes from each other rather than separating Bedrock from Quick.
Control is where the custom build still stands apart, and only in the customer-managed shape. There you pick the vector store from a long list, including OpenSearch Serverless, S3 Vectors, Aurora PostgreSQL, Neptune Analytics, Pinecone and MongoDB Atlas. You pick the chunking strategy: default at roughly 300 tokens, fixed-size, hierarchical, semantic, or none at all. You pick any Bedrock embedding model. Managed knowledge bases narrow all three, with chunking limited to built-in or fixed-size and a substitute embedding model required to be float32 at 1024 dimensions. Quick exposes none of these settings.
Then there is what the team carries afterwards. AWS operates Quick, so the work is connecting sources and configuring access. A custom build puts retrieval quality, identity plumbing, evaluation and day-two operations on the team permanently. That work is waste when the requirement is standard, and the only route to tuning every layer when it is not.
This is a buy-versus-build decision, and buying wins by default when the requirement sits inside the product’s envelope. A custom build has to justify itself with control the managed product cannot offer.
What we’ll filter on
- Sign-in ownership, does AWS authenticate staff, or does your application do it and pass identity into retrieval?
- Document-level access, must answers be filtered per user, and do the sources support ACL crawling?
- Data-source fit, are the sources among the six with built-in connectors?
- Customisation depth, does the requirement need a specific vector store, chunking strategy, embedding model, foundation model, or user experience?
- Time to first usable answer, how quickly must staff have something?
- Operational ownership, who runs retrieval quality and evaluation over the years that follow?
The landscape
Amazon Quick. A managed AI assistant for the enterprise, grown out of Amazon QuickSight, which continues inside it as Amazon Quick Sight. You point Quick Index at data sources through built-in integrations, it indexes the content, and staff ask questions in chat. They reach it from the web, the desktop application, Chrome, Slack, Microsoft Teams and Microsoft 365. Around the assistant sit Quick Flows for workflow automation, Quick Automate for agent-driven business processes, Quick Research for cited reports, and spaces for sharing knowledge bases with a team. Action connectors, MCP and OpenAPI let it act in other systems rather than only answer. An existing Amazon Q Business index can be attached as a knowledge base, keeping the access controls it already carries. You configure Quick rather than rebuild its internals.
A custom RAG app on Amazon Bedrock Knowledge Bases. Knowledge Bases comes in two shapes, and the difference matters more than the Quick comparison does. A Bedrock Managed Knowledge Base runs ingestion, storage, indexing and retrieval for you, with seven native connectors, ACL-aware retrieval, agentic retrieval, and built-in embedding and reranking models. A Customer-managed Knowledge Base hands you the vector store and the search strategy, and narrows the connector list to S3 and custom. Either way your application supplies the front end, the authentication, the foundation model and the prompts. Source files are capped at 50 MB each, against 500 MB for a standard document in Quick Index.
The hybrid reality. The two are not either-or. A Bedrock Managed Knowledge Base can be associated natively as a knowledge base inside Quick, so one index serves both a bespoke application and general staff chat. The axes below apply per use case, not once for the whole organisation.
Evaluation
Side by side
| Attribute | Amazon Quick | Custom app on Bedrock Knowledge Bases |
|---|---|---|
| Authenticates end users | ✓ IAM Identity Center or IAM Federation | ✗ your app authenticates and passes identity |
| Document-level ACL filtering | ✓ per-document check at query time | ✓ ACL-aware retrieval on managed bases |
| Real-time ACL re-check | Not documented | ✓ SharePoint, OneDrive, Google Drive, Confluence |
| Native connectors to document stores | ✓ six | ✓ seven managed, two customer-managed |
| Choice of vector store | ✗ | ✓ customer-managed only |
| Control of chunking and embeddings | ✗ | ✓ full on customer-managed, partial on managed |
| Choice and swapping of foundation model | ✗ | ✓ |
| Custom or embedded user experience | ✗ Quick’s own surfaces | ✓ any you build |
| Actions in other systems | ✓ action connectors, MCP, Flows, Automate | Build with tool use or agents |
| Time to first usable answer | Fast | Slower |
| Operational ownership | AWS | Your team |
Read the table against the requirement and the old tie-breaker has gone. Per-user document filtering appears in both columns now, so it no longer decides anything on its own. What still separates them is the front end, the sign-in, and the retrieval internals.
The solution
For the assistant as described, Amazon Quick is the stronger default, and time to first answer decides it rather than access control. Quick signs staff in through IAM Identity Center, checks permissions per document at query time, and reaches all four sources through built-in integrations. Nobody writes a front end, a sign-in flow, or the plumbing that carries a verified identity into every retrieval call. Staff have a working assistant in weeks. Spaces, action connectors and Flows leave room to grow from answering into acting.
The custom Bedrock build becomes the right pick when the requirement steps outside that envelope. Concretely: a chunking strategy the content demands, a particular embedding or foundation model, a vector store the team already runs, retrieval embedded inside an existing product, or a source with no connector. Start with a managed knowledge base, which keeps the seven connectors and the ACL-aware retrieval. Drop to customer-managed only for the vector store or the search strategy, and note that the connector list shrinks to S3 and custom when you do.
The trap is picking the custom build for the control and then under-building the identity layer. Bedrock filters on whatever identity your application hands it and cannot tell a correct one from a stale one. Two failure modes follow. A mismatched email returns nothing from that source, silently. A reassigned email returns someone else’s documents.
The honest tie-breaker is the front end crossed with the retrieval internals. If a standard chat surface and standard retrieval will do, buy. If either has to be yours, and the team is resourced to own authentication and operations, build. The decision below walks those gates.
Worked example
Take the requirement as stated: HR policies in SharePoint, deal notes in Google Drive, engineering docs in Confluence, PDFs and spreadsheets in S3, answers scoped to each user, usable in weeks.
Walk it through the gates. A stock chat surface is fine for a general staff assistant, so nobody needs a bespoke front end. That points at buy. All four sources sit among Quick’s six integrations, so ingestion and permission capture are configuration rather than code. That confirms buy. Does the content demand a particular vector store or chunking scheme? For mixed policy documents and deal notes, no. So Amazon Quick is the pick. Connect the four sources, wire it to IAM Identity Center, set the governance controls, and staff have a permission-respecting assistant in weeks.
Now change one fact. Suppose the assistant has to live inside the company’s existing internal portal, answers must come from a foundation model the business has standardised on, and the engineering docs need chunking tuned to their heavy code blocks. Those three push through every gate. The pick flips to a Bedrock build, and the shape matters: a managed knowledge base keeps the SharePoint, Google Drive and Confluence connectors plus ACL-aware retrieval, while the portal handles sign-in and passes each user’s verified email into every retrieval call. Only the code-block chunking argues for customer-managed, and dropping to that shape loses three of those four connectors. Same organisation, different use case, different answer.
What’s worth remembering
- Both options do RAG, so the decision is which layers the team builds and operates, not whether there is a retrieval pipeline.
- Quick authenticates staff through IAM Identity Center or IAM Federation and checks permissions per document; a Bedrock build authenticates users itself and passes a verified identity into retrieval.
- Bedrock Managed Knowledge Bases do ACL-aware retrieval across the same six document stores Quick connects to, with real-time re-checks on SharePoint, OneDrive, Google Drive and Confluence.
- ACL awareness is filtering, not authorization: matching is on email exactly as spelled in each source, and a stale address fails silently.
- Pick a Customer-managed Knowledge Base only for the vector store or the search strategy, because it narrows the connector list to S3 and custom.
- Buy by default when the requirement sits inside the product’s envelope; the custom build has to justify itself with control the managed product cannot offer.