Do You Lose Document-Level Permissions Migrating to Amazon Quick?

Most migration write-ups focus on connectors and pricing. This one is about the thing that will actually stop your rollout in a security review, and it is buried deep in AWS's migration guide where a lot of people will not reach it.

If you are moving from Amazon Q Business to Amazon Quick, the access control model changes, and in one common configuration it changes in a way that silently widens who can read what. That is worth understanding before you connect anything, not after.

The one question that decides everything: are you on IAM Identity Center?

AWS splits the migration path in two, and this is the fork.

If you use IAM Identity Center, you are in good shape. AWS calls this "the most straightforward path" and notes that the identity infrastructure carries forward into Quick. Access to a Bring Your Own Index knowledge base "is automatically granted only to users with access to the selected Q Business index," and adding users beyond that requires deliberate admin configuration in both consoles. Subscriptions are deduplicated across applications sharing the same Identity Center instance, so each user is charged once at their highest tier. Nothing widens by accident.

If you use IAM federation, native identities or AWS Managed Microsoft AD, read AWS's sentence carefully, because it is doing a lot of work: "In a non-IDC implementation, all Amazon Quick users automatically receive access to connected Q Business indexes."

Every Quick user. All connected indexes. AWS states the consequence directly: "you lose the per-user and per-group access distinctions that Q Business enforced at the index level."

What that actually means in practice

Picture a Q Business deployment where finance content was indexed and scoped to the finance group, HR content to HR, and everything else to the company. Standard, sensible, and exactly the kind of segmentation Q Business's User Store existed to manage.

Connect that index to Quick through BYOI in a non-Identity-Center configuration and every Quick user can query all of it. Nobody misconfigured anything. That is the documented default behavior. The permissions did not fail; they stopped being applied at that layer.

This is the kind of change that does not announce itself. Search still works. Answers still come back. They are just drawn from a wider corpus than the person asking should be able to see, and unless somebody deliberately tests with a restricted account, the first sign of trouble is an employee quoting a compensation band or an unannounced reorg back to you.

How do I restore per-user permissions in Amazon Quick?

AWS documents the remedy, and it is architectural rather than a setting. You segment content into multiple knowledge bases organized by access level, then restrict each knowledge base's sharing permissions to the appropriate groups within Quick Spaces.

So instead of one index with per-user ACLs inside it, you build one knowledge base per access tier and control access at the knowledge base boundary. AWS provides a Python script that exports Q Business user and group ACL mappings and generates corresponding Quick permission assignments, walking through list_data_sources, then list_groups per data source, then folder permission updates on the Quick side.

Three things to weigh before you plan around this:

It is coarser. A knowledge base boundary is not a document ACL. Anything requiring genuinely per-document access within a shared corpus does not map cleanly to this model, and you will find yourself creating knowledge bases to represent permission combinations.

It multiplies with complexity. Distinct access patterns become distinct knowledge bases. Organizations with matrixed access, where a document is visible to one department plus two project teams plus a compliance group, generate a lot of knowledge bases quickly.

It is now yours to maintain. Permissions used to be inherited from the source system, which meant they stayed correct when someone changed teams. In this model, drift between your source systems and your knowledge base sharing rules is a standing operational risk, and it is exactly the sort of thing an auditor asks you to evidence. Teams working toward SOC 2 or ISO 27001 usually end up wanting a systematic way to map controls and prove access reviews happened, because "we have a script" is not an answer that survives fieldwork.

Which sources support document-level ACLs in Quick?

Four, and AWS is clear that this "significantly narrows the access control gap" without closing it.

Each ACL entry supports Name (an email for USER, a group name for GROUP), Type (USER or GROUP) and Access (ALLOW or DENY). All ACLs resolve within the Quick namespace of whoever created the knowledge base, which is a detail worth noting when you decide who runs the setup.

The setting you cannot undo

This one deserves its own heading because it is genuinely irreversible.

ACLs must be enabled at knowledge base creation time. AWS's wording: "this setting is permanent and cannot be changed after creation." During setup you specify the global ACL file location, an S3 path to acl.json, and optionally a metadata files folder.

Create a knowledge base without ACLs, discover later that you need them, and your only option is to delete it and rebuild, re-ingesting everything. On a large corpus that is not a five-minute correction. If there is one line to take from this article into your migration runbook, it is to decide the ACL question before you click Create, every single time, even for knowledge bases you think are low-risk.

