top of page

Amazon Q Business vs. Custom Bedrock RAG: The Enterprise Decision Guide for 2026


Amazon Q Business and a custom Amazon Bedrock RAG system can both answer questions from enterprise data. That similarity disappears as soon as a buyer asks what is actually being purchased.


Amazon Q Business is a managed workplace assistant: connectors, an enterprise index, permission-aware responses, citations, a web experience, subscriptions, guardrails, analytics, and supported actions are assembled into a product. A custom Bedrock RAG solution is an application your organization designs: it can use Bedrock models, Knowledge Bases, Guardrails, Agents or AgentCore capabilities, and AWS infrastructure, but the product boundary belongs to you.


This is not simply managed versus custom retrieval. It is buy an employee-facing application versus build an AI product on a platform.


That distinction affects delivery time, user experience, model choice, security boundaries, integrations, evaluation depth, operating responsibilities, and cost. It also affects whether the comparison is available to your organization at all: AWS changed the Amazon Q Business product path in 2026.


This guide explains the decision for existing Q Business customers, greenfield buyers, and teams considering a migration to custom Bedrock RAG.


2026 Product Advisory: Read This Before Comparing Features


As of this article's review date, AWS states that Amazon Q Business is no longer open to new customers after the end of July 2026. AWS also says existing Q Business customers can continue using the service or use their existing Q index with Amazon Quick, which AWS describes as the next evolution of Q Business. Review the live Amazon Q Business product notice and Amazon Q Business API notice before making a procurement decision.


The practical consequence is:

  • Existing Q Business customer: This comparison remains directly relevant. You can continue, extend, adopt Amazon Quick, or migrate selected workloads to custom Bedrock RAG.

  • Organization that enrolled before the cutoff but has not deployed: Confirm account eligibility and support status with AWS before treating Q Business as a new strategic platform.

  • New customer after the cutoff: Do not create a roadmap that assumes you can start a new Q Business tenancy. Your current comparison is more likely Amazon Quick versus custom Bedrock RAG.

  • Content or procurement team using this article later: Recheck the linked AWS notice. Product names, transition options, and dates can change.


This lifecycle change does not make the technical comparison useless. It makes lifecycle fit a mandatory architecture criterion. A platform can meet every functional requirement and still be the wrong greenfield choice if its customer-onboarding path has closed.

2026 editorial position: Existing customers should make a measured stay, extend, or migrate decision. Greenfield buyers should evaluate Amazon Quick and custom Bedrock rather than trying to enter Q Business through an unsupported path.

The Executive Decision Map

Use the following map before reading the detailed comparison.

Your situation

Recommended starting point

Primary reason

Existing Q Business deployment meets workforce needs

Optimize or transition deliberately to Amazon Quick

Avoid rebuilding a functioning employee assistant without evidence

Existing Q Business deployment needs a branded or embedded experience

Assess Q Business APIs/embedding, Amazon Quick, and custom Bedrock

The UI and product boundary—not retrieval alone—may decide the choice

New workforce assistant for internal knowledge and productivity

Evaluate Amazon Quick first, then custom Bedrock

Q Business is no longer the normal greenfield entry path

Customer-facing AI feature inside a SaaS or digital product

Custom Bedrock RAG

Requires product-specific UX, tenancy, telemetry, release control, and economics

Need to choose models, retrievers, vector stores, prompts, or ranking logic

Custom Bedrock RAG

These are platform-level decisions Q Business intentionally abstracts

Need broad enterprise connectors and permission-aware answers quickly

Existing Q Business or Amazon Quick, if eligible

Packaged connectivity and identity-aware retrieval reduce integration work

Need highly specialized retrieval, structured tools, or domain workflows

Custom or hybrid Bedrock architecture

Application owns orchestration and evidence contracts

Unsure whether customization creates value

Run a bounded comparative benchmark

Make the decision from quality, security, adoption, and TCO evidence

Short Answer


Choose the managed workplace-product path when the desired outcome is a broadly deployed employee assistant and the packaged identity, connector, chat, citation, and action model fits.


Choose custom Bedrock RAG when the desired outcome is a differentiated AI application or when model choice, retrieval behavior, authorization, user experience, tenant isolation, workflow control, evaluation depth, or product telemetry is a strategic requirement.


Do not choose custom merely because it sounds more flexible. Flexibility becomes engineering and operational ownership. Do not remain on a packaged product merely because it was faster to launch. A product abstraction becomes costly when it blocks a critical requirement.


The Real Boundary: Workplace Product vs. Application Platform


The fastest way to understand the choice is to compare what the buyer receives.


Amazon Q Business Product Boundary

Enterprise sources + source permissions
        ↓
Managed connectors and synchronization
        ↓
Amazon Q index and permission-aware retrieval
        ↓
Managed response generation and citations
        ↓
Web experience, integrations, plugins, controls, analytics
        ↓
Subscribed workforce users

Amazon Q Business is designed to produce a usable employee experience without requiring a team to assemble every RAG component. AWS describes it as a fully managed assistant that answers questions, summarizes, generates content, and completes supported tasks from enterprise data. See What is Amazon Q Business?.


Custom Bedrock RAG Product Boundary

Your identity and application experience
        ↓
Your API, session, policy, and orchestration layer
        ↓
Bedrock Knowledge Base or custom retrievers and tools
        ↓
Bedrock embeddings, rerankers, foundation models, guardrails, evaluations
        ↓
