Multi-tenancy considerations - Amazon Verified Permissions

Multi-tenancy considerations

You might want to develop applications for use by multiple customers - businesses that consume your application, or tenants - and integrate them with Amazon Verified Permissions. Before you develop your authorization model, develop a multi-tenant strategy. You can manage the policies of your customers in one shared policy store, or assign each a per-tenant policy store.

  1. One shared policy store

    All tenants share a single policy store. The application sends all authorization requests to the shared policy store.

  2. Per-tenant policy store

    Each tenant has a dedicated policy store. The application will query different policy stores for an authorization decision, depending on the tenant that makes the request.

Neither strategy creates a relatively-higher volume of authorization requests that might have an impact on your AWS bill. So how, then, should you design your approach? The following are common conditions that might contribute to your Verified Permissions multi-tenancy authorization strategy.

Tenant policies isolation

Isolation of the policies of each tenant from the others is important to protect tenant data. When each tenant has their own policy store, they each have their own isolated set of policies.

Authorization flow

You can identify a tenant making an authorization request with a policy store ID in the request, with per-tenant policy stores. With a shared policy store, all requests use the same policy store ID.

Templates and schema management

Your policy templates and a policy store schema add a level of design and maintenance overhead in each policy store.

Global policies management

You might want to apply some global policies to every tenant. The level of overhead for management of global policies varies between shared and per-tenant policy store models.

Tenant off-boarding

Some tenants will contribute elements to your schema and policies that are specific to their case. When a tenant is no longer active with your organization and you want to remove their data, the level of effort varies with their level of isolation from other tenants.

Service resource quotas

Verified Permissions has resource and request-rate quotas that might influence your multi-tenancy decision. For more information about quotas, see Quotas for resources.

Comparing shared policy stores and per-tenant policy stores

Each consideration requires its own level of time and resource commitment in shared and per-tenant policy store models.

Consideration Effort level in a shared policy store Effort level in per-tenant policy stores
Tenant policies isolation Medium. Must include tenant identifiers in policies and authorization requests. Low. Isolation is default behavior. Tenant-specific policies are inaccessible to other tenants.
Authorization flow Low. All queries target one policy store. Medium. Must maintain mappings between each tenant and their policy store ID.
Templates and schema management Low. Must make one schema work for all tenants. High. Schemas and templates might be less complex individually, but changes require more coordination and complexity.
Global policies management Low. All policies are global and can be centrally updated. High. You must add global policies to each policy store in onboarding. Replicate global policy updates between many policy stores.
Tenant off-boarding Medium. Must identify and delete only tenant-specific policies. Low. Delete the policy store.
Service resource quotas High. Tenants share resource quotas that affect policy stores like schema size, policy size per resource, and identity sources per policy store. Low. Each tenant has dedicated resource quotas.

How to choose

Each multi-tenant application is different. Carefully compare the two approaches and their considerations before making an architectural decision.

If your application doesn't require tenant-specific policies and uses a single identity source, one shared policy store for all tenants is likely to be the most effective solution. This results in a simpler authorization flow and global policy management. Off-boarding a tenant using one shared policy store requires less effort because the application does not need to delete tenant-specific policies.

But if your application requires many tenant-specific policies, or uses multiple identity sources, per-tenant policy stores are likely to be most effective. You can control access to tenant policies with IAM policies that grant per-tenant permissions to each policy store. Off-boarding a tenant involves deleting their policy store; in a shared-policy-store environment, you must find and delete tenant-specific policies.