Amazon Q Business is AWS's generative-AI assistant for the enterprise: connect it to 40+ data sources, and it answers questions, summarizes, and takes actions over your company's own content — while respecting each user's existing access permissions. This guide covers what it is, the connectors, how indexing and permission-aware retrieval actually work, building apps and plugins, the per-user pricing, admin setup, security and data handling, real use cases, and how it compares to Microsoft 365 Copilot.
Amazon Q Business is a fully-managed, generative-AI–powered assistant that answers questions, generates content, and completes tasks using your enterprise's own systems and data. Think of it as a ChatGPT-style assistant that has securely read your company's wiki, file shares, ticketing system, and CRM — and will only tell each employee what that employee is allowed to know.
There are two products under the Amazon Q umbrella, and conflating them is the single most common confusion. Amazon Q Developer is the AI coding assistant for engineers — completions in the IDE, a chat that knows AWS, agents that write tests and upgrade Java. Amazon Q Business — the subject of this page — is the enterprise knowledge assistant for everyone else: support, sales, operations, finance, HR, legal. If you came here for the coding tool, you want the Q Developer page instead.
The core problem Q Business solves is that enterprise knowledge is scattered. The answer to "what's our refund policy for EU customers?" lives in a Confluence page; the relevant Salesforce account note is somewhere else; the Slack thread where the exception was approved is a third place; the signed contract PDF sits in SharePoint. A new support agent has to know all four systems exist and have access to each. Q Business collapses that into one natural-language question and returns a synthesized, cited answer with links back to every source document.
Mechanically, Q Business is a managed retrieval-augmented generation (RAG) application. RAG means the model does not answer from its training data alone — it first retrieves the most relevant passages from your indexed content, then grounds its generated answer in those passages. This is what keeps answers current (your data, not the model's 2024 training cut-off) and what makes citations possible. The crucial difference from a raw foundation model is that Q Business builds, hosts, secures, and maintains the entire retrieval pipeline for you: the connectors, the index, the embeddings, the ranking, the access-control enforcement, and the chat UI.
Q Business is also deeply tied to AWS IAM Identity Center for identity. Users sign in with their existing corporate identity (Okta, Microsoft Entra ID / Azure AD, Ping, or any SAML 2.0 / OIDC provider federated through IAM Identity Center), and Q resolves who they are so it can enforce their permissions. This identity grounding is what separates an enterprise assistant from a consumer chatbot.
Amazon Q Business is a managed, permission-aware RAG assistant that connects to 40+ enterprise data sources, indexes them, and lets employees ask natural-language questions — returning cited answers limited to what each user is already authorized to access.
A RAG assistant is only as good as the data it can reach. Q Business ships a library of 40+ built-in connectors — managed, ACL-aware integrations that crawl a source system, pull documents and their permissions, and keep the index in sync on a schedule. You configure credentials and a sync frequency; AWS maintains the connector.
Connectors fall into rough families. File and document stores: Amazon S3, Microsoft SharePoint (Online and Server), OneDrive, Google Drive, Box, Dropbox, and Amazon WorkDocs. Wikis and knowledge bases: Atlassian Confluence (Cloud and Server), Notion, Guru, and Zendesk knowledge. Collaboration and messaging: Slack, Microsoft Teams, and Gmail. CRM and ITSM: Salesforce, ServiceNow, Zendesk, and Jira. Databases and search: Amazon RDS / Aurora, Amazon FSx, Amazon Kendra (as an existing retriever), web crawlers for public sites, and JDBC for arbitrary SQL databases.
Each connector does three things at sync time: (1) it crawls the source for documents, (2) it extracts text and metadata, and (3) — this is the part that matters most for the enterprise — it ingests the access-control list (ACL) attached to each document. A SharePoint document that's shared with only the Finance group carries that group membership into the Q index as metadata. The connector also captures field-level metadata (author, last-modified date, document type, custom fields) that can later be used for filtering and boosting.
Sync can run on a schedule (hourly, daily, custom) or on demand. Q tracks document changes incrementally after the first full crawl, so subsequent syncs only process what changed — keeping the index fresh without re-crawling everything. For sources without a native connector, you have two escape hatches: the custom document enrichment hooks (transform documents in-flight with a Lambda during ingestion) and the BatchPutDocument / custom data-source API, which lets you push documents into the index programmatically from any system you can write code against.
| Family | Example sources | ACL ingested? | Typical use |
|---|---|---|---|
| File / document stores | Amazon S3, SharePoint, OneDrive, Google Drive, Box, Dropbox | Yes | Contracts, decks, specs, PDFs |
| Wikis / knowledge bases | Confluence, Notion, Guru, Zendesk KB | Yes | Policies, runbooks, how-tos |
| Collaboration / messaging | Slack, Microsoft Teams, Gmail | Yes | Decisions, threads, tribal knowledge |
| CRM / ITSM | Salesforce, ServiceNow, Jira, Zendesk | Yes | Account notes, tickets, incidents |
| Databases / search | RDS / Aurora, FSx, Kendra, JDBC, web crawler | Varies | Structured records, existing indexes |
| Custom | BatchPutDocument API, custom data source | You supply | Anything without a native connector |
This is the section worth reading twice. Q Business's value and its safety both come from one design choice: permissions are enforced at retrieval time, per user, on every query. Understanding the pipeline tells you why a competitor can't just bolt RAG onto a chatbot and call it enterprise-ready.
The lifecycle has two phases — ingestion (happens on a sync schedule) and query (happens per question). Getting the boundary right is the whole game.
When a connector syncs, each document is chunked into passages, converted to vector embeddings, and written to Q's managed index alongside its text, its metadata, and — critically — its ACL. The ACL records which users and groups are permitted to see that document in the source system. Q does not flatten everything into one readable blob; it preserves the principal-level permissions as first-class index metadata.
Group membership is resolved through IAM Identity Center, which Q maps to the groups in your identity provider (Entra ID, Okta, etc.). So a document shared with the "EMEA-Sales" group in SharePoint is associated, in the index, with the set of users who belong to EMEA-Sales — and that mapping updates as your directory changes.
When a user asks a question, Q first identifies the user via IAM Identity Center, then retrieves candidate passages from the index filtered to only the documents that user's identity and group memberships entitle them to see. Passages the user can't access are never retrieved, never ranked, and never reach the model. The foundation model then generates an answer grounded only in that permitted, retrieved context, and returns citations to the specific source documents.
The consequence: Q cannot leak across permission boundaries. If Finance salary spreadsheets are indexed but a given engineer has no access to them in the source system, that engineer querying "what are the comp bands?" retrieves nothing from those files and gets either an answer from documents they can see or an honest "I couldn't find that." This is the property that lets you index sensitive corporate data without manufacturing a new data-exfiltration path.
Because answers are grounded in retrieved passages, Q can show its work: every response can cite the source documents it drew from, so a user can click through and verify. Admins can also tune whether Q is allowed to fall back to the model's general world knowledge when no relevant company document is found, or whether it should restrict answers strictly to retrieved enterprise content — a setting that matters a great deal in regulated environments where an ungrounded guess is worse than "not found."
Most "chat with your docs" tools index everything into one pool and trust the prompt to behave. Q Business enforces source-system permissions at retrieval, per user, per query — so the assistant inherits your existing access model instead of bypassing it. That is the difference between a demo and something legal will let you ship.
Out of the box, Q Business is a question-answering assistant over your content. But its more interesting use is as a platform: you can build branded assistant apps, wire in plugins that let it take actions in other systems, and embed the experience into your own tools.
A Q Business application is the top-level unit you create in the console: it has its own index, its own set of connected data sources, its own users and groups, and its own configuration. A large enterprise typically runs several applications — one for the support org, one for sales enablement, one for internal IT — each scoped to the right data and audience.
Plugins extend Q from reading data to doing things. With the built-in plugins, a user can ask Q to create a Jira issue, open a ServiceNow ticket, look up a Salesforce opportunity, or send a message in Microsoft Teams — directly from the chat, without leaving the assistant. Q maps the natural-language request to the right API call, asks the user to confirm the parameters, and executes the action using the connected system's credentials and the user's own permissions.
Beyond the built-ins, you can register custom plugins against any third-party or internal API by supplying an OpenAPI schema. Q reads the schema, understands the available operations, and can then invoke your endpoints as actions. This turns Q into an action layer over your internal services: "raise a deployment freeze," "fetch the current on-call," "approve this PTO request" — each backed by your own API and governed by your own auth.
You can embed the Q Business web experience into your own portal or intranet with a few lines of configuration, so employees get the assistant inside tools they already use rather than a separate destination. Q Business also offers a lightweight app-builder (often referred to as Q Apps) that lets non-developers turn a useful prompt-and-data workflow into a small shareable internal app — for example, a "draft a customer-renewal email from this account's notes" app the whole CS team can reuse.
Admins control all of this centrally: which plugins are enabled, which data sources a given application can reach, whether end users may create their own apps, and what guardrail and topic controls apply. The platform is deliberately governable, because the buyers are enterprises that need to answer "who can do what, with which data?" before rollout.
Amazon Q Business is priced per user per month on a subscription basis, in two tiers, with index storage and document-volume considerations layered on top. The headline list prices below are representative as of 2026 — always confirm against the live AWS pricing page, as AWS adjusts these.
Q Business Lite (~$3 per user per month) covers the core conversational experience: ask questions, get cited answers over connected data, basic chat. It suits large populations of light, read-only users — for example, frontline staff who occasionally look something up.
Q Business Pro (~$20 per user per month) is the full feature set: everything in Lite plus plugins and actions, the app-creation capabilities, and access to Amazon Q in QuickSight (natural-language analytics and dashboard authoring over your BI data). Pro is the tier for power users — analysts, support leads, sales engineers — who need Q to take actions and work over structured data, not just answer questions.
A subtlety many teams miss: you can mix tiers within one application, assigning Lite to the broad population and Pro to the smaller set of power users, which keeps the blended per-seat cost down. Beyond seats, you pay for index capacity — Q provisions index units, each holding a bounded number of documents and a defined query throughput; very large corpora consume more index units. There is no separate per-query LLM token bill the way there is with raw Bedrock usage; the subscription bundles the model inference. Connector data transfer and any underlying AWS resources (e.g., the S3 buckets you keep source data in) bill normally.
| Capability | Q Business Lite (~$3/user/mo) | Q Business Pro (~$20/user/mo) |
|---|---|---|
| Conversational Q&A over your data | Yes | Yes |
| Cited answers + source links | Yes | Yes |
| Document summarization | Yes | Yes |
| Plugins + actions (Jira, ServiceNow, etc.) | No | Yes |
| Custom plugins (your APIs) | No | Yes |
| Create Q Apps | Limited | Yes |
| Amazon Q in QuickSight (NL analytics) | No | Yes |
| Best for | Broad light read-only users | Power users, analysts, action-takers |
Standing up Q Business is a console-and-config exercise, not a data-engineering project — that's the point of a managed service. The sequence below is the canonical path a partner (or your platform team) follows.
The whole flow happens in the Amazon Q Business console plus IAM Identity Center, and a small pilot can be live in days rather than the months a hand-built RAG stack would take.
Step 6's permission verification is non-negotiable. Before any wide rollout, log in as users at different access levels and confirm the boundaries hold against real sensitive documents. A misconfigured connector ACL mapping is the one way Q can over-share — catch it in the pilot, not in production.
Because Q Business indexes a company's most sensitive content, AWS designed it around the data-handling guarantees enterprises require — and the same guarantees that apply to Amazon Bedrock, on which Q's model inference runs.
Your data is yours. Content you connect to Q Business is not used to train the underlying foundation models. Your queries, your documents, and the answers stay within your AWS environment and are not fed back into base-model training. This mirrors the Bedrock data-privacy posture and is usually the first question a security team asks.
Encryption and isolation. Data is encrypted in transit and at rest, with the option to use your own AWS KMS customer-managed keys for the index. Each Q Business application is logically isolated to your account, and you choose the AWS Region your data and index live in — important for data-residency requirements (EU, UK, etc.).
Identity-grounded access. As covered above, every retrieval is filtered by the asking user's identity and group memberships resolved through IAM Identity Center, so the assistant enforces your existing entitlements rather than creating a parallel access path. Admins get guardrails to block sensitive topics, control specific words/phrases, and constrain responses, plus admin controls over plugins and data scope.
Auditability and compliance. Administrative and usage activity is logged (via AWS CloudTrail and Q's own admin tooling), giving you the audit trail compliance teams need. Q Business runs within AWS's compliance envelope, and AWS publishes which compliance programs the service is in scope for (e.g., SOC, ISO, HIPAA eligibility, FedRAMP for relevant Regions) — confirm the current attestations for your specific requirement on AWS's compliance pages, as scope is updated over time.
Q Business pays off wherever employees waste time hunting across systems for answers that already exist somewhere in the company. Three patterns dominate.
Internal knowledge / employee self-service. "What's our parental-leave policy in Germany?" "Where's the approved vendor list?" "What changed in the Q3 security policy?" Q answers from HR docs, the wiki, and policy PDFs with citations — deflecting tickets from HR, IT, and ops, and onboarding new hires faster because they can simply ask instead of knowing where everything lives.
Customer support. A support agent asks Q a customer's question and gets a synthesized answer from the knowledge base, past tickets, and product docs — with sources — cutting handle time and improving first-contact resolution. With Pro plugins, the agent can also create or update the ticket in ServiceNow or Zendesk directly from the assistant.
Analytics and sales/ops enablement. Through Amazon Q in QuickSight (Pro), business users ask questions of their BI data in plain language — "show revenue by region this quarter vs last" — and get charts and narrative answers without writing SQL or pinging the data team. Sales teams use Q over Salesforce + Confluence + Slack to prep for calls and draft follow-ups grounded in the actual account history.
Versus Microsoft 365 Copilot (brief, and fair). Microsoft 365 Copilot is the natural comparison for "enterprise assistant over our data." The honest framing is a fit question, not a winner. Copilot lives inside the Microsoft 365 graph — Word, Excel, Outlook, Teams, SharePoint — and is unmatched if your work and data already live there; it's licensed per user (around $30/user/mo) on top of M365. Amazon Q Business is source-agnostic and AWS-native: it shines when your knowledge is spread across many non-Microsoft systems (Salesforce, Confluence, ServiceNow, Slack, S3, plus SharePoint), when you want a custom assistant app embedded in your own tools, when you need to take actions across third-party APIs via plugins, and when you want model inference governed inside your AWS account on Bedrock. Many organizations run both — Copilot for in-Office productivity, Q Business for cross-system enterprise search and custom assistants. Choose by where your data and your control boundary actually sit.
| Dimension | Amazon Q Business | Microsoft 365 Copilot |
|---|---|---|
| Home turf | Source-agnostic; AWS-native (Bedrock) | Microsoft 365 graph (Word/Excel/Outlook/Teams) |
| Best when your data lives in | Many mixed systems (Salesforce, Confluence, S3, ServiceNow…) | Microsoft 365 / SharePoint / OneDrive |
| Custom assistant apps + plugins | Yes — apps, custom plugins via OpenAPI | Limited; extends via Copilot/Graph connectors + agents |
| Permission model | Inherits source ACLs via IAM Identity Center | Inherits Microsoft 365 / Entra permissions |
| Indicative price | ~$3 (Lite) / ~$20 (Pro) per user/mo | ~$30 per user/mo (on top of M365) |
| Control boundary | Your AWS account + Region | Microsoft cloud tenant |
The most common rollout mistake is putting everyone on Pro (overspending) or everyone on Lite (frustrating power users who hit a wall at plugins and analytics). The right answer is almost always a mix. This is the decision matrix.
| User profile | Recommended tier | Why | Approx /user/mo |
|---|---|---|---|
| Frontline / occasional lookups | Lite | Read-only Q&A is all they need | ~$3 |
| New hires / onboarding | Lite | Self-serve answers; no actions yet | ~$3 |
| Support agents (action-takers) | Pro | Need plugins to update tickets from chat | ~$20 |
| Sales / CS enablement | Pro | Cross-system grounding + draft actions | ~$20 |
| Analysts / BI users | Pro | Amazon Q in QuickSight (NL analytics) | ~$20 |
| App builders / power users | Pro | Create Q Apps + custom plugins | ~$20 |
| Whole-company default | Lite, upgrade by need | Keeps blended seat cost low | blended |
Situation: Support agents were drowning: every non-trivial question meant searching five systems, and answers depended on tribal knowledge. New-agent ramp took ~10 weeks. Leadership wanted a permission-aware assistant over all five sources but had no in-house GenAI team, and was nervous about accidentally exposing the HR and finance content that also lived in SharePoint.
What CloudRoute did: Routed within 20 hours to a UK-based AWS Advanced partner with a Bedrock + Q Business track record. The partner filed a Bedrock/GenAI POC credit application ($25K) plus Activate credits to cover the surrounding AWS spend. They wired IAM Identity Center to the company's Entra ID, stood up one Q Business application with all five connectors, mapped ACLs, set topic guardrails, and ran a permission-verification pilot proving restricted users could not retrieve HR/finance docs before rollout. Support agents went on Pro (for Zendesk plugin actions); the rest of the company went on Lite.
Outcome: Live in 18 days. First-contact resolution up, average handle time down ~22% in the first quarter; new-agent ramp cut from ~10 weeks to ~6. All build-phase AWS consumption was credit-funded. CloudRoute's commission was paid by the partner out of AWS's engagement funding — the customer paid $0 for the routing.
engagement window: ~3 weeks to live · founder/IT time: ~12 hours · credits secured: $25K+ POC + Activate · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who connects your sources, maps permissions, and stands up Q Business safely. AWS funds the build via credits. Customer pays $0.