The situation
A platform team of a dozen engineers wants two things at once. The first is to move faster day to day: less time writing boilerplate, faster answers to “how does this service work”, quicker unit tests, and a hand with a stalled Java 8 to Java 17 upgrade that nobody has time to finish. The second is a product ask from the business: the company’s customer portal should gain a natural-language assistant that answers questions about a customer’s own account, drafts replies, and summarises recent activity, all grounded in the company’s private data.
The proposals in the room have multiplied. One engineer would point everything at Amazon Bedrock, because Bedrock has the models. Another has been using Kiro on a side project and wants seats for the whole team, but is not sure whether it covers the portal work too. A third saw Amazon Quick demoed at a conference and cannot say how it differs from either of the others, only that it also answers questions with an AWS logo on it.
The two needs look similar because both involve a generative model, but they sit on opposite sides of a line. One is about making the engineers who build the product faster. The other is a feature the product itself has to ship. Choosing the wrong shape for either means building something AWS already sells finished, or trying to bend a finished assistant into a product it was never meant to be.
What actually matters
The distinction that decides everything is finished product versus building block. A finished assistant is something you switch on and use: no application to design, no retrieval pipeline to wire, nothing to operate. A platform is the opposite by design: it provides model access and building blocks, and you assemble the application around them. The two answer different questions, so ranking one above the other leads nowhere. Sort by who the output is for.
If the output is for your own engineers, and the value is that they write, understand, test, and modernise code faster, a finished developer assistant is the fit and building anything is wasted effort. If the output is for your customers, embedded in your product, shaped by your data and your rules, you are building an application and need a platform underneath it. And if the output is for your own staff asking questions across internal documents and systems, that is a third audience with its own finished product, easily misfiled as either of the other two.
The audience frame also keeps the three products from competing when they should compose. The natural arrangement for this team is the developer assistant helping write the code for the Bedrock application that becomes the portal feature. The assistant makes building faster; the platform is what gets built. Reaching for one does not rule out the others.
Cost and effort follow the split. The finished assistants are per-user subscriptions, some with a monthly allowance of agent work on top of the seat: pay for seats, productive the same day. The seat is not always the whole bill, though. An Amazon Quick account provisioned through AWS carries a USD$250 per-account monthly infrastructure fee on top of the per-user price, and Enterprise accounts meter agent hours at USD$3 an hour beyond the plan’s allowance. Bedrock is usage-priced on tokens and features, and carries the cost of designing, building, evaluating, and operating an application. One is an operating expense you switch on; the other is a project you staff. Be aware, too, that service names in this area change fairly frequently; the three roles are the stable thing.
What we’ll filter on
- Who is the output for, your own engineers, internal staff, or your product’s end users?
- Finished product or building block, something to use today or a platform to build on?
- Subject matter, source code and AWS, or your own enterprise and customer data?
- Customisation depth, does the value depend on your prompts, your data, your guardrails, and your interface?
- Complementary fit, could one tool build the thing another tool ships?
The landscape
Kiro. The developer assistant: an agentic development environment spanning an IDE, a CLI and a browser interface, built for spec-driven development, where work starts from a specification that Kiro writes as three files, requirements.md, design.md and tasks.md, and the agent plans against rather than from a blank completion. It fills the finished-product role for engineers: you install it and use it, with nothing to design and no retrieval pipeline to operate. A developer can pick which model answers, but only inside the assistant; there is no surface to put in front of a customer. It sells as a per-user monthly subscription with a monthly credit allowance for agent work, above a perpetual free tier.
Amazon Q Developer. The other finished assistant aimed at engineers. It sits in the AWS console and documentation site, in chat applications, and in IDE plugins, rather than in a spec-first environment of its own. In the console it answers questions about your own AWS resources and costs, diagnoses common console errors, and opens a Support conversation without leaving the page. It also helps with code written against the AWS SDKs and the AWS CLI. In the IDE it chats about code, completes lines, scans for security vulnerabilities, and runs Java language upgrades as transformation jobs, taking a Maven project from Java 8 or 11 to Java 17 or 21 and handing back a diff to accept. One caveat governs all of that IDE work: AWS discontinues support for the Amazon Q Developer IDE plugins on 30 April 2027 and points the same capabilities at Kiro, so a team choosing today should read Q Developer as the console-side assistant. The upgrade work has its own successor: AWS Transform custom carries an AWS-managed AWS/java-version-upgrade transformation that takes any build system from any source JDK to any target JDK, with dependency modernisation alongside, and it runs from the AWS Transform CLI, an IDE plugin, or as a Power inside Kiro. AWS charges nothing extra for AWS Transform. Both Q Developer and Kiro sell developer productivity, and neither is a platform.
Amazon Quick. A finished, managed assistant whose user is an employee and whose subject is enterprise data rather than code. Knowledge bases index content from S3, SharePoint, OneDrive, Confluence, Google Drive and web crawlers. Connectors built from OpenAPI specifications or MCP servers let it read and act in other systems, and extensions put it inside Chrome, Slack, Teams and Microsoft 365. Access control comes in two layers. Sharing a knowledge base decides who may use it at all, and AWS calls that control coarse-grained. On top of it, an ACL-aware knowledge base enforces the source documents’ own permissions, so each authorised user retrieves only the documents they can already see at the source; S3, Google Drive, SharePoint, Confluence Cloud and OneDrive support it. Whether a knowledge base is ACL-aware is fixed when it is created and cannot be turned on or off afterwards, which makes it a design decision rather than a setting. Permission changes arrive on the refresh schedule, every 24 hours by default. It goes past answering, too: Quick Flows automate repetitive tasks, Quick Automate builds the multi-step business-process automations, Quick Sight is the BI side that turns questions into dashboards, and Spaces gather the documents, dashboards and datasets an agent draws on. It fits when the job is an internal, cross-source assistant for staff. It is not a developer tool and not a platform.
Amazon Q Business and Amazon Q Apps. The same staff-assistant role under the earlier name, and closed off now: Amazon Q Business is no longer open to new customers, existing customers get bug fixes and security updates but no new features, and AWS directs the work to Quick. Q Business was the managed enterprise-RAG assistant: connect the wikis, mailboxes, ticket systems and document stores, ask a question in plain language, get an answer grounded in those sources and filtered by what the asker is allowed to see. Amazon Q Apps were the small, purpose-built applications someone in the business built on that connected data without writing code, and they migrate to Quick Flows. Read all of these names as one role, staff assistant over enterprise data, and start anything new on Quick. Whether the managed assistant covers the need at all is a separate call, weighed against building the retrieval application yourself.
Amazon Bedrock. The platform, not an assistant. API access to hundreds of foundation models, from Amazon, Anthropic, OpenAI, xAI and others, behind one interface, plus the machinery an application needs: knowledge bases for retrieval over your own data, guardrails that filter content and check responses against their sources, and model customisation. Agents have moved: Amazon Bedrock Agents is now Bedrock Agents Classic and is closed to new customers, so an agent that plans and calls tools is built on Amazon Bedrock AgentCore instead. You bring the use case, the prompts, the data, and the interface. It is where a customer-facing feature gets built, because that feature needs your data, your rules, and your product’s surface, none of which a finished assistant exposes.
Evaluation
Side by side
The first two columns are the developer assistants and sit together; they differ in shape, not in who they serve.
| Attribute | Kiro | Amazon Q Developer | Amazon Quick | Bedrock |
|---|---|---|---|---|
| Finished product you use | ✓ | ✓ | ✓ | ✗ |
| Building block you develop on | ✗ | ✗ | ✗ | ✓ |
| Audience is your own developers | ✓ | ✓ | ✗ | ✗ (whoever you build for) |
| Audience is internal staff | ✗ | ✗ | ✓ | ✗ (whoever you build for) |
| Powers a feature in your product | ✗ | ✗ | ✓ (embedded Quick Sight only) | ✓ |
| Works with source code and AWS | ✓ | ✓ | ✗ | ✓ (if you build it) |
| Grounds answers in your own data | ✗ | ✗ | ✓ | ✓ (you configure it) |
| Model and prompts yours in a shipped product | ✗ | ✗ | ✗ | ✓ |
| Time to value | Same day | Same day | Days | A build project |
| Pricing shape | Subscription plus credits | Free and Pro tiers per user | Per-user seat, plus a per-account fee and metered agent hours | Usage, tokens and features |
The solution
The developer-productivity half of the situation is a clean finished-assistant case, and the tell is that every item on the list is about the engineers, not the product. Boilerplate, questions about how a service works, unit tests, and the Java upgrade are all things a finished assistant does out of the box, and building any slice of that on Bedrock would mean reconstructing a supported product. So the team adopts Kiro: same-day seats, and boilerplate, service questions and unit tests are what a spec-driven agent is built for. Write the spec, let it plan the changes, review the diffs. The Java 8 to 17 upgrade has a purpose-built route rather than a hand-written spec: install the AWS Transform Power in Kiro and run the managed AWS/java-version-upgrade transformation, which handles the dependency modernisation that a language bump drags along. Amazon Q Developer covers the same half of the situation from the console side, answering questions about AWS resources and diagnosing console errors, and its IDE plugin can still run the Java upgrade as a transformation job of its own. That IDE path has an end date of 30 April 2027, though, so a team standing this up now starts on Kiro. Either way, nobody builds anything.
The customer-portal half is a clean Bedrock case, and the tell is the opposite: the output is for end users, it must be grounded in the company’s private customer data, and it lives inside the product’s own interface with the company’s own rules about what it may say. No finished assistant exposes that combination. Building it on Bedrock means choosing a foundation model, grounding answers through a knowledge base so replies cite real account activity, configuring guardrails that filter responses against policy, and wiring it into the portal. It is a build-and-operate project, priced on usage, and that is the correct shape for a feature the company ships to customers.
Amazon Quick is the pick for neither half, and it is the easiest of the three to misfile. Its audience is internal staff over enterprise data, so it is not the developer tool. Nor is it the portal feature, though the reason needs stating carefully, because one part of Quick does reach into your own application: Quick Sight embeds dashboards, visuals and its Generative Q&A experience into a page you own, and GenerateEmbedUrlForAnonymousUser does it for readers who have no Quick identity at all. What that embeds is a natural-language layer over Quick Sight datasets and topics. It will not draft a reply, it will not answer from the company’s documents, and it gives you no model choice, no prompts and no guardrail configuration. For a BI panel inside the portal it is a real option; for the assistant the business asked for it is not. If the company later wants an internal assistant for employees to query the wiki and the document store, or to automate the workflows that follow those answers, Quick becomes the right answer to that separate question.
The part that ties the situation together is composition. The team does not choose an assistant instead of Bedrock; it uses the assistant to build the Bedrock application. The engineers lean on Kiro to write the portal feature’s code, generate its tests, and stand up its infrastructure, and the thing they are building is the Bedrock-backed assistant the customers will use. The productivity tool and the platform sit at different layers and work together.
Worked example
Picture the team’s backlog with each item tagged by the single question of who the output is for.
“Cut the time it takes to scaffold a new microservice” is for the developers, so it is the finished assistant: hand Kiro the spec and let it plan and generate the scaffold. “Finish the Java 17 upgrade on the billing service” is for the developers too: the managed AWS/java-version-upgrade transformation, run from Kiro, planned by the agent and reviewed by the team. “Add a natural-language assistant to the customer portal that answers account questions” is for end users and needs the company’s data and interface, so it is the Bedrock build: model plus knowledge base plus guardrails behind the portal. “Generate the unit tests the billing upgrade needs” is for the developers again, the assistant’s job, ideally right after the migration while the changes are fresh.
Then the one that looks ambiguous. “Let customer-support staff ask questions across our internal runbooks and past tickets” is not for developers and not for the product’s end users; it is for internal staff over enterprise data. That is the Amazon Quick shape, a separate finished assistant for a separate audience, and recognising it keeps it from being mis-sorted into either a Bedrock build or a developer seat.
The backlog sorts itself once each item answers the who-is-it-for question first. Everything aimed at the engineers collapses onto a finished assistant with no build. The one feature aimed at customers is the Bedrock project. The internal-staff item lands on the third product.
What’s worth remembering
- Finished product or building block. Kiro and Amazon Quick are assistants you use; Bedrock is a platform you build on.
- Sort by audience. Your engineers point to Kiro, internal staff to Amazon Quick, and your product’s end users to a Bedrock build.
- Assistants rarely ship. Only Quick Sight embeds in your product, as a BI Q&A panel; none gives you model choice, prompts or guardrails.
- The products compose. The team uses the developer assistant to build the Bedrock application its customers will use.
- Check the retirement dates. Amazon Q Business takes no new customers, and Q Developer IDE plugins lose support on 30 April 2027.
- Learn roles, not labels. Developer assistant, staff assistant and build platform stay stable while product names close and move.