One behavior change that works in your favor

Not all of this is bad news, and the difference is worth planning for because it will look like a bug otherwise.

Quick does not ingest documents that lack an associated ACL entry. Q Business did the opposite: it granted all users access to S3 prefixes that did not appear in the ACL file. Quick's posture is stricter and, frankly, the safer default. A document nobody explicitly granted access to simply does not enter the index.

The migration consequence is real though. AWS advises that organizations "should ensure all documents have explicit ACL entries before enabling ACLs in Quick to avoid unintentional content exclusion." So content that was quietly visible to everyone under Q Business, because it fell through a gap in your acl.json, will silently vanish from Quick. Users will report that search got worse. The cause will be an ACL file that was never complete, and you will only find it by auditing coverage before you cut over.

A migration checklist for the permissions piece

Work through these in order before you connect anything to production:

1. Confirm your identity model. IAM Identity Center or not. This single fact determines whether the rest of this list is a checkbox or a project.

2. Export your current access map. Run list_data_sources and list_groups against your Q Business application and write down which groups can reach which sources today. You cannot verify a migration against a baseline you never captured.

3. Audit ACL coverage. Find every document without an explicit ACL entry. Under Q Business these were visible to everyone; in Quick they will not be ingested at all. Decide deliberately which way each should go.

4. Design your knowledge base boundaries. If you are on a non-Identity-Center setup, sketch the knowledge base per access tier map before building anything. Retrofitting this is expensive.

5. Decide ACLs at creation, always. Permanent setting, no exceptions, including for the knowledge base you are "just testing with."

6. Test with a restricted account. Not an admin account. Sign in as someone with deliberately narrow access and run queries that should return nothing. This is the only test that catches the failure mode described at the top of this article, and it is the one most teams skip.

Frequently asked questions

Does Amazon Quick Suite support document-level permissions?

For four sources: Amazon S3, Confluence Cloud, SharePoint and Google Drive. Each ACL entry supports a user or group name, a type of USER or GROUP, and ALLOW or DENY access. For connectors without native ACL crawling, AWS's documented approach is to segment content into multiple knowledge bases by access level and control sharing per knowledge base in Spaces.

Do I lose permissions migrating from Q Business to Amazon Quick?

Only in a non-IAM-Identity-Center configuration. AWS states that in that setup, all Amazon Quick users automatically receive access to connected Q Business indexes, so per-user and per-group distinctions enforced at the index level are lost. With IAM Identity Center, access is granted only to users who already had access to the selected index.

Can I enable ACLs on a Quick knowledge base after creating it?

No. AWS states that ACLs must be enabled at knowledge base creation and that "this setting is permanent and cannot be changed after creation." If you need ACLs on an existing knowledge base, you have to delete and recreate it, which means re-ingesting all of its content.

Why did documents disappear after migrating to Quick?

Most likely because they have no explicit ACL entry. Quick does not ingest documents lacking an associated ACL entry, whereas Q Business granted all users access to S3 prefixes absent from the ACL file. AWS advises ensuring every document has an explicit ACL entry before enabling ACLs to avoid unintentional content exclusion.

How do I keep per-user access control without IAM Identity Center?

By segmenting content into separate knowledge bases organized by access level and restricting each one's sharing permissions to the appropriate groups within Quick Spaces. AWS provides a Python script that exports Q Business group ACL mappings and generates the corresponding Quick assignments. It is a workable pattern, but it is coarser than document-level ACLs and becomes harder to maintain as access patterns multiply.

The alternative: permissions you never rebuild

Everything above is a consequence of one design decision, that permissions live in the search product's own model and have to be populated, mapped and maintained there. Each migration then becomes a permissions migration.

There is another way to build this. InSearch does not maintain its own copy of your access model. It reads each source's native item-level permissions and enforces them at query time, per person, on every query. When someone changes teams in Google Workspace or loses access to a Confluence space, their answers change with it, because the source is the authority rather than a synced snapshot.

That means there is no ACL file to keep complete, no permanent setting to get right at creation, no knowledge base tree encoding your org chart, and no configuration in which everyone silently receives access to everything. It also means the security review is a shorter conversation. If you are weighing the migration effort, it is worth comparing against an Amazon Quick Suite alternative and reading how permission-aware enterprise search works before you commit to rebuilding an access model by hand. Try a question in the box above.