Your citations, telemetry, feedback, releases, support, and economics

Amazon Bedrock is a platform for building generative AI applications. A custom RAG design can use a Bedrock Managed Knowledge Base, a customer-managed vector knowledge base, or an independently implemented retriever that calls Bedrock models. The application team decides how much of the retrieval stack to manage.


For the retrieval-layer distinction, see Amazon Bedrock Knowledge Bases vs. Custom RAG. This article compares the larger product boundary: Q Business as a workplace application versus a custom application built with Bedrock.


What Amazon Q Business Gives an Existing Customer


The value of Q Business is not one retrieval algorithm. It is the amount of enterprise-assistant work already packaged around retrieval.


Broad Enterprise Connectivity


The current connector catalog includes Amazon S3, SharePoint, OneDrive, Teams, Exchange, Google Drive, Gmail, Confluence, Jira, Salesforce, ServiceNow, Slack, Box, GitHub, Zendesk, and other systems, plus web and custom connectors. The exact set and preview status change, so use the live Amazon Q Business connector list.


Connectors do more than copy text. For supported sources they can crawl document ACL and identity information, store principal mappings, and filter responses based on the end user's access. ACL changes take effect through source synchronization, making connector scheduling part of the authorization design. AWS explains this behavior in Q Business connector concepts.


This is a meaningful advantage when an organization would otherwise have to build, secure, monitor, and update many source adapters.


A Workforce Identity Model


Q Business integrates with AWS IAM Identity Center and also documents an IAM federation route with limitations. IAM Identity Center is the recommended workforce-access model, connecting corporate users and groups to application subscriptions and document permissions. Review how Amazon Q Business works and the IAM Identity Center setup guidance.


The advantage is a defined, enterprise-oriented identity path. The trade-off is that your product must fit that path. A customer-facing application with millions of external identities, custom tenant claims, product tiers, or highly dynamic authorization may be a better fit for a custom architecture.


A Finished Chat Experience


The managed web experience includes conversation, citations, file uploads, advanced search, response feedback, source review, and supported actions. It can be branded within supported configuration boundaries and distributed through supported workplace integrations. See the current Q Business web-experience capabilities.


That can shorten time to adoption for an internal assistant. It can also become a constraint if the assistant must live inside a product-specific workflow, render domain objects, stream custom UI components, follow a unique approval process, work offline, or expose detailed evidence controls.


Managed Responses, Citations, and Agentic RAG


Q Business provides source attributions and can restrict responses to enterprise data. Its current feature set also includes agentic RAG, response-personalization options, file upload, metadata filtering through APIs, and hallucination mitigation. See Amazon Q Business features.


This is valuable for a workplace product where administrators prefer configuration to retrieval engineering. It is less suitable when the team must choose the underlying LLM, inspect every retrieval stage, implement a proprietary reranker, or guarantee a custom output schema.


Plugins and Supported Actions

Built-in and custom plugins can query external systems or perform actions from chat. Custom plugins use an OpenAPI schema, network and authentication configuration, and supported action definitions. Q Business can present a review form before an action is submitted. See Q Business actions and plugins and custom plugin configuration.

The boundary matters. Current AWS documentation says that once a plugin is enabled for an application, all authorized web-experience users can see and use it; plugin access cannot be customized per end user at that feature layer. The downstream system still needs correct authentication and authorization. Review the live plugin-use limitations before treating plugins as a fine-grained entitlements system.


Administrative Controls and Product Analytics


Administrators can configure global and topic-level controls, enterprise-data-only behavior, file uploads, personalization, orchestration, and hallucination mitigation. Some combinations have constraints: current documentation notes that hallucination mitigation must be disabled when chat orchestration is enabled. See Q Business global controls.


Q Business publishes CloudWatch metrics for chat volume, no-answer messages, hallucination detections, action invocations and errors, time to first token, latency, active users, conversations, and feedback. It also offers an analytics dashboard for usage and unsuccessful queries. Review Q Business chat metrics and analytics dashboard metrics.

These are valuable product-operating signals. A mature evaluation program still needs representative test questions, expected evidence, permission-negative cases, domain review, and release thresholds.


What Custom Bedrock RAG Makes Possible


Custom Bedrock RAG trades the packaged assistant for architectural choice.


Three Retrieval Depths


A custom application can choose among:

  1. Bedrock Managed Knowledge Base: Bedrock manages ingestion, storage, indexing, embeddings, reranking, and retrieval infrastructure.

  2. Bedrock customer-managed vector knowledge base: Bedrock provides knowledge-base workflows while the customer owns a supported vector or graph store.

  3. Fully custom retriever: The application owns parsing, chunking, embeddings, indexing, querying, fusion, reranking, and evidence assembly, while still using Bedrock models where useful.


AWS's current Knowledge Bases overview and managed versus customer-managed comparison explain the first two. AWS Prescriptive Guidance describes custom RAG retriever options.


This graduated architecture is important. “Custom Bedrock RAG” does not require rebuilding a vector database, and using a managed knowledge base does not require accepting the Q Business user experience.


Model, Prompt, and Response Control


A Bedrock application can select supported foundation models based on accuracy, latency, modality, Region, price, and risk. It can route different tasks to different models, version system prompts, enforce JSON schemas, validate citations, add deterministic post-processing, and change behavior by workflow.


