We are planning to use Namespaces to isolate users from differen clients. Now with the new AI features like spaces and deep research, we are worried that data in the Quick Index from one customer can be queried by another customer.
How can we ensure isolated Quick Indexes between our customers? Can we do this within one account or do we have to create a separate AWS account for each customer?
Hi @JanoschPeters and welcome to the Quick Community!
As security is always one of the driving factors as new features get implemented, namespaces are designed specifically for this requirement and they extend through the new Agentic AI features. As namespaces operate at the permissions level, they block all users from accessing information outside of their own namespace, unless provided with the proper permissions.
This can all be done within one account, no need to create separate accounts for each customer.
I’ve also included some additional information about namespaces and how they can be used to setup multitenancy!
Hi @Brett, thanks for your response.
I’d like to follow up on a couple of points. First, the Q index doesn’t appear to be mentioned anywhere in the article you linked to. Second, the page Creating an Amazon Q index on behalf of a customer states that a shared Amazon Q Business application environment is only recommended when indexing documents that are visible to all users — which suggests the Q index is shared across all users regardless of namespaces. This is what the docs say:
We recommend creating one Amazon Q Business application environment per customer for better security and data segregation. Alternatively, you can create one Amazon Q Business application environment and share it with multiple customers. This is only recommended when you index documents that are visible to all users in your application.
If that’s the case, creating a separate account per customer would significantly increase our AWS costs, which is a concern for us.
Could someone from AWS clarify whether namespace-level index isolation is supported, or confirm the recommended architecture for multi-tenant setups?
Hi @JanoschPeters,
I understand how confusion could arise from this situation, the naming conventions are not always the clearest. However, one thing to keep in mind is that Q Business is a completely separate environment from Quick Suite. It has it’s own index setup.
The documentation you shared is specifically referring to Q Business. The Quick Index feature that handles Quick Suite, respects all existing QuickSight security models, which includes the separation of assets between namespaces.
This is a public facing forum, mostly operated by other users; so the footprint by AWS team members is fairly small. If you’d like to get in contact directly with AWS, you can try creating a support ticket:
Hi @JanoschPeters ,
Just checking back in since we haven’t heard from you in a bit. I wanted to see if the guidance shared earlier helped resolve your question, or if you found a solution in the meantime.
If you still have any additional questions related to your initial post, feel free to share them. Otherwise, any update you’re able to provide within the next 3 business days would be helpful for the community.
Thank you
Hi @JanoschPeters ,
Since I haven’t received any further updates from you, I’ll treat this inquiry as complete for now. If you have any additional questions, feel free to create a new post in the community and link this discussion for context.
Thank you
I created a ticket at AWS support to clarify this issue. I am posting the key points here for the community to benefit:
QuickSight Multi-Tenant Security – Key Takeaways
1. Namespace isolation works for most features Spaces, Chat Agents, Deep Research, and Q Topics are effectively isolated through the UI — the user/group picker only surfaces identities within the same namespace, so accidental cross-namespace sharing is not possible through normal UI workflows.
2. API-level risk applies to all QuickSight assets Namespace isolation is enforced at the UI level only. Internal AWS principals (developers, CI/CD roles, Lambda functions) with overly broad quicksight:Update*Permissions (e.g. UpdateTopicPermissions, UpdateDashboardPermissions, UpdateDataSetPermissions) could explicitly grant cross-namespace access by specifying cross-namespace ARNs — bypassing UI-level isolation entirely. Note: tenant users authenticating via SSO/SAML federation are not affected, as their IAM roles should only carry QuickSight session permissions.
3. Flows “Share with all” is the main gap The “Share with all users in the account” option in Flows is account-scoped and can cross namespace boundaries. Mitigation: use Custom Permission Profiles to disable this option for all tenant users. Requires quicksight:CreateCustomPermissions / quicksight:UpdateAccountCustomPermissions. AWS recommends validating this in a non-prod environment first.
4. RLS as an additional security layer RLS is not strictly required if namespaces and IAM policies are configured correctly, but it provides a valuable defense-in-depth layer. If any sharing misconfiguration occurs, RLS ensures users can only see data they are authorized to access at the row level. AWS recommends it as a safeguard alongside namespace isolation.