They share a brand and a security model and almost nothing else. Amazon Q Developer is an AI coding assistant for engineers; Amazon Q Business is an enterprise assistant that answers questions over your company's own data. This page settles the confusion: what each one is, who it's for, how their capabilities, data sources, and pricing differ, whether you can run both at once, and a pick-by-role decision table so you choose the right one the first time.
The confusion is structural, not your fault. AWS shipped two genuinely different products under one brand, and the marketing sentence for "Amazon Q" describes both at once — so people reasonably assume they're tiers or editions of a single thing. They are not.
AWS describes Amazon Q as the assistant for "accelerating software development and leveraging your enterprise data." Read it again: that one sentence is actually two products bolted together. "Accelerating software development" is Amazon Q Developer. "Leveraging your enterprise data" is Amazon Q Business. They are not Basic-and-Premium tiers of the same assistant — they are separate services, with separate consoles, separate pricing pages, separate documentation, and separate buyers.
The brand collision creates real, expensive mistakes. A team that buys "Amazon Q" expecting a coding assistant and lands on Q Business gets an enterprise RAG tool that has never seen their repo. A CIO who pilots "Amazon Q" for company-wide knowledge search and accidentally provisions Q Developer ends up with an IDE plugin nobody outside engineering can use. The wrong choice means the wrong pilot, the wrong budget line, the wrong success metric, and weeks lost before anyone notices the mismatch.
The good news: once you know the one axis that actually separates them, the decision is fast and rarely ambiguous. That axis is data source — what each product reads to do its job. Q Developer reads your code and your AWS account. Q Business reads your enterprise content (documents, tickets, CRM records, wikis) through connectors. Almost every "which one?" question collapses the moment you ask "what does it need to read?"
This page is built for the person who already knows both products exist and just needs to choose correctly. If you want the broad "what is Amazon Q" overview first, see the Amazon Q guide; for per-product depth, the Amazon Q Developer and Amazon Q Business pages carry it.
Building software? Amazon Q Developer — it lives in your IDE/CLI/console and reads your code + AWS account. Helping employees find and use what the company already knows? Amazon Q Business — it reads your documents, tickets, CRM, and wikis (~40+ connectors) and answers with citations under each user's permissions. Same brand and security model; different jobs. You can run both.
Before comparing them, define them cleanly. Read these two paragraphs and the rest of the page snaps into place.
The only things the two products genuinely share are the brand ("Amazon Q"), the foundation underneath (both are built on Amazon Bedrock, AWS's managed foundation-model service), and the resulting data-handling posture (your content is not used to train the base models and stays inside AWS's security boundary). Everything else — buyer, surface, data source, success metric, pricing shape — diverges.
Amazon Q Developer is an AI assistant for software engineering. It lives where engineers work: inside the IDE (VS Code, JetBrains IDEs, Visual Studio, Eclipse), the command line, and the AWS Management Console. It provides inline code completion across many languages, a chat panel for technical "how do I…" questions, and agents that go beyond autocomplete — implementing a multi-file feature from a prompt (/dev), generating unit tests and documentation, running guided code transformations and language/framework upgrades (/transform, e.g. Java version migrations), and scanning code for security vulnerabilities.
Its defining trait is AWS awareness: it can reason about your AWS account and architecture and help diagnose console errors, which a generic coding assistant cannot. Its data source is your codebase plus your AWS account context — not your company's documents. Its buyers are engineering leaders, platform teams, and individual developers, and its success is measured in accepted-suggestion rate, time-to-merge, and reduction in boilerplate and upgrade toil.
Amazon Q Business is an enterprise assistant that answers questions over your company's own content. It is a fully-managed retrieval-augmented generation (RAG) application: you connect data sources — Microsoft SharePoint, OneDrive, Salesforce, ServiceNow, Confluence, Jira, Slack, Google Drive, Amazon S3, and roughly forty-plus others — Q indexes them, and employees ask natural-language questions and get synthesized answers with citations back to the source documents. It surfaces as a web app, an embeddable intranet widget, browser extensions, and Slack/Teams — never an IDE.
Its defining trait is permission-aware retrieval: at index time it ingests each document's access-control list (ACL), and at query time — after identifying the user through IAM Identity Center — it retrieves only content that user is already entitled to see. Its data source is your enterprise content via connectors, not your code. Its buyers are CIOs, IT, knowledge-management, and internal-operations teams, and its success is measured in deflected support tickets, time-to-answer for employees, and adoption across departments.
Data source. Q Developer reads your code + AWS account to help you ship software. Q Business reads your enterprise content (documents, tickets, CRM, wikis via ~40+ connectors) to help employees find and use what the company already knows. Ask "what does it need to read?" and the choice is almost always obvious.
The two products do not overlap in features because they don't share a job. Here is what each one actually does, mapped so you can see there is essentially no functional middle ground.
A useful way to read the contrast: Q Developer's capabilities are all about producing and changing artifacts (code, tests, docs, upgrades), while Q Business's capabilities are all about finding, synthesizing, and acting on existing knowledge (answers, summaries, actions in connected systems). Neither does the other's job — Q Developer cannot answer "what's our refund policy?" from a Confluence page, and Q Business cannot write a unit test for your repo.
| Capability | Q Developer | Q Business |
|---|---|---|
| Inline code completion | Yes — across many languages in the IDE | No |
| Multi-file feature implementation (agents) | Yes (/dev) | No |
| Unit test + documentation generation | Yes | No |
| Code transformations / version upgrades | Yes (/transform) | No |
| Code security scanning | Yes | No |
| Answer questions over company documents | No | Yes — RAG with citations |
| Connect to enterprise data sources | No (reads code + AWS account) | Yes — ~40+ connectors |
| Permission-aware retrieval (per-user ACLs) | N/A | Yes — enforced at retrieval |
| Take actions in other systems (plugins) | Limited (AWS ops via chat) | Yes — Jira/ServiceNow/Salesforce, custom APIs |
| No-code internal apps | No | Yes (Q Apps) |
| AWS account / architecture awareness | Yes | No |
This is the axis that resolves almost every "which one?" question, so it deserves its own section. The two products read fundamentally different things, and that difference is the whole reason they exist as separate services.
Confusing the data sources is the root of most wrong choices, so it is worth being precise about what each product can and cannot see.
Q Developer's context is the code you're working in and the AWS environment around it. In the IDE it uses your open files and project to ground completions and chat; with workspace indexing it can reason across a larger local codebase to implement features and answer repo-specific questions. In the console and CLI it is AWS-aware — it can reason about your account's resources, explain errors, and guide configuration. What it does not do is connect to SharePoint, Salesforce, Confluence, or your document stores; it has no concept of your company's policy PDFs or CRM records.
The practical implication: Q Developer needs no connector setup, no index, and no document-permission mapping. Its "data plumbing" is the IDE/CLI/console integration and (for org rollout) IAM Identity Center for license and policy management. That is why a developer can install the extension, sign in with a free Builder ID, and be productive in minutes.
Q Business's context is your enterprise content, reached through managed connectors. Each connector crawls a source system (S3, SharePoint, OneDrive, Google Drive, Box, Confluence, Notion, Slack, Teams, Gmail, Salesforce, ServiceNow, Jira, Zendesk, RDS/Aurora, a web crawler, JDBC for arbitrary databases, and more), extracts text and metadata, and — critically — ingests each document's ACL so permissions follow the data into the index. For sources without a native connector, you can push documents in via the custom data-source / BatchPutDocument API.
The practical implication is the inverse of Q Developer: Q Business is a data-integration project, not a code tool. The value (and the risk) lives in the connector configuration, index sizing, and permission mapping. Done right, employees ask one question and get a cited answer drawn from across all those systems — limited to what they're allowed to see. Done carelessly, a misconfigured ACL mapping can over-share, which is exactly why the rollout includes a permission-verification pilot. For the build-vs-buy view of this retrieval layer, see Bedrock Knowledge Bases and RAG on AWS.
Q Developer is context-aware of your engineering surface (code + AWS account) and needs no data setup. Q Business is context-aware of your company's knowledge (documents/tickets/CRM via connectors) and is fundamentally a data-integration effort with permissions at its core. The setup effort is wildly different precisely because the data sources are.
Both are per-seat with a free or low entry point, but the shapes differ — Q Business has an extra cost line (the index) that Q Developer doesn't. Figures below are representative as of 2026; always confirm current rates on the AWS pricing page.
Amazon Q Developer uses a simple two-tier model. The Free tier gives individual developers inline suggestions, chat, and a capped number of agent interactions and security scans per month at no cost. The Pro tier is roughly $19 per user per month and adds higher limits, organization-wide license management through IAM Identity Center, policy controls, and higher caps on the agentic features and scanning. Some heavy agent actions (for example large-scale code transformations) can carry additional usage-based charges beyond the seat fee. There is no separate "index" cost — Q Developer doesn't maintain a corpus.
Amazon Q Business has two seat tiers plus an index cost. Q Business Lite is about $3 per user per month for read-only conversational Q&A — suited to broad, light user populations. Q Business Pro is about $20 per user per month for the full feature set: plugins and actions, app creation (Q Apps), and Amazon Q in QuickSight. Separately, you pay for the index capacity that stores and serves your data, sized to document volume and query throughput. So a Q Business bill = (seats × tier) + (index capacity). You can mix tiers within one application to control blended seat cost.
The structural takeaway for budgeting: Q Developer cost scales mostly with headcount of engineers × seat; Q Business cost scales with headcount × tier plus how much data you index. Teams modeling Q Business routinely forget the index line — for a small deployment it's modest, but for an enterprise indexing millions of documents it becomes a meaningful share of total cost. If you run both products, they are billed entirely independently; there is no bundle discount for having both.
| Pricing element | Q Developer | Q Business |
|---|---|---|
| Free / entry tier | Free tier (capped usage) | Lite ~$3/user/mo |
| Full tier | Pro ~$19/user/mo | Pro ~$20/user/mo |
| Extra data/storage cost | None (no corpus) | Index capacity, billed separately |
| Usage-based add-ons | Heavy agent actions may add charges | Inference bundled; connector/data transfer bills normally |
| What cost scales with | Engineer headcount × seat | Headcount × tier + indexed document volume |
| Can mix tiers in one deployment | Free + Pro by user | Lite + Pro within one application |
A frequent follow-up once the difference clicks: "do we have to choose?" No. Because they're separate products doing non-overlapping jobs, running both is the normal end-state for a company that has both engineers and knowledge workers.
There is no technical conflict and no licensing barrier to running Amazon Q Developer and Amazon Q Business simultaneously. They're provisioned independently, billed independently, and administered through the same identity backbone (IAM Identity Center), which actually makes running both easier — your engineers get Q Developer seats, the broader organization gets Q Business seats, and both authenticate against the same federated identity provider (Okta, Microsoft Entra ID, Ping).
The typical pattern in an organization that adopts both: engineering standardizes on Q Developer (often Free for trial, Pro for the team rollout) to accelerate shipping and automate upgrades; everyone else — support, sales, ops, HR, finance, legal — gets Q Business to answer questions over company knowledge, with a Lite/Pro mix by role. The two never compete for the same use case, so there's no overlap to rationalize.
There is a small grey zone worth naming: developers also have company knowledge needs (architecture decision records, runbooks, internal policies) that live in Confluence/SharePoint rather than the codebase. That's a Q Business job, not a Q Developer one — so in a both-products org, engineers may hold a Q Developer seat and a Q Business seat. That's expected, not redundant: one reads their code, the other reads the company's documents. Budget for it rather than trying to force one tool to do both.
Provision Q Developer for engineers and Q Business for knowledge workers; both authenticate through the same IAM Identity Center / IdP. Billing is fully separate (no bundle), and some people legitimately need a seat in each — Q Developer for their code, Q Business for the company's documents. Coexistence is the designed end-state, not a workaround.
If the data-source axis didn't already decide it for you, pick by who's asking and what they're trying to do. The rule of thumb: match the product to the job, then license per role rather than per company.
Start from the role. If the user writes or maintains software, it's Q Developer. If the user needs answers from company knowledge, it's Q Business. A single company usually has both kinds of user, which is why "pick one for the whole org" is the wrong frame — you pick per role. The scenarios below cover the cases that trip people up.
Find the row that matches your situation, read the recommendation. This is the scannable version of everything above.
If a single role wants outcomes from more than one row across both products, that's your signal to run both — read it as a "both" answer, not a tie to break.
| Your situation | Who the user is | What they need to read | Pick | Why |
|---|---|---|---|---|
| Speed up coding, tests, upgrades | Engineers / platform | Code + AWS account | Q Developer | Completion, agents, /transform, security scans |
| Answer questions over company docs | Support / ops / HR / legal | Enterprise content (connectors) | Q Business | Permission-aware RAG with citations |
| Cut new-hire ramp / ticket volume | Knowledge workers | Wikis, tickets, CRM, files | Q Business | One question across many systems |
| Take actions from chat (tickets, CRM) | Knowledge workers | Connected business systems | Q Business Pro | Plugins + custom APIs (OpenAPI) |
| Reason about AWS resources/errors | Engineers / DevOps | AWS account context | Q Developer | AWS-aware console + CLI assistant |
| Both engineers AND knowledge workers | Whole company | Code AND enterprise content | Both | Non-overlapping jobs; billed separately |
| Engineers who also need internal docs | Engineers | Code AND company knowledge | Both (per seat) | Q Developer reads code; Q Business reads docs |
The single table to bookmark. If you remember nothing else from this page, remember that these two columns describe different products — and the row that decides it for you is almost always "primary data source."
| Dimension | Amazon Q Developer | Amazon Q Business |
|---|---|---|
| Primary job | Write, fix, test & upgrade code | Answer questions over your company data |
| Primary data source | Your codebase + AWS account | ~40+ enterprise connectors (RAG) |
| Typical buyer | Engineering / platform leaders | CIO / IT / knowledge management |
| Where it runs | IDE, CLI, AWS console, dev chat | Web app, intranet widget, Slack/Teams |
| Signature features | /dev, /transform, test gen, security scan | Permission-aware RAG, plugins, Q Apps |
| Permission model | IAM Identity Center for org licensing | Per-user ACL retrieval via IAM Identity Center |
| Pricing | Free / Pro ~$19/user/mo | Lite ~$3 / Pro ~$20 per user/mo + index |
| Closest competitors | GitHub Copilot, Cursor | Microsoft 365 Copilot, Glean, ChatGPT Enterprise |
| Data used to train base models? | No | No |
| Setup effort | Install extension; minutes to start | Connector + index + permission project |
Situation: The engineering org had rolled out Amazon Q Developer themselves and loved it — but leadership then tried to extend "Amazon Q" to the rest of the company for knowledge search and discovered Q Developer does nothing of the sort. Support, sales, and ops still hunted across Confluence, Salesforce, Zendesk, and S3 for answers, and a half-configured attempt at an enterprise assistant had stalled because nobody internal owned the connector-and-permissions work or was confident the HR/finance content in SharePoint wouldn't leak. They needed Q Business stood up correctly — and wanted AWS to fund it.
What CloudRoute did: CloudRoute confirmed the split in the first call: keep Q Developer for engineering (already working, no change), add Q Business for everyone else. Routed within a day to a Germany-based AWS Advanced partner with IAM Identity Center + Q Business experience. The partner filed a Bedrock/GenAI proof-of-concept credit application ($25K) with Activate Portfolio credits behind it for the surrounding AWS spend, federated identity to the company's Entra ID, stood up one Q Business application across Confluence, Salesforce, Zendesk, and S3, mapped ACLs, set topic guardrails, and ran a permission-verification pilot proving restricted users could not retrieve HR/finance documents. Support went on Q Business Pro (for Zendesk plugin actions); the rest of the company went on Lite.
Outcome: Q Business live in 17 days alongside the untouched Q Developer deployment. Cross-system answer time dropped sharply; new non-engineering hires stopped filing "where do I find…" tickets. 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: ~2.5 weeks to live · IT time: ~10 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 Amazon Q Business safely — while your engineers keep Q Developer. AWS funds the build via credits. Customer pays $0.