AWS explicitly notes in its RAG option selection guidance that Q Business does not expose LLM choice, whereas Bedrock lets builders select supported models.


Model choice is not automatically a business benefit. It matters when measured model differences affect accuracy, latency, cost, language support, modality, or contractual requirements. Otherwise it can create a permanent model-evaluation burden without changing user outcomes.


Purpose-Built User Experience


A custom application can:

  • Embed the assistant inside a customer portal, operational console, mobile app, or SaaS product.

  • Render tables, cards, diagrams, source previews, forms, and domain objects.

  • Show confidence, evidence sufficiency, approval status, or risk indicators.

  • Mix conversational and deterministic interfaces.

  • Route low-confidence cases to an agent or specialist.

  • Preserve product-specific session state and user preferences.

  • Add accessibility, localization, and channel requirements beyond a standard chat surface.

  • Instrument conversion, task completion, deflection, and workflow outcomes.


For an internal knowledge assistant, these freedoms may be unnecessary. For a revenue-generating AI feature, they may define the product.


Application-Specific Authorization and Tenancy


Custom Bedrock RAG can use Cognito, an external identity provider, IAM, verified JWT claims, Amazon Verified Permissions, database row-level security, vector-store filters, separate indexes, separate accounts, or combinations of these controls.


This enables pooled, bridge, and silo tenant patterns; per-workflow tool entitlements; product-tier restrictions; just-in-time authorization; and detailed decision logs. It also transfers responsibility for implementing every identity propagation and cache-isolation detail correctly.


The central rule is unchanged:

The model must receive only evidence and tool permissions that the verified principal is authorized to use. Prompts and output filters are not authorization controls.

Arbitrary Retrieval and Tool Orchestration


A custom system can classify a question and route it among:

  • A Bedrock knowledge base for governed documents.

  • OpenSearch for tuned keyword and vector retrieval.

  • Aurora PostgreSQL or another relational store for structured facts.

  • Neptune Analytics for graph relationships.

  • A real-time ERP, CRM, pricing, inventory, or case-management API.

  • A policy engine for authorization.

  • A calculator or deterministic business rule.

  • A human-approval workflow.


Evidence from these systems can be normalized, ranked, deduplicated, and presented with a consistent citation contract. That is difficult to express as a conventional workplace search assistant, but it is also a substantial engineering program.


Component-Level Evaluation and Release Control


Custom RAG can record parser versions, chunks, filters, candidates, ranks, reranker scores, evidence selection, prompt versions, model versions, citations, policy outcomes, latency, tokens, and cost for every request. Teams can run shadow pipelines, blue/green indexes, canary model changes, and retrieval regression gates.


Amazon Bedrock offers knowledge-base evaluation capabilities covering retrieval and generation dimensions. Review Bedrock Knowledge Base evaluation. The application team must still create the benchmark and decide what “good enough” means.


Eleven Questions That Decide the Architecture


Feature tables are useful, but enterprise decisions usually turn on a small number of constraint questions.


1. Is the User an Employee or a Product Customer?


Q Business was designed around workforce users and enterprise subscriptions. Its identity integration, workplace experience, connectors, and per-user tiers align naturally with employee productivity.


Custom Bedrock RAG aligns better with customers, partners, anonymous traffic, devices, applications, or complex tenant populations. Q Business also documents consumption pricing for anonymous embedded use cases, but the 2026 new-customer notice and product-successor path must be considered before selecting it.


Decision: If the assistant is primarily an internal employee destination, the managed workplace path deserves the first evaluation. If AI is a feature inside your product, custom Bedrock is usually the stronger baseline.


2. Is Chat the Product or One Step in a Workflow?


Q Business provides a capable chat and search experience with citations, uploads, feedback, and plugins. It is strongest when conversation is the main interaction.


Custom Bedrock is stronger when AI is one step inside claims review, customer support, procurement, clinical operations, legal review, field service, analytics, or another domain workflow. The application can combine RAG with deterministic screens, validation, approvals, and system updates.


Decision: Prefer Q Business for a general assistant. Prefer custom Bedrock for a domain application with embedded AI.


3. Do Packaged Connectors Cover the Sources?


Q Business's connector breadth can save months of source-integration work, especially when source ACLs must be indexed.


Custom RAG is required when sources are unsupported, data must arrive through events or CDC, preprocessing is domain-specific, connector behavior must be transactional, or the same ingestion platform serves multiple products.


Decision: Create a source matrix with connector availability, authentication, ACL support, field coverage, change detection, deletion behavior, rate limits, sync time, and error recovery. “Connector exists” is not the same as “connector satisfies the requirement.”


4. How Quickly Must Data and Permission Changes Appear?


Q Business updates connector-indexed ACLs and content through synchronization. The correct sync frequency depends on source capabilities and operating requirements.


Custom Bedrock can implement event-driven ingestion, transactional deletion, or per-query checks against a source-of-truth policy system. It can also fail through queue delays, partial writes, or index drift if not engineered carefully.


Decision: Define separate service levels for new content, content updates, deletions, permission grants, and permission revocations. High-risk systems should test revocation propagation with real source and identity changes.


5. Must You Choose or Route the LLM?


Q Business deliberately abstracts the underlying model. This reduces model operations and gives AWS responsibility for the packaged experience.


Custom Bedrock exposes supported model selection and permits routing by task, cost, risk, language, modality, or latency.


