Two teams asked me the same week to ‘set up Amazon Q’ and meant two completely different products. One wanted an HR and IT assistant that answers staff questions from SharePoint and Confluence. The other wanted an AI pair-programmer in VS Code. Same brand, different service, different console, different bill.
That confusion is the first thing to clear up, and in mid 2026 there is a second twist: the developer side of Amazon Q is being folded into a new product called Kiro. If you start a new IDE rollout on Q Developer today, you are building on something with a published end date. This part maps both products, prices them with real numbers, and gives you a build order that survives the transition.
Two products, one name
Amazon Q is a brand, not a single service. Under it sit two products that share almost nothing operationally. Amazon Q Business is a managed assistant that indexes your enterprise content and answers questions with citations and permission checks, so a user only sees answers drawn from documents they are allowed to read. Amazon Q Developer is a coding assistant that lives in your IDE and command line, does code completion, chat, and agentic tasks like framework upgrades, and also appears inside the AWS Management Console to help you operate AWS itself.
They are provisioned separately, billed separately, and administered by different teams in most organisations. Q Business is bought by an IT or knowledge-management group and wired to content sources. Q Developer is bought by an engineering group and wired to repositories. Confusing them wastes weeks, because the person who owns your SharePoint connectors is rarely the person who owns your Java upgrade backlog.
There is now a third box on the map. Kiro is AWS’s new agentic development environment, built for spec-driven development, and it is where the Q Developer IDE experience is heading. So when you say ‘Amazon Q’ in a planning meeting, name the product: Q Business, Q Developer, or Kiro. The diagram below is the version I sketch on a whiteboard before any of these conversations start.
What Amazon Q Business actually does
Q Business connects to your content sources, builds a searchable index, and gives users a chat interface that answers from that content with citations. The part that earns its keep is permission awareness. When a user asks a question, Q Business filters retrieval to documents that user can access in the source system, so a contractor does not get answers pulled from a board deck. That access mapping comes from your identity provider through IAM Identity Center, which is the single-sign-on layer AWS uses across accounts.
There are two seat tiers, and the split matters more than the price gap suggests. Lite at 3 dollars per user per month covers question and answer over your knowledge bases, file upload in chat, permission-aware responses, and browser extensions. It does not include plugins. Pro at 20 dollars per user per month adds Q Apps, which are small shareable task apps, plus built-in and custom plugins for systems like Salesforce, Jira, and ServiceNow, content generation, and Amazon Q in QuickSight for data questions. If a user needs to take an action, file a ticket, submit time off, or trigger a workflow, they need Pro. Pure question and answer stays on Lite.
One more note for planning. AWS has said the next evolution of Q Business is Amazon Quick Suite, an agentic teammate that can turn answers into actions, and existing Q Business customers keep their index and can reuse it there. That does not change what you buy today, but it tells you the roadmap is toward action, not just retrieval. Here is how the two tiers compare on the features people actually ask about.
| Capability | Lite, 3 dollars per user | Pro, 20 dollars per user |
|---|---|---|
| Q and A with citations | Yes, about one page | Yes, about seven pages |
| Permission-aware retrieval | Yes | Yes |
| Plugins, built-in and custom | No | Yes |
| Q Apps | No | Yes |
| Q in QuickSight, Reader Pro | No | Yes |
| Slack and Teams integration | No | Yes |
How indexing and pricing add up
Seats are only half the bill. You also pay for index capacity, and this is where budgets get surprised, because the index charges the moment it exists, whether or not you have loaded a single document. There are two index types. A Starter index runs in one Availability Zone, costs 0.140 dollars per hour per unit, and caps at five units per application, which makes it right for a proof of concept. An Enterprise index runs across three Availability Zones, costs 0.264 dollars per hour per unit, and supports customer managed key encryption, which is what you want in production. Each unit holds up to 20,000 documents or 200 megabytes of extracted text, whichever comes first, plus 100 hours of connector sync time per month.
Run the Enterprise number and it is easy to hold in your head. One unit at 0.264 dollars per hour across 24 hours and 30 days is about 190 dollars per month. So a corpus of 40,000 documents needs two units, roughly 380 dollars per month, before you count a single seat. Media adds line items too: 0.003 dollars per image, 0.006 dollars per audio minute, and 0.050 dollars per video minute at ingestion.
Put seats and index side by side for a mid-size rollout and the shape is clear. Seats dominate, index is the minority of the bill, and the trap is buying Pro for everyone when most of your users only ask questions. The chart plots the worked example below.
Worked example
A 600 person company runs one Q Business application. 500 frontline staff on Lite at 3 dollars is 1500 dollars per month. 100 knowledge workers who need plugins go on Pro at 20 dollars, which is 2000 dollars. The corpus is 40,000 documents, so two Enterprise index units at about 190 dollars each add 380 dollars. Total is about 3880 dollars per month. Move all 600 to Pro and seats jump to 12,000 dollars, a 3.4 times increase for a feature set most of them will not touch. Tier by actual need.
| Index type | Price per unit hour | Availability Zones | Best for |
|---|---|---|---|
| Starter | 0.140 dollars, max 5 units | 1 | Proof of concept, dev |
| Enterprise | 0.264 dollars, adds CMK | 3 | Production workloads |
Wiring Q Business to your data
A Q Business deployment is three moving parts: an application tied to an identity source, an index sized to your corpus, and connectors that sync content and carry access-control lists so permission filtering works. Get identity right first. If you wire the application to IAM Identity Center, seats deduplicate: a user subscribed to several Q Business applications that share the same Identity Center instance is charged once, at their highest tier. If you use IAM federation instead, the user is charged once per identity provider, so five applications behind five providers means five charges for the same person. That single design choice can double or halve a seat bill.
The application and index are a few API calls. Here is the create path with the AWS CLI, the output you should expect, and the two ways it usually fails.
# Create the application with IAM Identity Center as the identity source
aws qbusiness create-application
--display-name 'hr-it-helpdesk'
--identity-center-instance-arn 'arn:aws:sso:::instance/ssoins-7207abcd1234'
--role-arn 'arn:aws:iam::111122223333:role/QBusinessAppRole'
# Expected output
{
"applicationId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE",
"applicationArn": "arn:aws:qbusiness:us-east-1:111122223333:application/a1b2c3d4..."
}
# Size an Enterprise index to two units, about 40,000 documents
aws qbusiness create-index
--application-id 'a1b2c3d4-5678-90ab-cdef-EXAMPLE'
--display-name 'main-index'
--type ENTERPRISE
--capacity-configuration 'units=2'Failure mode one: if the role trust policy does not allow qbusiness.amazonaws.com to assume it, create-application returns AccessDeniedException. Failure mode two: if the Identity Center instance is in a different region than the application, you get a ValidationException. Both cost an afternoon if you find them after wiring connectors, so validate the role and region before you index anything.
Q Developer is moving into Kiro
Now the part that changes your roadmap. Amazon Q Developer is the coding side: Free tier with 50 agentic requests and 1,000 lines of transformation per month, or Pro at 19 dollars per user per month with higher limits, admin controls through Identity Center, and IP indemnity. It does completion, chat, and agentic jobs like upgrading a repository from Java 8 to Java 17 across many files. It has been good at that work.
AWS is retiring the IDE side of it. Kiro is the replacement, an agentic development environment built for spec-driven development, where you write structured requirements and the agent plans and implements against them, with hooks that run on save or commit, steering files that hold project context, and custom subagents. The published timeline is specific. New Q Developer signups are blocked from 15 May 2026. From 29 May 2026, Opus 4.6 is no longer offered on Q Developer Pro, and the newest coding models, including Opus 4.7, are exclusive to Kiro. The Q Developer IDE plugins and paid subscriptions reach end of support on 30 April 2027. Existing subscribers keep IDE access until that date, and the plugins stay listed with a deprecation notice pointing to Kiro.
My read: do not start a new IDE-plugin standardisation on Q Developer in 2026. You would be onboarding a tool that stops taking new signups within weeks and loses its best models first. Pilot Kiro for new work, and keep existing Q Developer users where they are until you have a migration window. The timeline below is what I put in front of engineering leads.
My take
If you are greenfield on IDE assistants, go straight to Kiro and skip Q Developer plugins entirely. If you already run Q Developer Pro, you have until 30 April 2027, but plan the move now while the migration guide is fresh and your reps still have context. The one thing I would not do is buy new Q Developer seats in 2026 for a multi-year rollout.
Console and chat apps outlive the sunset
The sunset is narrower than the headline suggests, and this is the detail people miss. Only the Q Developer IDE plugins and their paid subscriptions are ending. Amazon Q Developer inside the AWS Management Console, on the AWS documentation and marketing sites, in the Console Mobile App, and in the Q Developer chat apps for Slack and Microsoft Teams is not affected. Those first-party experiences keep working, and your existing subscription benefits carry over in them.
So the operational assistant that explains a failed CloudFormation stack or answers a billing question in the console stays exactly where it is. What is changing is only the in-editor coding tool, and only for the IDE plugins. If your teams mostly use Q Developer to reason about AWS in the console rather than to write code in VS Code, this transition barely touches you. Keep that distinction in your rollout notes so nobody rips out the console assistant thinking it is going away.
Where Q Business earns its seat, and where Kiro takes the IDE
Here is the call I give customers. Amazon Q Business is worth buying now if you have content scattered across SharePoint, Confluence, ServiceNow, and file shares and you want permission-aware answers without building retrieval yourself. Start on Lite for the population that only asks questions, reserve Pro for the minority who need plugins, Q Apps, or QuickSight, and size the Enterprise index to your real document count rather than a round number. Wire it to IAM Identity Center on day one so seats deduplicate and access filtering is clean.
On the developer side, treat Q Developer as a product in managed decline for IDE use and let Kiro carry new work. The console and chat-app assistants stay, so you lose nothing there. If you want the vendor-neutral view of how permission filtering and grounding actually keep an assistant honest, the guardrails part of the GenAI series pairs well with this one. Next in this series I move from buying assistants to judging them, with model evaluation on Bedrock. Price your own rollout with the worked example above before you commit a single seat, then tell me where your split between Lite and Pro lands. In practice the split that works is Lite for the everyday questions and Pro held back for the long, multi-document reasoning that Lite fumbles. Routing on question type rather than sending everything to Pro is where the real saving lives.
References
- Amazon Q Business pricing, seats and index units
- Amazon Q Business subscription tiers and index types
- Amazon Q Developer end-of-support announcement
- Kiro, the agentic development environment
About The Author
DrJha