Which fits your situation: Amazon Q Business or Onyx for permission-aware AI search
If you already run Amazon Q Business, the first question is continuity, not features. AWS has closed Q Business to new customers and points existing users toward Amazon Quick, so a team that depends on the service today must decide whether to stay on the AWS path or move its assistant to a platform it operates. If you have no Q Business footprint and need permission-aware search over company content under your own control, Onyx is the self-hosted option to evaluate first, because it syncs source-application permissions and runs inside your own cloud account, data centers or air-gapped network. Keeping Q Business in place is reasonable when your identity, data and workflows are already deeply tied to AWS and you accept a frozen feature set.
The decision turns on five points. The first is identity: Q Business relies on IAM Identity Center, while Onyx offers SSO through Google OAuth, OIDC or SAML and SCIM provisioning, so confirm which identity provider actually governs access to each connected source. The second is data residency, where you should map exactly where the index, database and model calls sit for each option. The third is model choice, since Onyx works with self-hosted models through Ollama, LiteLLM or vLLM as well as hosted providers. The fourth is your appetite for running a stack, which means a Postgres, search index, Redis and model-serving footprint for Onyx. The fifth is the Q Apps and guardrails your team depends on, because those features do not carry over one-for-one and must be inventoried before any migration date is set.
Before choosing, ask AWS in writing what support, security fixes and data retention terms apply to your Q Business application through its remaining life, and ask the same of Amazon Quick if that is your alternative path. Then list every data source, plugin and workflow in use, and test whether permissions in each source appear unchanged in both candidate systems using a sample of restricted documents. Where the answer is unclear, treat it as an open risk in your plan rather than an assumption. Your engineering and compliance leads should own that inventory, and DeployOpen can help plan and document the implementation if you choose the self-hosted route.
Which option fits which scenario
This table matches common team situations to the better fit, Amazon Q Business or a self-hosted Onyx deployment, and gives the reason for each. Read each row against your own identity, network, content and model requirements, since a managed AWS service remains the better choice for some teams.
| Scenario | Better fit | Reason |
|---|---|---|
| Current Q Business user with IAM Identity Center | Stay on Q Business only if AWS still supports your account, otherwise evaluate Onyx | Q Business is tied to IAM Identity Center. Onyx instead uses SSO through Google OAuth, OIDC or SAML plus SCIM, so you must map your Identity Center groups to Onyx roles and test them before cutover. |
| Index must stay in your own VPC or air-gapped network | Onyx | Onyx documents an air-gappable deployment where the index, database and processing run in a self-contained set of services. Confirm the exact network isolation steps with Onyx and your security team for your environment. |
| Managed service with minimal operations | Amazon Q Business or Onyx Cloud | Self-hosting makes your team responsible for upgrades, backups, scaling and index health. If that staffing is not available, AWS managed operations or Onyx Cloud is the better fit. |
| Heavy SharePoint, Confluence or Salesforce content | Onyx | Onyx ships connectors for SharePoint, Confluence and Salesforce and syncs source permissions. Validate permission sync on your largest sites and spaces before you rely on it for access control. |
| Need choice of self-hosted or proprietary models | Onyx | Onyx works with self-hosted models through Ollama, LiteLLM or vLLM and with providers such as Anthropic, OpenAI and Gemini. Q Business model options are set by AWS, so check the current list before deciding. |
| Need AWS-native governance and billing consolidation | Amazon Q Business | Teams already standardized on AWS accounts, CloudTrail and consolidated billing may value fewer moving parts. Self-hosting adds a separate stack to monitor and secure. |
| Migration from a frozen AWS feature set | Onyx | AWS now offers only fixes for Q Business, so features will not expand. Onyx is actively developed as open source, which lets you track changes and contribute, though you must test each release yourself. |
Where the data and the index live under each option
The two products place your documents, index and access rules in different places. Amazon Q Business runs as an AWS-managed service, while Onyx runs inside infrastructure you choose. The cards below cover the decisions that follow from that difference.
AWS-managed service boundary
Amazon Q Business is a managed AWS service, so the application, its index and its connector sync run in AWS-operated infrastructure. Your team configures the application and its data sources but does not operate the index or the database behind it. Before a renewal or migration, confirm with AWS which region the application and index use, what content is stored, how long it is kept, and what can be deleted on request.
Onyx in your own infrastructure
Onyx runs in your own cloud account or data center. Its document index, database and processing run within a self-contained set of services, deployable with Docker, Kubernetes, Helm or Terraform. Your team owns the Postgres database, the index engine, Redis and the model servers, so the location of every component is a decision you record in your architecture file.
Air-gapped operation and model traffic
Onyx documents an air-gappable deployment and works with self-hosted models through Ollama, LiteLLM or vLLM. Air-gapping only holds if the connectors can reach their sources on your network and the model servers never call an external provider. Ask your team to test outbound traffic from the index, workers and model servers, and to confirm which connectors need network paths to SharePoint, Confluence or Salesforce.
Identity and permission boundaries
Amazon Q Business ties identity to IAM Identity Center. Onyx supports SSO through Google OAuth, OIDC or SAML, SCIM user provisioning and role-based access control in its enterprise features. Onyx also syncs source permissions, so answers draw only on documents the user can already see in the source application. Test a sample of restricted documents with users from each group before cutover.
Audit and query history
Onyx lists usage analytics and query history auditing among its enterprise features, which are part of the self-hosted Enterprise Edition. Decide who may read query history, how long it is retained, and whether it is exported to your SIEM. For Amazon Q Business, document which AWS-side logs cover administrative changes and user activity, and how your team would obtain them during an investigation.
Compliance evidence ownership
DeployOpen prepares controls, configurations and evidence for compliance assessments in your Onyx environment. DeployOpen does not issue audit reports or attestations. Independent auditors and certification bodies do that work. Ask any implementation partner, including DeployOpen, to define the evidence set and its scope in writing, and confirm early which assessor will review it.
What the Onyx license and editions mean for your team
Start with the license, because it decides which features you can run without a paid agreement. Onyx Community Edition is MIT licensed and covers retrieval-augmented generation, AI chat, agents and actions. Code in the ee directories falls under the Onyx Enterprise License instead, so the repository is not uniformly permissive. Before you build a plan around the community code, open the Onyx LICENSE file and check which directories and features your intended deployment touches. Have counsel confirm that reading against your own use, including internal distribution, hosting for business units and any customization you plan to make.
Onyx is available in three forms: self-hosted open source, Onyx Cloud as a managed service, and a self-hosted Enterprise Edition. The Enterprise Edition adds premium features such as role-based access control (RBAC), and Onyx's README also lists SCIM provisioning, usage analytics and query history auditing among its enterprise features. Those controls matter in this comparison because Amazon Q Business gives you administrative controls through AWS. If your team needs fine-grained roles for who can manage connectors, see query history or administer assistants, confirm with Onyx which of these sit in the community code and which require the Enterprise Edition, and get that answer in writing before you compare costs.
Treat the edition decision as part of the migration scope, not an afterthought. Ask Onyx to map each control your current Amazon Q Business setup relies on to a specific edition, and record whether it is community, Enterprise or Cloud. Ask whether a self-hosted Enterprise Edition license carries its own recurring fee, what the term and renewal conditions are, and whether support is included. Those answers change the total cost of ownership far more than the choice of model provider, so they belong in the written scope before any infrastructure is provisioned.
What each option costs to run, by component
Amazon Q Business bundles most of its cost into AWS subscriptions and index charges, while self-hosted Onyx moves cost into infrastructure, model usage and people you control. The cards below separate one-time work from recurring spend so you can ask each vendor or partner for the same line items.
Q Business subscriptions and index charges
Amazon Q Business charges per user subscription and for index capacity, and AWS sets those rates in its pricing model. Confirm the current Lite and Pro user rates and the index unit pricing for your Region directly on the AWS pricing page or with your account team, since these change. Ask how many users fall into each tier and how index size is counted, because both scale the recurring bill. Treat this as a fully recurring line that grows with headcount and corpus size.
Onyx infrastructure and index hosting
With Onyx you pay for the compute and storage that run the stack: Postgres, the Vespa or OpenSearch index, Redis, model servers and object storage. Onyx Lite removes the vector database and background workers, which lowers the footprint for smaller teams. Cloud or on-premises hardware is recurring, and sizing depends on document volume and sync frequency. Ask your infrastructure partner for a sizing estimate based on your source count and document volume before committing.
Model usage: GPUs or API calls
Model cost depends on your choice. Self-hosted models served through Ollama, LiteLLM or vLLM require GPU capacity, which is a fixed monthly or hardware cost. Proprietary providers such as Anthropic, OpenAI and Gemini bill per token, so cost rises with query volume. Q Business bundles model usage into its subscription, so this line is new when you move. Ask for a model cost forecast based on expected daily queries and average answer length.
Storage, backups and data egress
Object storage, database backups and replicas are recurring costs that grow with indexed content and retention settings. Q Business prices index capacity inside AWS, while Onyx storage sits in your own cloud account or data center, where it is billed under your existing contracts. Check whether your backup target and retention period are included in the proposal. Ask who owns the backup schedule and how restore tests are priced, since a backup you cannot restore is not a cost saving.
One-time implementation and connector setup
Migration and initial deployment are one-time costs. They include mapping sources such as S3, SharePoint, Confluence and Salesforce, configuring SSO and SCIM provisioning, validating that permission sync matches the source systems, and replacing any Q Apps or guardrails you used. Fixed-scope engagements agree deliverables and timelines in writing before work starts. Ask for the connector list, the permission test plan and the acceptance criteria as separate line items.
Staff time, upgrades and support
Running Onyx yourself is recurring work: patching, upgrades, monitoring, on-call coverage and user support. Your internal staff or a retainer covers this, and the effort rises with the number of connectors and the frequency of Onyx releases. Q Business removes this operating load because AWS runs the service, though its feature set is currently frozen. Ask a partner whether upgrades, security patches and monitoring are included in the retainer, and what response times apply.
What moving from Amazon Q Business to Onyx involves
The sequence runs from inventorying what Q Business connects to, through rebuilding connectors and checking permissions, to a pilot, cutover and decommissioning. Each step ends with a check you can verify before moving on.
Inventory sources, users and custom plugins
Start by listing every data source the Q Business application reads, every user group that holds access, and every custom plugin, action or Q App in use. Use the AWS CLI to export the application configuration and data source definitions so the list comes from the live setup, not memory. Your team, with the application owner, records which sources are indexed, how often they sync, and which plugins call internal systems. The step is done when each source and plugin has a named owner and a yes or no decision on whether it moves.
Map identity and permission scope
Document how Q Business currently applies access rules. Q Business relies on IAM Identity Center for user identity and on the permissions of each connected source. Onyx instead uses its own SSO through Google OAuth, OIDC or SAML, with SCIM for user provisioning, and syncs document permissions from the source applications. Your identity team confirms which identity provider will feed Onyx and which groups map to Onyx roles. The step is done when every group in the inventory has a mapped role and an agreed owner for access decisions.
Reconnect sources and validate permission sync
Configure Onyx connectors for each source in scope. The Onyx repository includes connectors for sources such as SharePoint, Confluence, Google Drive, Slack and Salesforce, and you should confirm that each source you use has a current connector before you commit. Run an initial sync, then test with accounts from different groups. Check that a user sees only the documents they can open in the source application, and that restricted content stays hidden from others. The step is done when a written test list passes for every source, and failures are logged and resolved.
Choose and test models
Q Business manages its own model choices, so this is a decision you now own. Onyx supports self-hosted models through Ollama, LiteLLM and vLLM, and proprietary providers such as Anthropic, OpenAI and Gemini. Select the models that meet your data handling rules, then run a fixed set of representative questions against each candidate and score the answers for accuracy and citation quality. Confirm where prompts and retrieved content are processed, especially if you choose a hosted API. The step is done when a model is approved for each use case and the test results are archived.
Rebuild or replace Q Apps and guardrails
Review each Q App, action and guardrail against what it does for users. Onyx offers agents and actions in its Community Edition, but Q Apps and Q Business guardrails do not map one to one, so each one needs a rebuilt equivalent or a documented decision to retire it. Write down any content filtering or usage rule you must keep and implement it in Onyx or in the surrounding gateway. Confirm the outcome with the people who use each Q App. The step is done when every item is marked rebuilt, replaced or retired, with the owner's sign-off recorded.
Pilot with one user group
Choose a single user group that uses Q Business regularly and has representative sources. Run Onyx in parallel for that group, collect feedback on answer quality, missing content and access errors, and fix issues before widening access. Keep the Q Business application available during the pilot so users can compare results. Your team reviews query history and audit output in Onyx to confirm logging meets your internal policy. The step is done when the pilot group signs off on answer quality and no access errors remain open.
Cut over and retire the Q Business application
Move the remaining users to Onyx, announce the change with a clear date, and update any links, bookmarks or internal documentation that point to Q Business. Once usage has stopped, remove data source connections, delete the Q Business application and its indexes, and confirm with AWS that no residual data remains in your account. Check your records of the decommission against the inventory from the first step. The step is done when the Q Business application is deleted, its indexes are removed, and the inventory shows every item closed.
Operate and keep Onyx current
After cutover, assign an owner for connector maintenance, model updates, backups and Onyx upgrades. Onyx publishes releases and a Helm chart, so plan a routine to review release notes before each upgrade and test changes in a non-production environment first. Confirm which parts of operation your team will run and which, if any, a partner will support under a retainer. The step is done when the runbook names an owner for each area and the first scheduled upgrade review is on the calendar.
Questions buyers ask before switching from Q Business to Onyx
How much effort and time does moving from Q Business to Onyx take?
The effort depends mostly on how many sources you connect, how much content they hold, and how much identity and model work the target environment needs. Each source needs its own credential, a permission sync check, and a decision about which users and groups see it. Onyx deploys with Docker, Kubernetes, Helm or Terraform, so the platform setup itself is only one part of the work. Ask for a written scope that lists every data source, its owner, its document volume and the identity provider it depends on. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so the schedule should come from that document, not from a generic estimate. Confirm the timeline against your own environment and your number of sources.
Can an in-house team move from Q Business to Onyx without outside help?
An in-house team can do it if it already runs container platforms, manages identity, and owns the integrations that the assistant depends on. The work spans container or Kubernetes operations, Postgres, the search index, Redis, model servers, identity configuration, connector setup and ongoing upgrades. Many teams underestimate the upgrade and monitoring load, because that work recurs for as long as the system runs. A common middle path is to have an outside team plan and implement the first deployment, then move operations in-house with documentation and training. DeployOpen works on fixed-scope engagements and offers retainers for ongoing support and upgrades, so you can choose how much of the lifecycle to keep. Decide this before you commit to a timeline.
What does the move need from our identity, source owner and model teams?
The move needs decisions and access from three groups before technical work can finish:
- Identity administrators, who configure SSO through Google OAuth, OIDC or SAML, set up SCIM user provisioning if you use it, and confirm which groups map to which roles.
- Source owners for SharePoint, Confluence, Jira, Slack, Google Drive and other systems, who must grant read access for the connector service account and confirm which content is in scope.
- Model and infrastructure owners, who choose between self-hosted models through Ollama, LiteLLM or vLLM and proprietary providers such as OpenAI, Anthropic or Gemini, and who size the GPU or API spend.
Onyx supports both paths, so the model choice is a governance and cost decision as much as a technical one. Agree these owners and their deadlines in the written scope.
Do document permissions carry over from Q Business to Onyx?
Onyx connects to more than 50 applications and syncs their permissions, so answers draw only on documents the asking user can already see in the source system. That is the mechanism to rely on, but it does not replace testing. Q Business permission behavior depends on how your AWS identity and data source connections were configured, so you should not assume that every rule maps one to one. Build a test set of documents with known owners and restricted groups, then sign in as users from each group and confirm what Onyx returns. Repeat the test after each connector change and after each identity sync. Ask DeployOpen to include this test plan in the scope so that access evidence is written down before cutover.
What happens to Q Apps and guardrails when we switch to Onyx?
Q Apps and guardrails need an explicit inventory before you decide anything. List every Q App in use, its owners, the data it reads, and the actions it takes. List every guardrail or content rule that applies, and record what it blocks and why. Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions, so some workflows may map to agents in Onyx. Whether a given Q App or guardrail maps directly, or needs redesign and a separate review, depends on its logic and on how your organization enforces policy. Do not assume equivalence. Confirm each item with the workflow owner, record the decision, and send any redesigned agent through your normal risk review before users rely on it.
Is Amazon Quick a better continuity path than self-hosting Onyx?
Amazon Quick keeps the operating model closer to what you have today, because AWS runs the service. Self-hosting Onyx moves that operating responsibility to you or to your implementation partner, but it gives you control over where data and models run. Choose Quick if its current feature set covers your Q Apps, actions and guardrails, and if you accept AWS as the operator. Choose Onyx if you need the deployment to stay in your own infrastructure, need model choice, or want a project you can inspect and modify. Before deciding, ask AWS in writing which Q Business features carry over to Quick, what permission behavior changes, and what the end date for your current application is. Use those answers in the same comparison.
What do we pay for in a self-hosted Onyx stack after the move?
The cost has several components, and each one is paid to a different party:
- Infrastructure for the index, database, Redis, object storage and model servers, which recurs monthly or per usage in your cloud account or data center.
- GPU hardware or API model usage, which recurs and grows with users and query volume.
- Staff time for upgrades, monitoring and connector maintenance, which recurs.
- Implementation work and optional retainers from DeployOpen, which are one-time for the build and recurring for support.
- An Onyx Enterprise license if you need features under the Enterprise License.
Ask any quote to split these lines out, and ask what drives each one. No figures are supplied here, so use your own infrastructure prices and your Amazon Q Business invoices to build the comparison.
Does Onyx Community Edition cover everything we need, or do we need Enterprise?
Onyx Community Edition is MIT licensed and covers RAG, AI chat, agents and actions. Code in the ee directories falls under the Onyx Enterprise License, so check which features you need before you plan around the open-source edition. Onyx's documentation lists SSO, SCIM user provisioning, role-based access control, usage analytics and query history auditing among its enterprise features, and it places RBAC in the Enterprise Edition. Map each requirement from your Q Business deployment to its edition in the Onyx license and deployment documentation, then confirm the result with Onyx before you buy or build around a feature. Include the license cost, if any, in the quote so the comparison stays complete.
How to decide between a managed AWS path and a self-hosted Onyx deployment
Decide on evidence from your own environment, not on the product label. Start by writing down four inputs: the sources your users search (SharePoint, OneDrive, Confluence, Jira, Slack, S3 buckets and Salesforce are the usual candidates), the identity provider that issues your user accounts, the residency rules that govern where document content and embeddings may be stored and processed, and the model providers or self-hosted models you are permitted to use. Add a short list of must-have features, such as Actions, guardrails, custom workflows or query history auditing, and mark each one as required or nice to have. Without this list, any comparison of Amazon Q Business, Amazon Quick and Onyx turns into a feature checklist that favors whoever wrote it.
Then pilot both paths against a representative source set using real user accounts, not administrator accounts. Pick several sources with deliberately mixed sharing: a restricted HR folder, a Confluence space limited to one team, a Jira project with customer data and a shared drive open to everyone. For each source, have test users from different groups ask questions whose correct answers they should and should not be able to see. Record every answer that leaks content outside the user's permissions, and check whether group changes and removed access propagate after a sync. Confirm with AWS how Amazon Q Business and any Amazon Quick bridge handle ACL inheritance, and confirm with Onyx how its permission sync behaves for each connector you selected, since connector coverage varies by source. Measure ingestion time, answer quality on your own questions and the operator effort each path demands, and let those results drive the decision.
How DeployOpen helps evaluate, implement or migrate to Onyx
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Amazon Q Business vs Onyx, the work starts with a written scope that tests your permission model and connectors before any production cutover.
How we scope
- Inventory your current Amazon Q Business data sources, identity setup and user groups before choosing a target design
- Define which connectors, such as SharePoint, Confluence or Salesforce, must map to Onyx permission sync
- Agree deliverables, timelines and exclusions in writing before any work begins, since most engagements are fixed-scope
- Confirm model hosting choices, including self-hosted models through Ollama, LiteLLM or vLLM or hosted providers
How we build
- Deploy Onyx in your own environment with Docker, Kubernetes, Helm or Terraform, matching your existing platform standards
- Connect SSO through OIDC or SAML and configure SCIM provisioning against your identity provider
- Test that search answers draw only on documents each test user can already see in the source application
- Harden the deployment and document configuration, access roles and backup procedures for your security team
How we hand over
- Deliver runbooks covering architecture, upgrades, connector maintenance and incident response for your operators
- Provide evidence of permission tests, access configuration and logging that your compliance team can use in assessments
- Walk through role-based access control and query history auditing with administrators who will run the platform
- Document open-core licensing boundaries so your team knows which features fall under the Onyx Enterprise License
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan version upgrades against the Onyx release notes and Helm chart changes before applying them to production
- Repeat permission and connector tests after each upgrade or new data source is added
- Confirm with your team which support scope, response expectations and review cadence fit your operating model