Decision: If no business requirement changes with model choice, abstraction is an advantage. If the model is part of product differentiation, compliance, cost control, or evaluation, choose the platform boundary.


6. How Specialized Is Retrieval?


Q Business provides managed enterprise search and agentic RAG behavior. It is appropriate for broad knowledge discovery.


Custom retrieval is justified for clause-aware legal search, code-aware indexing, temporal policy reasoning, medical terminology, product-identifier boosting, graph traversal, multimodal region retrieval, learned ranking, cross-index fusion, or other specialized methods.


Decision: Require a representative benchmark. “We may need custom ranking later” is not sufficient reason to fund a search platform today.


7. What Is the Authorization Boundary?


Q Business maps identities and source ACLs to permission-aware responses. That is a strong fit when enterprise-source permissions are the intended policy.


Custom Bedrock is stronger when authorization depends on transaction state, contract, tenant, jurisdiction, case assignment, product tier, consent, purpose of use, or dynamic policy evaluation outside source ACLs.


Decision: Draw the identity and authorization sequence for both a permitted and denied request. Include plugins, caches, logs, citations, and feedback data—not only document retrieval.


8. How Much Action Control Is Required?


Q Business plugins support built-in and OpenAPI-described actions with a managed interaction model. This is useful for common workplace tasks.


Custom Bedrock agents can implement per-tool entitlements, state machines, transaction boundaries, idempotency, compensating actions, multi-step approvals, custom UI, and domain-specific audit evidence.


Decision: Use packaged plugins for bounded employee productivity where their access and review model fits. Use custom orchestration for high-risk or product-specific transactions.


9. What Must Be Observable and Reproducible?


Q Business provides CloudWatch and product-analytics signals. A custom system can expose every intermediate retrieval and generation artifact, subject to privacy controls.


Decision: If operators must explain why a particular chunk was ranked, reproduce an answer against an exact index version, or compare multiple retrievers, confirm what Q Business exposes before selecting it. Do not assume that “managed” means opaque or that “custom” means observable; both require validation.


10. Which Regions and Residency Rules Apply?


Current AWS documentation lists Q Business endpoints in a limited set of Regions and notes that some non-US Regions have reduced feature availability. It also states that cross-Region inference is enabled by default and advises highly regulated customers with in-country processing needs to contact AWS Support. Review Q Business endpoints and quotas and cross-Region inference behavior.


Bedrock availability also varies by Region, model, and capability, but a custom architecture may offer more ways to select components that satisfy residency requirements.


Decision: Validate the complete data path: sources, connector processing, index, identity, inference, logs, backups, external plugins, and support access.


11. What Is the Product's Strategic Horizon?


Q Business's 2026 customer-onboarding change makes lifecycle a first-class consideration. Existing customers need support, transition, and exit plans. New customers need to evaluate the successor offering rather than relying on historical Q Business materials.


Custom Bedrock does not eliminate product evolution. Models, APIs, Knowledge Bases, AgentCore, vector stores, and pricing also change. The difference is that your application contract can isolate those changes if designed well.


Decision: Record a three-year lifecycle assumption, named owner, review date, migration triggers, and data-exit plan for either choice.


Side-by-Side Enterprise Scorecard


The table below is a starting hypothesis, not a substitute for testing.

Decision area

Amazon Q Business

Custom Bedrock RAG

Primary product

Managed workforce assistant

Custom AI application or product feature

2026 greenfield availability

Closed to new customers after July cutoff according to current AWS notice

Available subject to Bedrock service, model, and Region availability

Existing-customer path

Continue or use existing Q index with Amazon Quick

Continue evolving custom application

Time to initial employee experience

Faster when packaged features fit

Longer because app, identity, UX, and operations must be built

Connectors

Broad managed enterprise catalog

Any source the team implements; Bedrock KB connectors may reduce work

Source ACL integration

Managed for supported connectors

Must be designed through KB ACLs, metadata filters, policy services, or datastore controls

User experience

Managed web and supported integrations

Fully custom web, mobile, embedded, API, and channel experiences

Model choice

Not exposed to customer

Supported Bedrock models selected and routed by application

Retrieval control

Configurable product behavior

Managed KB, customer-managed KB, or fully custom retrieval

Citations

Built-in source attribution

Application defines and validates citation contract

Actions

Built-in/custom plugins with supported interaction model

Arbitrary tools, state machines, approvals, and UI

Per-user action entitlements

Product-layer limitations require review

Can be implemented at application and tool boundaries

Guardrails

Administrative global/topic controls and supported mitigation

Bedrock Guardrails plus custom input, retrieval, tool, and output policies

Evaluation

Product analytics, feedback, CloudWatch; custom testing still needed

Component and end-to-end evaluation designed by team; Bedrock evals available

Multi-tenancy

Workforce/application model; verify intended isolation

Pooled, bridge, or silo patterns under customer design

Pricing shape

User subscriptions plus index; anonymous consumption option

Models, retrieval, storage, compute, network, observability, and engineering

Operations

Lower infrastructure burden

Full product, integration, evaluation, and possibly retrieval operations

Portability

Q-specific index, application, identity, and experience

Depends on internal contracts; can be higher but is not automatic


Mandatory Gates


