The situation
A mid-sized enterprise wants an internal assistant that answers staff questions from company knowledge: HR policies in SharePoint, deal notes in Salesforce, engineering docs in Confluence, and a pile of PDFs and spreadsheets in Amazon S3. The ask sounds simple, chat with our documents, but two constraints make it real. First, the answers must respect who is asking: a support agent must not see the compensation spreadsheet just because it happens to contain the phrase they searched for, and the assistant must never surface a document the person could not open directly. Second, 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 Q Business, a managed enterprise assistant that connects to those data sources through built-in connectors, indexes and retrieves for you, and enforces each user’s existing permissions on every answer. The other is a custom retrieval application built 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, and also owns the connectors and the permission enforcement.
The instinct is to reach for the custom build because it is the interesting engineering. The question underneath is whether the requirement is standard enough that the managed product already does the hard part, or bespoke enough that owning every layer earns back its cost.
What actually matters
The first thing worth naming is that both options do retrieval-augmented generation. Both chunk documents, embed them, store the vectors, retrieve the relevant passages at query time, and hand them to a model to ground the answer. The difference is not whether there is a RAG pipeline; it is who builds and operates each layer of it, and what comes pre-solved.
The property that decides the most here is identity-aware retrieval. When staff ask questions across HR, sales, and engineering content, the assistant has to filter what it retrieves by the asking user’s permissions, so an answer only ever draws on documents that user is allowed to see. Amazon Q Business does this natively: it can integrate with an identity provider through IAM Identity Center, honour the access-control lists that its connectors ingest alongside the documents, and scope each user’s retrieval to their own entitlements. Building the same thing on Bedrock Knowledge Bases is possible, using metadata filtering and per-user access tokens threaded through retrieval, but you are designing, building, and testing that enforcement yourself, and getting it wrong leaks documents. This one axis often settles the decision on its own.
The second is data-source coverage. Q Business ships a large catalogue of managed connectors for common enterprise systems, S3, SharePoint, Salesforce, Confluence, and many more, that handle ingestion, incremental sync, and pulling in each document’s access-control metadata. If your sources are in that catalogue, that is a large amount of undifferentiated plumbing you do not write. On a custom build you either use a Bedrock Knowledge Bases native data source, S3 and a growing set of others, or you build and operate the ingestion for anything outside it, including the part that captures permissions.
The third is customisation and control. A custom Bedrock app lets you tune chunking strategy, choose the embedding model, pick the vector store, select and swap the foundation model, shape the prompts and the grounding, and build any user experience you like, including embedding retrieval inside an existing product rather than a standalone chat window. Q Business is customisable within its own envelope, guardrails, admin controls, plugins that let it take actions in other systems, Q Apps for packaging lightweight task flows, but you do not get to replace its retrieval internals. If the requirement needs a specific chunking scheme, a particular model, or retrieval woven into a bespoke workflow, the managed envelope becomes a ceiling.
The fourth is time to value against total ownership. Q Business is fast to stand up and is operated by AWS, so the team’s effort goes into connecting sources and configuring access rather than building and running a pipeline. The custom build is slower to first answer and puts retrieval quality, permission enforcement, evaluation, and ongoing operations permanently on the team. That ownership is a cost when the requirement is standard and an asset when it is genuinely bespoke, because it is also the only path that lets you tune every layer.
The softer, cross-cutting point: this is a buy-versus-build decision, and buy wins by default when the requirement sits inside the product’s envelope. The custom build has to justify itself with a real need for control that the managed product cannot meet, not with the appeal of building it.
What we’ll filter on
- Identity-aware access, does the assistant have to enforce per-user, document-level permissions on every answer?
- Data-source fit, are the sources covered by existing managed connectors, or do they need custom ingestion?
- Customisation depth, does the requirement need control over chunking, embeddings, vector store, model, prompts, or UX?
- Time to value, how quickly must staff have something usable?
- Operational ownership, who is going to run retrieval quality, permissions, and evaluation over time?
The landscape
Amazon Q Business. A fully-managed generative-AI assistant for the enterprise. You point it at data sources through built-in connectors, it indexes and retrieves the content, and it answers questions grounded in that content through a ready-made chat experience, in a web app or embedded. Its distinguishing strength is that it is identity-aware: integrated with IAM Identity Center and your identity provider, it honours the access-control information its connectors ingest, so retrieval is scoped to what each user is permitted to see. It includes admin controls and guardrails for topic and response governance, and plugins so the assistant can take actions in other systems rather than only answering. Q Apps let staff package a prompt-driven task into a small shareable app, and Q also surfaces inside other services, for example Amazon Q in QuickSight for data questions. The trade is that you work within its model of the world; you configure it rather than rebuild its internals.
A custom RAG app on Amazon Bedrock Knowledge Bases. Bedrock Knowledge Bases is the managed retrieval layer: give it a data source, and it handles chunking, embedding with a model you choose, and storing the vectors in a supported vector store, then exposes retrieval APIs (retrieve, and retrieve-and-generate) that your application calls. Around that you build the rest: the connectors for any source Knowledge Bases does not natively ingest, the access-control enforcement, the choice and orchestration of the foundation model, the prompt and grounding design, evaluation, and the user experience. You get full control of every layer and full responsibility for it. This is the right shape when the requirement is bespoke enough that the control pays for the ownership, or when retrieval has to live inside an existing application rather than a standalone assistant.
The hybrid reality. The two are not strictly either-or. A team can start on Q Business for the broad enterprise-assistant need and build a targeted Bedrock app for the one workflow that needs bespoke retrieval, or use Bedrock Knowledge Bases as the retrieval engine inside a product while Q Business serves general staff questions. The decision axes below apply per use case, not once for the whole organisation.
Side by side
| Attribute | Amazon Q Business | Custom app on Bedrock Knowledge Bases |
|---|---|---|
| Identity-aware, per-user access | ✓ built in | ✗ you design and build it |
| Managed connectors to enterprise sources | ✓ large catalogue | ✗ native sources plus DIY ingestion |
| Retrieval pipeline managed for you | ✓ | Partly (KB does retrieval; you own the app) |
| Control of chunking, embeddings, vector store | ✗ within product envelope | ✓ full control |
| Choice and swapping of foundation model | ✗ within product envelope | ✓ full control |
| Custom or embedded UX | ✗ Q’s chat surfaces | ✓ any UX you build |
| Actions in other systems | ✓ plugins | Build with tool use / agents |
| Time to first usable answer | Fast | Slower |
| Operational ownership | AWS | Your team |
Reading the table against the requirement: the enterprise assistant needs identity-aware retrieval across many standard sources, fast, which is exactly the column Q Business wins. A custom Bedrock build wins when the row that matters is control of chunking, model, or UX, and the team is willing to own permissions and operations to get it.
The picks in depth
For the assistant as described, Amazon Q Business is the stronger default, and it is the two constraints that decide it. The per-user, document-level access control is native, so the compensation spreadsheet stays invisible to the support agent without the team designing an enforcement layer, and the managed connectors to SharePoint, Salesforce, Confluence, and S3 mean the ingestion, sync, and permission capture are configuration rather than a build. That collapses the time-to-value constraint too: staff get something usable in weeks because the hard, undifferentiated parts, secure retrieval across mixed sources, are the product’s job. Guardrails and admin controls come with it, and plugins leave room to grow from answering into acting without a rebuild.
The custom Bedrock Knowledge Bases build becomes the right pick when the requirement steps outside that envelope. Concretely: a specific chunking strategy the content demands, a particular embedding or foundation model you need to choose and swap, a vector store you already run, retrieval that has to be embedded inside an existing product rather than a standalone assistant, or a data source with no connector where you would be building ingestion regardless. In those cases you are buying control you genuinely need, and the price is that identity-aware retrieval, permission enforcement, retrieval-quality evaluation, and day-two operations are all now yours to design, build, and run. The trap is choosing the custom build for the control and quietly under-building the permission enforcement that Q Business would have given you for free; a document-leak from a home-grown access filter is a far worse outcome than a slightly less bespoke assistant.
The honest tie-breaker is the identity requirement crossed with data-source fit. When both point at standard, buy. When the requirement needs control the product cannot give, and the team is genuinely resourced to own permissions and operations, build. The decision below walks those gates.
A worked example: the mixed-source staff assistant
Take the requirement as stated: HR policies in SharePoint, deal notes in Salesforce, engineering docs in Confluence, PDFs and spreadsheets in S3, answers scoped to each user’s permissions, usable in weeks.
Walk it through the gates. Per-user access is a hard requirement, and it is the standard kind: honour the permissions the source systems already hold. That points at buy. The sources are all in the managed-connector catalogue, so ingestion, sync, and access-control capture are configuration, not code. That confirms buy. Is bespoke control needed, a specific chunking scheme, a particular model, retrieval embedded in another product? For a general staff assistant, no. So Amazon Q Business is the pick: connect the four sources, wire it to the identity provider through IAM Identity Center, set guardrails, and staff have a permission-respecting assistant in weeks, with the leak-risk of a home-grown access filter never entering the picture.
Now change one fact. Suppose the assistant must live inside the company’s existing internal portal, answers have to be generated by a specific foundation model the business has standardised on, and the engineering docs need a chunking strategy tuned to their heavy code blocks. Those three push through the last gate: the requirement now needs control the managed envelope will not give. The pick flips to a custom Bedrock Knowledge Bases build, with Knowledge Bases doing retrieval, the chosen model doing generation, retrieval embedded in the portal, and, unavoidably, the team designing and testing the per-user access enforcement that Q Business would have handed them. Same organisation, different use case, different answer, which is exactly why the axes are applied per requirement rather than once.
What’s worth remembering
- Both options are RAG; the real question is who builds and operates each layer, and what comes pre-solved, not whether there is a retrieval pipeline.
- Identity-aware, per-user document access is Amazon Q Business’s standout strength, native through IAM Identity Center and connector-ingested access controls; on a custom build you design and test that enforcement yourself.
- If the data sources are in Q Business’s managed-connector catalogue, ingestion, sync, and permission capture are configuration rather than code you write and run.
- A custom app on Bedrock Knowledge Bases gives full control of chunking, embeddings, vector store, model, prompts, and UX, and full ownership of retrieval quality, permissions, and operations.
- Buy wins by default when the requirement sits inside the product’s envelope; the custom build has to justify itself with a real need for control the managed product cannot meet.
- Choose the custom build when you need a specific chunking scheme, a particular or swappable model, a vector store you already run, retrieval embedded in another product, or a source with no connector.
- The worst outcome is picking the custom build for the control and under-building the permission enforcement Q Business would have given you for free; a leak from a home-grown access filter beats no bespoke feature.
- Time to value favours Q Business heavily, because the hard undifferentiated part, secure retrieval across mixed sources, is the product’s job.
- Q Business grows past answering into acting through plugins, and packages small task flows as Q Apps, without a rebuild.
- The decision is per use case: the same organisation can buy for the general staff assistant and build for the one workflow that genuinely needs bespoke retrieval.