Introduction
In today’s competitive software landscape, SaaS providers often face the challenge of delivering personalized data visualizations to multiple customers. This need is particularly pressing for multi-tenant SaaS products where different customers, or tenants, require isolated access to dashboards tailored to their data. Amazon QuickSight, a fully managed service from AWS, offers a robust solution for building and embedding dashboards that align perfectly with the multitenancy architecture of modern SaaS products.
Multitenancy in QuickSight enables organizations to efficiently manage and segregate dashboards, data sources, datasets, and user permissions for different tenants, all within a single QuickSight account. This approach simplifies operations while ensuring compliance with data privacy and security standards.
This blog will provide insights into implementing multitenancy in QuickSight, leveraging namespaces for isolating users and resources, configuring access control, and best practices for tenant isolation. The blog also discusses strategies for sharing dashboards across namespaces, dynamically embedding dashboards in client applications, and handling complex setups where namespace-specific administrators manage their own users and resources.
Leveraging Namespaces for Multi-Tenancy
QuickSight provides namespaces as a powerful feature to implement multi-tenancy, allowing organizations to segregate users and resources across different tenants. A namespace is essentially a container within QuickSight that isolates users, groups, and resources, ensuring that each tenant operates independently within the same QuickSight account.
For organizations setting up tenants, the ‘default’ namespace can be reserved for internal use, such as managing resources for subsidiaries or internal teams. Additional namespaces can then be created for each tenant, enabling
- Data Isolation: Ensuring that data and resources for one tenant are not accessible to others.
- Custom User Management: Defining specific users and groups for each namespace, aligning with tenant-specific roles and permissions.
Creating all users across tenants in the same default namespace in Amazon QuickSight can lead to several challenges.
- Lack of Tenant Isolation : Without namespaces, users across tenants share the same resource space. Misconfigurations in access control (e.g., incorrect permissions on shared folders or row-level security rules) could lead to users inadvertently accessing dashboards, datasets, or analyses that belong to other tenants.
- Complex Access Control Configuration : One would rely heavily on RLS to ensure users see only their data in shared dashboards or datasets. This increases the complexity of dataset configurations and requires constant maintenance to prevent errors.
- Scalability Issues : As the number of tenants grows, managing shared dashboards, datasets, and analyses for all users in a single namespace becomes unmanageable
- Performance Bottlenecks : A single namespace means all users query shared datasets. Heavy usage by one tenant could degrade performance for others, leading to contention and slower query times.
- High Risk of Admin Errors : Misconfiguring a single shared resource or folder can impact multiple tenants, resulting in widespread access issues or data exposure.
Provisioning Users within the Namespaces
Provisioning users in namespaces requires using the AWS CLI or SDK to programmatically create and manage users. Administrators can create users via the console for only the default namespace. For any other custom created namespaces, the users can only be created and provisioned access via the API. This process ensures that users added to a specific namespace cannot view or access resources outside their assigned namespace and hence provides complete isolation and control over tenant-specific configurations.
For a straightforward multitenancy setup, where users are only required to view QuickSight dashboards, the administrator of the default namespace can directly provision these users. However, in a more complex scenario where control needs to be delegated to a superuser within a specific namespace, the administrator can provision a user with an ‘admin’ role for that namespace. This superuser can then manage the namespace independently, provisioning additional users with roles such as ‘author’ or ‘reader.’ This approach empowers tenants with greater autonomy while reducing reliance on the default namespace administrator.
Resource Management
Creating Data Sources for Each Tenant and Sharing with the Namespace
Creating a dedicated data source for each tenant provides clear separation of data and preventing accidental data leaks or unauthorized access. This has 2 major benefits
- Custom Configuration : This allows for Data sources to be customized for tenant-specific requirements, such as applying connection settings, query optimizations, or filters.
- Operational Independence: Updates or maintenance on one tenant’s data source do not impact others, allowing for better scalability.
To share the data source with a namespace, you can use QuickSight APIs or CLI commands to assign the data source permissions to users or groups within the namespace.
Publishing a Dashboard Across Namespaces
Frequently, an admin may create a standard dashboard in the default namespace and need to share it with users in a custom namespace. This scenario is particularly useful when you want to provide a unified experience for tenants while maintaining data isolation. Steps involved in this process are
Replicate assets : Replicate the datasets, analysis across the namespace
- Duplicate an existing dataset using the API & modify the data source ARN in the dataset configuration to point to the new tenant’s data source.
- Duplicate the analysis & modify the analysis definition to reference the new dataset created for the tenant.
- Publish the dashboard copy to the namespace updating the dashboard definition to use the new tenant-specific analysis or dataset.
Grant Access: Assign permissions to groups or users in the custom namespace to view or edit the dashboard.
Embedding QuickSight Dashboards in Client Applications
Finally, let’s talk about embedding Amazon QuickSight dashboards into client applications while maintaining strict access control. The process involves dynamically generating embed URLs based on user authentication and authorization within the application. This ensures that only authorized users can access the appropriate dashboards.
When a user requests access to a dashboard, the application sends a request to an AWS Lambda function, providing the namespace, user ID, and dashboard ID as inputs. The Lambda function verifies the user’s existence within the specified namespace and, upon successful verification, generates an embedded URL tailored to the namespace-specific configuration. This URL is then returned to the application, allowing the user to securely access the dashboard.