Before applying weights, eliminate any option that fails one of these gates:

  1. Availability gate: Can the organization legally and technically procure or continue the service in the required account and Region?

  2. Security gate: Does the identity, authorization, residency, encryption, audit, and action model satisfy policy?

  3. Quality gate: Does the system retrieve authoritative evidence and generate acceptable answers on a representative benchmark?

  4. Product gate: Can it deliver the required user experience, integrations, workflows, and product telemetry?

  5. Operations gate: Can the team meet freshness, latency, availability, recovery, support, and change-management requirements?

  6. Economic gate: Does the three-year expected value exceed build, run, change, and migration cost?


A strong score on deployment speed cannot compensate for a failed authorization gate.


Workload Outcomes: Which Architecture Usually Wins?


Company-Wide HR, IT, and Policy Assistant


Need: Employees ask policy, benefits, IT, and procedure questions across SharePoint, ServiceNow, Confluence, and other systems. Existing source permissions should be honored. A central workplace interface is acceptable.


Existing Q customer: Q Business or transition to Amazon Quick is the likely winner. Connector breadth, permission-aware retrieval, subscriptions, citations, and workplace experience align well.


Greenfield customer: Evaluate Amazon Quick against custom Bedrock. Building an entire assistant may be unnecessary unless sources, permissions, UX, or workflows exceed the packaged boundary.


AI Support Feature Inside a Multi-Tenant SaaS Product


Need: Each customer accesses its own documentation, cases, and product state. The assistant lives inside the application's UI, respects tenant tiers, emits product analytics, and may perform actions.


Likely winner: Custom Bedrock RAG.


The workload needs product-native authentication, tenant isolation, routing, UI components, per-tenant configuration, cost attribution, release control, and API integration. A workforce subscription model is not the natural boundary.


Executive Knowledge and Research Workspace


Need: Leaders search enterprise documents, analyze business information, and move from research to actions or BI.


Likely winner: For greenfield deployment, evaluate Amazon Quick because AWS positions it as the evolution of Q Business with research, insights, and automation. Use custom Bedrock if research requires proprietary sources, specialized methods, a custom experience, or a product-specific audit trail.


Regulated Case or Evidence Review


Need: Users work on matters, claims, investigations, or clinical cases with dynamic permissions, strict purpose limitations, versioned evidence, and reproducible decisions.


Likely winner: Custom Bedrock RAG or a rigorously tested managed/hybrid architecture.

Source ACLs may not fully express case assignment, consent, legal hold, jurisdiction, or purpose of use. The application may need policy decisions before every retrieval, immutable source versions, evidence manifests, and human approval.


Product Documentation Assistant for Public or Known Users


Need: Customers ask questions on a public website or inside a product. Sources are mostly public documentation. The experience must match brand and product analytics.


Likely winner: Custom Bedrock for a strategic product feature; a managed embedded assistant may fit a bounded existing deployment. New Q Business availability must be checked because historical pricing examples are not proof that new enrollment remains possible.


Agent that Searches, Analyzes, and Executes Transactions


Need: The system combines documents with CRM data, SQL, inventory, pricing, calculators, and write actions under per-user policy.


Likely winner: Custom or hybrid Bedrock architecture.


A knowledge-base product can serve as one retriever, but the broader system requires explicit tool contracts, policy enforcement, approval, idempotency, recovery, and transaction logs. These are application responsibilities.


Security Review: The Questions a CISO Will Ask


Neither option is “secure by default” at the completed-solution level. AWS secures the underlying cloud infrastructure; the customer remains responsible for configuration, data, users, application behavior, and compliance obligations. See Security in Amazon Q Business and the corresponding AWS shared-responsibility guidance.


Identity and Document Permissions


For Q Business, verify:

  • IAM Identity Center or federation configuration.

  • User and group synchronization behavior.

  • Connector ACL and identity crawling support for every source.

  • Public-document behavior when ACLs are absent.

  • Content and ACL re-sync interval.

  • Denied-user and revoked-user tests.

  • Application subscription removal and offboarding.


For custom Bedrock RAG, verify:

  • Token validation, issuer, audience, expiry, and claims.

  • Principal-to-tenant mapping.

  • Application, retriever, datastore, and tool authorization.

  • Filter injection prevention.

  • Cache keys that include the full authorization context.

  • Cross-tenant and cross-role negative tests.

  • Service-role least privilege and confused-deputy controls.


Encryption and Network Paths


Amazon Q Business encrypts sensitive data at rest and supports a customer-managed symmetric KMS key for the application environment; it uses HTTPS for data in transit. Review Q Business data encryption. Its security documentation also covers interface VPC endpoints and data protection.


A custom Bedrock design must enumerate encryption and network settings for Bedrock, the knowledge or vector store, source buckets, queues, databases, caches, secrets, logs, backups, and application runtime. More control means a larger configuration and evidence surface.


Enterprise-Only Answers and General Model Knowledge


Current Q Business documentation says direct access to general LLM knowledge is enabled by default for application environments created after October 31, 2024, although administrators can disable it. If policy requires answers only from approved enterprise sources, configure and test that behavior explicitly. See Using the Q Business web experience.


Custom Bedrock applications must implement the equivalent evidence rule themselves: require citations, check evidence sufficiency, distinguish model knowledge from retrieved claims, and refuse or escalate when authoritative support is absent.


Prompt Injection and Tool Safety


Treat connected documents, web pages, emails, and third-party content as untrusted input. An instruction found inside a retrieved document should not override system policy or authorize a tool.


For both options:

  • Restrict what sources can enter the index.

  • Scan or classify content where risk warrants it.

  • Separate data from instructions in prompt design.

  • Require authorization again at tool execution.

  • Use confirmation for consequential writes.

  • Limit tool parameters and validate outputs.

  • Test indirect prompt injection and data-exfiltration attempts.

  • Log decisions without exposing secrets or unnecessary sensitive content.


Residency and Cross-Region Processing


Do not equate an application Region with the only Region in which processing can occur. Q Business documents cross-Region inference behavior, and Bedrock models and inference profiles can have their own routing semantics. Validate residency with current service documentation and AWS support for regulated workloads.


The Economics: Per-User Product vs. Component Consumption


The pricing models express the product boundary.


Amazon Q Business Cost Shape


At the time of review, the Amazon Q Business pricing page lists:

  • Lite and Pro user subscriptions.

  • Starter and Enterprise index capacity charged by index unit and hour.

  • Separate processing charges for supported images, audio, and video.

  • Consumption bundles for certain anonymous embedded Chat or ChatSync use cases.

  • User-subscription rules involving first use, prorating, cancellation timing, tier, application environment, and identity-provider configuration.


The page currently lists specific dollar prices, but this guide does not hard-code them into the decision because pricing, eligibility, and successor packaging can change. Use the live page and obtain an AWS quote for the deployment date.


Q Business TCO includes:

User subscriptions
+ index units and media processing
+ connector and identity administration
+ source governance and permission cleanup
+ security review and evaluation
+ adoption, training, support, and change management
+ plugins and downstream application costs
+ transition or migration work

Per-user pricing can be attractive when it replaces substantial engineering and delivers broad employee value. It can be inefficient if subscriptions are assigned widely but monthly active use remains low. Track adoption by user cohort, not only total licensed users.


Custom Bedrock RAG Cost Shape


Custom TCO includes:

Model input and output tokens
+ embedding and reranking
+ knowledge-base retrieval or vector-store capacity
+ ingestion, parsing, queues, storage, compute, network, APIs, caches
+ observability, security, backups, and evaluation
+ application engineering and user experience
+ search relevance, platform operations, and on-call
+ reindexing, model changes, incidents, and migration

Custom usage can align cost more directly to requests, tokens, storage, and infrastructure rather than seats. However, the absence of a per-user license does not make the architecture cheaper. One dedicated platform team can dominate the three-year cost.


Use current Amazon Bedrock pricing and the pricing pages for every selected data and application service.


A Simple Three-Year Decision Model


Model low, expected, and high cases for:

  • Eligible users, subscribed users, monthly active users, and questions per active user.

  • Corpus documents, extracted text, images, audio, video, and monthly change.

  • Retrieval, reranking, input tokens, output tokens, and peak concurrency.

  • Number of applications, environments, accounts, and Regions.

  • Connector maintenance and source onboarding.

  • Initial engineers and steady-state platform/on-call staffing.

  • Evaluation, red teaming, audit, and incident response.

  • Adoption, workflow integration, and support.

  • Product transition or platform exit.


Then calculate:

Cost per active user
Cost per successfully completed task
Cost per trusted answer
Cost per deflected support request
Three-year cash cost
Three-year engineering capacity consumed
Risk-adjusted business value

The best architecture is not the one with the lowest cost per query. It is the one with the lowest cost per acceptable business outcome at the required risk level.


Existing Q Business Customers: Stay, Extend, Transition, or Migrate


An existing customer has four rational choices.


Stay and Optimize


Choose this when Q Business meets user, security, quality, and cost requirements and AWS support aligns with the planning horizon.


Actions:

  • Confirm service and commercial terms with AWS.

  • Audit subscriptions against active-user metrics.

  • Tune connector schedules and permission synchronization.

  • Configure enterprise-only versus general-knowledge behavior deliberately.

  • Review plugin scope and downstream authorization.

  • Build a representative accuracy and authorization regression suite.

  • Export or preserve evaluation data, source manifests, and decision records.


Extend Through Supported APIs and Integrations


Choose this when the index and retrieval experience are valuable but users need a different channel or limited integration.


Validate whether supported embedding, Chat/ChatSync, data-accessor, plugin, or workplace integration capabilities meet the need. Avoid building so much custom logic around a packaged product that you inherit both the constraints of Q Business and the operations of custom RAG.


Adopt Amazon Quick Using the Existing Q Index


AWS currently says existing Q Business customers can leverage an existing Q index with Amazon Quick. This may be the preferred roadmap for workforce research, insights, and automation. Treat it as a new product evaluation, not an automatic upgrade assumption.

Confirm:

  • Feature and Region availability.

  • Identity and permission continuity.

  • Index reuse and migration behavior.

  • User packaging and pricing.

  • Data processing and residency.

  • Integrations, actions, analytics, and governance.

  • Support and rollout timeline.


Migrate Selected Workloads to Custom Bedrock RAG


Choose this when a measured requirement falls outside the product boundary or when product strategy requires a customer-owned application.


Do not migrate everything at once. Segment workloads:

  • Keep broad internal knowledge discovery on the managed path.

  • Move customer-facing or domain-specific experiences to custom Bedrock.

  • Reuse governed sources and stable identifiers.

  • Run shadow retrieval against real query traffic.

  • Compare permissions, citations, quality, latency, and cost.

  • Cut over by cohort or use case with rollback.