The Lambda function operates under an IAM policy designed to enforce namespace-level security.
{
"Effect": "Allow",
"Action": "quicksight:GenerateEmbedUrlForRegisteredUser",
"Resource": [
"arn:aws:quicksight:region:account-id:namespace/tenant_namespace_1"
]
}
It ensures that only users belonging to the specified namespace are permitted to generate embedded URLs.
For every new tenant, a corresponding custom namespace is created, and a new IAM policy is associated with the Lambda function, granting access to users from the new namespace. This setup eliminates the need to replicate the Lambda function for each tenant while maintaining a scalable and secure embedding solution for multitenant applications.
SPICE Management
In a multi-tenant environment with AWS QuickSight, SPICE memory management primarily operates within the context of each individual tenant’s namespace. Each tenant’s namespace essentially has its own dedicated pool of SPICE capacity. This means that the memory consumed by one tenant’s datasets does not directly impact other tenants. Additionally, the amount of SPICE capacity available to each tenant can be managed and controlled by the administrator.
Administrators can monitor SPICE capacity usage for each tenant within their account. This helps identify potential issues and proactively manage resource allocation. If a tenant requires more SPICE capacity, administrators can increase the allocated capacity. Conversely, unused capacity can be released to optimize costs.

While each tenant’s data is logically isolated within its namespace, the underlying hardware infrastructure for SPICE is shared across all tenants within the same AWS region.
Advanced Multitenancy setup
In a more advanced multitenancy setup, the primary admin of a QuickSight account can provision tenant-specific admins within custom namespaces. These tenant admins, in turn, are empowered to manage users (authors and readers) within their respective namespaces and create custom dashboards tailored to their tenant’s needs. This decentralized administration model fosters scalability, autonomy, and flexibility, especially in SaaS environments or enterprises managing multiple tenants. Here the Role Hierarchy and Responsibilities are as follows –
Primary Admin: The primary admin operates within the default namespace and holds overarching responsibilities for managing all namespaces. This includes provisioning tenant namespaces, assigning tenant admins, and setting up initial shared resources such as data source templates and dashboard layouts
Tenant Admins: Each tenant namespace is managed by a tenant-specific admin. These admins have the autonomy to create and manage users—both authors and readers—within their namespace. They are responsible for ensuring that tenant-specific data sources and permissions are configured correctly and that the dashboards created within their namespace meet the tenant’s requirements.
Authors: Within their namespace, the authors collaborate with tenant admins to build and refine dashboards that provide actionable insights tailored to the tenant’s business context.
For example, when a new tenant is onboarded, the primary admin creates the namespace and assigns an admin to it. The tenant admin then provisions users, organizes them into groups for streamlined access management, and ensures that the necessary data sources and templates are available. Authors within the namespace can then create custom dashboards, while readers access these dashboards as required.
This model allows tenant admins to create and distribute dashboards independently of the primary admin, reducing bottlenecks and enabling faster response times to tenant-specific analytics needs
Choosing the right Pricing Model
AWS QuickSight offers two primary pricing models: User-Based and Capacity-Based. User based pricing model is simple where one pays a fixed fee per user per month and is suitable for organisations with a stable and predictable number of users. On the other hand, Capacity based pricing is Ideal for organizations with fluctuating user numbers or varying usage patterns.
Pricing models are applied at the namespace level. This gives you the flexibility to tailor your pricing strategy to the specific needs and usage patterns of each tenant or department within your organization.
For eg. You can have one namespace operate on a User-Based model, where you pay a fixed fee per user. This is suitable for departments with a stable user base and consistent usage.
Simultaneously, another namespace can utilize the Capacity-Based model, paying only for the resources consumed (e.g., reader sessions). This is ideal for departments with fluctuating user numbers or high usage variability.
Understanding QuickSight Costs by Namespace
AWS QuickSight allows you to track and allocate costs at the namespace level. This provides valuable insights into the cost consumption of each tenant or department within your organization.
Here we use AWS Cost Explorer for understanding costs by namespace. By applying cost allocation tags such as “Namespace: Sales” or “Namespace: Marketing” to your QuickSight resources, you can effectively filter and group costs within Cost Explorer. This allows you to visualize and analyze the cost consumption of each namespace, identify cost drivers, and make informed decisions about resource allocation and pricing strategies.
For example, you can easily track the total cost associated with the “Sales” namespace by filtering your cost data based on the “Namespace: Sales” tag. This provides a clear picture of the costs incurred for all users and resources within that specific namespace.
Summary
This blog aimed to provide a comprehensive understanding of the journey when onboarding Amazon QuickSight as an analytics solution, especially for multitenant environments. QuickSight offers robust capabilities to streamline tenant onboarding, manage resources, and ensure secure, scalable analytics. By replacing custom-built solutions with QuickSight’s offerings, organizations can significantly reduce operational complexity while delivering powerful, tailored BI experiences. From leveraging namespaces to implementing dynamic embedding and access control, QuickSight equips businesses with the tools needed to meet diverse tenant requirements. As you transition to QuickSight, this guide highlights the critical steps and considerations to ensure a seamless and efficient integration into your analytics ecosystem.