This avoids converting a product-lifecycle concern into a rushed, high-risk platform rewrite.


Greenfield Buyers: The Decision Has Changed


For a new customer after the Q Business cutoff, the decision sequence should be:

  1. Confirm the desired outcome. Is this a workforce assistant, a research and automation workspace, or a custom product feature?

  2. Evaluate Amazon Quick for the packaged-workplace outcome. Verify current features, Regions, identity, pricing, and transition terms directly with AWS.

  3. Evaluate Bedrock Managed Knowledge Base for a custom application with standard retrieval. This often offers a lower-operations middle ground.

  4. Use customer-managed or fully custom retrieval only where the benchmark proves that extra control matters.

  5. Record lifecycle and exit assumptions for the selected architecture.


AWS's broader RAG selection guidance historically recommends starting with the highest-level managed option that fits before building a custom retriever. The principle remains sound even though the named product path has evolved.


The Middle Ground Most Teams Miss


You do not have to choose between an entire packaged assistant and a completely hand-built search stack. A common 2026 architecture is:

Custom product UX and identity
        ↓
Custom application policy and orchestration
        ↓
Bedrock Managed Knowledge Base for documents
        + structured APIs and tools
        ↓
Selected Bedrock foundation model
        ↓
Custom citations, evaluation, feedback, and monitoring

This preserves product ownership while delegating ingestion and retrieval infrastructure. See the implementation companion, How to Build Enterprise RAG with Amazon Bedrock Knowledge Bases.


A 30-Day Evidence Plan Before You Commit


Week 1: Define the Outcome and Gates


Create:

  • Three high-value user journeys.

  • A source and permissions inventory.

  • Required Regions and residency path.

  • Quality, latency, freshness, and availability thresholds.

  • Threat model and action-risk classification.

  • User and traffic scenarios for cost.

  • Product-lifecycle assumptions.


Week 2: Build Production-Shaped Candidates


Use difficult content, not only clean PDFs:

  • Tables, scans, diagrams, attachments, and long documents.

  • Duplicate and superseded versions.

  • Exact identifiers and domain terminology.

  • Restricted, revoked, and cross-tenant content.

  • Unsupported-source samples.

  • No-answer and conflicting-source cases.


Make the candidates comparable. Use the same user journeys, expected evidence, answer criteria, and source versions.


Week 3: Test Quality, Security, and Operations


Measure:

  • Recall@K, MRR or nDCG where retrieval details are available.

  • Authoritative evidence coverage.

  • Answer correctness, faithfulness, completeness, and citation support.

  • Permission-positive, permission-negative, and revocation behavior.

  • Prompt-injection and malicious-document resistance.

  • p50, p95, and p99 response latency.

  • Ingestion failures, deletion propagation, throttling, and recovery.

  • User task completion and qualitative trust.


For an evaluation design, use Codersarts' RAG accuracy methodology and separate retrieval failures from generation failures.


Week 4: Model Economics and Record the Decision


Produce an architecture decision record with:

  • Existing-customer or greenfield status.

  • Pass/fail gate results.

  • Feature and Region limitations.

  • Evaluation data and confidence.

  • Security findings and accepted risks.

  • Three-year low, expected, and high TCO.

  • Staffing and on-call ownership.

  • Selected architecture and rejected alternatives.

  • Transition and migration triggers.

  • Next review date.


The output should allow another architecture board to reproduce why the decision was made.


Red Flags in Vendor and Internal Proposals


Challenge any proposal that:

  • Recommends Q Business to a new customer without addressing the July 2026 onboarding notice.

  • Treats Amazon Quick as a simple rename without validating feature, price, and migration implications.

  • Compares Q Business subscriptions with only Bedrock token charges.

  • Calls Bedrock RAG “fully managed” while omitting the application, identity, evaluation, and operations work.

  • Claims custom RAG is more accurate without a representative benchmark.

  • Assumes a connector supports every source field, ACL, deletion, and freshness requirement.

  • Uses source ACLs to explain dynamic transaction or tenant authorization without a policy model.

  • Treats guardrails or a system prompt as access control.

  • Enables plugins without reviewing which users can invoke them and how downstream APIs authorize actions.

  • Ignores the Q Business setting that may allow general model knowledge.

  • Ignores cross-Region inference in a residency-sensitive workload.

  • Measures only thumbs-up feedback and not authoritative evidence retrieval.

  • Has no behavior for insufficient or conflicting evidence.

  • Has no owner for subscriptions, index capacity, relevance, evaluation, or user adoption.

  • Promises easy migration but cannot preserve source IDs, permissions, test data, or answer history.

A current product name and a successful demo are not an enterprise architecture decision.

Frequently Asked Questions


Is Amazon Q Business the same as Amazon Bedrock?


No. Q Business is a managed enterprise assistant built using AWS generative AI capabilities, including Bedrock. Amazon Bedrock is a platform for building custom generative AI applications and agents with selectable supported models and services. One is a packaged application; the other is a builder platform.


Can new customers still sign up for Amazon Q Business in August 2026?


AWS's current product and API notices state that Q Business is no longer open to new customers after the end of July 2026. Confirm eligibility with AWS because wording and dates should be checked at procurement time. New customers should evaluate Amazon Quick for the successor workplace experience.


What happens to existing Amazon Q Business customers?


AWS currently says existing customers can continue using Q Business or leverage their existing Q index with Amazon Quick. Existing customers should confirm commercial terms, support horizon, feature roadmap, and migration mechanics with their AWS account team.


Does Amazon Q Business let us choose the LLM?


No. AWS's RAG selection guidance states that customers cannot choose the LLM used by Q Business. A custom Bedrock application can select among supported Bedrock foundation models and implement task-specific routing.


Can Q Business respect SharePoint, Confluence, or other source permissions?


For supported connectors, Q Business can crawl document ACL and identity information and filter responses according to mapped end-user access. Support varies by connector and configuration, and changes depend on re-synchronization. Test grants, denials, group changes, and revocations using the actual source.


Is custom Bedrock RAG always more expensive?


No. It can be cheaper for some usage profiles and more expensive for others. Q Business uses user-subscription and index economics; custom Bedrock uses component consumption plus engineering and operations. Compare three-year cost per successful business outcome, not only cost per query.


Can Q Business be embedded in our application?


Q Business documents web experiences, APIs, integrations, data accessors, and embedded or anonymous pricing scenarios. Availability and fit depend on account status, identity, required UI, and current product direction. A strategic customer-facing feature usually benefits from custom Bedrock control.


Does Q Business eliminate the need for RAG evaluation?


No. Product analytics and hallucination metrics help operate the service, but the organization still needs a representative golden dataset, expected evidence, domain review, permission-negative cases, adversarial tests, and acceptance thresholds.


Are Q Business guardrails the same as Amazon Bedrock Guardrails?


They belong to different product boundaries. Q Business provides administrative controls for its application experience. Custom Bedrock applications can use Bedrock Guardrails and add application-specific retrieval, tool, policy, and output controls. Neither replaces authorization.


Which is better for multi-tenant SaaS?


Custom Bedrock RAG is usually the more natural fit because the application can propagate tenant identity, select pooled or isolated storage, enforce product tiers, attribute costs, and expose tenant-specific UX. The decision still requires a formal isolation model and negative testing.


Can we use Q Business for search and Bedrock for a custom workflow?


Potentially, using supported APIs or index-access patterns, but validate the exact integration, entitlements, commercial model, lifecycle, and latency. Avoid an architecture that inherits two platforms' costs and constraints without a clear ownership boundary.


Should an existing Q Business customer migrate immediately?


Not merely because the product path changed. First confirm AWS support and successor options, measure current adoption and quality, identify actual gaps, and compare migration cost and risk. Migrate by workload when evidence shows a better outcome.


How do Amazon Quick and Q Business relate?


AWS describes Amazon Quick as the next evolution of Q Business and says existing Q Business customers can use their current service or leverage an existing Q index with Quick. Treat Quick as the current greenfield product evaluation and verify its live documentation rather than assuming exact feature parity.


The 2026 Recommendation


For an existing Amazon Q Business customer, stay on the managed path when it delivers trusted workforce answers, broad connector coverage, acceptable actions, strong adoption, and sustainable economics. At the same time, obtain a documented Amazon Quick transition plan and preserve an exit path. Move selected workloads to custom Bedrock only when product, security, quality, or economic evidence justifies it.


For a greenfield buyer, Q Business is no longer the default procurement option because AWS has closed it to new customers. Evaluate Amazon Quick for a packaged workforce assistant. Evaluate custom Bedrock RAG when you are building a differentiated application, serving external users, enforcing application-specific authorization, choosing models and retrievers, or orchestrating domain workflows.


For many teams, the best custom architecture is not fully custom retrieval. It is a custom application using a Bedrock Managed Knowledge Base, selected tools, strict authorization, and an evaluation pipeline. This preserves control where users experience it while avoiding unnecessary search infrastructure.


The decision rule is simple:

Buy the workplace outcome when the packaged boundary fits. Build on Bedrock when the application boundary is part of your advantage or control obligation. In 2026, verify that the product you intend to buy is still open to you.

How Codersarts Helps Enterprises Choose and Implement the Right AWS Path


Codersarts helps organizations evaluate Amazon workplace AI products and design production RAG applications on Amazon Bedrock. We begin with user journeys, enterprise sources, identity, authorization, evaluation data, Regions, and operating constraints—not a predetermined vector database.


Our RAG development services can include:

  • Q Business estate and transition assessment.

  • Amazon Quick versus Bedrock architecture evaluation.

  • Production-shaped proof of concept and comparative benchmark.

  • Bedrock Managed or customer-managed Knowledge Base implementation.

  • Custom ingestion, chunking, metadata, retrieval, reranking, and citations.

  • Employee, customer-facing, and multi-tenant application development.

  • Identity propagation, source permissions, policy enforcement, and security tests.

  • Custom tools, agent workflows, approvals, and enterprise API integrations.

  • Golden datasets, RAG evaluation, adversarial testing, and regression pipelines.

  • Infrastructure as code, observability, load testing, cost modeling, and migration.


Our AI development services, AI agent development services, and LLM evaluation and benchmark engineering support the surrounding application and governance layers.

Discuss Your AWS Enterprise Assistant Architecture


Bring us your current Q Business status, source inventory, identity model, top user journeys, and ten representative questions. We can turn them into a decision scorecard and a measurable managed-versus-custom proof of concept.




Official AWS References

Editorial note: Product availability, names, transition terms, Regions, features, quotas, models, and pricing can change. Revalidate the official AWS notices before publication and during every architecture or procurement review.

 
 
 

Comments


bottom of page