Azure provides many options for organizing your resources. In a multitenant solution, there are specific tradeoffs to consider, when you plan your resource organization strategy. In this article, we review two core elements of organizing your Azure resources: tenant isolation and scale-out across multiple resources. We also describe how to work with Azure's resource limits and quotas, and how to scale your solution beyond these limits.
Management levels and hierarchy
Azure provides four levels of management: management groups, subscriptions, resource groups, and resources. The following image shows the relationship between these levels.
Management groups help you manage access, policy, and compliance for multiple subscriptions. All subscriptions in a management group automatically inherit the conditions applied to the management group.
Subscriptions logically associate user accounts with the resources they create. Each subscription has limits or quotas on the amount of resources it can create and use. Organizations can use subscriptions to manage costs and the resources created by users, teams, or projects.
Resource groups are logical containers where you can deploy and manage Azure resources like web apps, databases, and storage accounts.
Resources are instances of services that you can create, like virtual machines, storage, or SQL databases.
Azure Resource Hierarchy
Approaches and patterns to consider
Tenant isolation
Azure resources are deployed and managed through a hierarchy. Most resources are deployed into resource groups, which are contained in subscriptions. Management groups logically group subscriptions together. All of these hierarchical layers are associated with an Azure Active Directory (Azure AD) tenant.
Isolation within a shared resource
You might choose to share an Azure resource among multiple tenants and run all of their workloads on a single instance. Review the service-specific guidance for the Azure services you use to understand any specific considerations or options that might be important.
When you run single instances of a resource, you need to consider any service limits, subscription limits, or quotas that might be reached as you scale
Separate resources in a resource group
You can also deploy dedicated resources for each tenant. You might deploy an entire copy of your solution for a single tenant. Or, you might share some components between tenants and deploy other components that are dedicated to a specific tenant.
We recommend that you use resource groups to manage resources with the same lifecycle. In some multitenant systems, it makes sense to deploy resources for multiple tenants into a single resource group or a set of resource groups.
It's a good practice to use separate resource groups for the resources you share between multiple tenants and the resources that you deploy for individual tenants.
Separate resource groups in a subscription
When you deploy a set of resources for each tenant, consider using dedicated tenant-specific resource groups. For example, when you follow the Deployment Stamps pattern, each stamp should be deployed into its own resource group. You can consider deploying multiple tenant-specific resource groups into a shared Azure subscription, which enables you to easily configure policies and access control rules. You might choose to create a set of resource groups for each tenant, and also shared resource groups for any shared resources.
Separate subscriptions
By deploying tenant-specific subscriptions, you can completely isolate tenant-specific resources. Additionally, because most quotas and limits apply within a subscription, using a separate subscription per tenant ensures that each tenant has full use of any applicable quotas. For some Azure billing account types, you can programmatically create subscriptions. You can also use Azure reservations across subscriptions.
Make you aware of the number of subscriptions that you can create. The maximum number of subscriptions might differ, depending on your commercial relationship with Microsoft or a Microsoft partner, such as if you have an enterprise agreement.
Separate subscriptions in separate Azure AD tenants
It's also possible to manually create individual Azure Active Directory (Azure AD) tenants for each of your tenants, or to deploy your resources into subscriptions within your customers' Azure AD tenants. However, working with multiple Azure AD tenants makes it more difficult to authenticate, to manage role assignments, to apply global policies, and to perform many other management operations.
Resource limits
Azure resources have limits and quotas that must be considered in your solution planning. For example, resources might support a maximum number of concurrent requests or tenant-specific configuration settings.
The way you configure and use each resource also affects the scalability of that resource. For example, given a certain amount of compute resources, your application can successfully respond to a defined number of transactions per second. Beyond this point, you might need to scale out. Performance testing helps you to identify the point at which your resources no longer meet your requirements.
Tags
Resource tags enable you to add custom metadata to your Azure resources, which can be useful for management and tracking costs.
Antipatterns to avoid
Not planning for scale. Ensure you have a clear understanding of the limits of the resources you'll deploy, and which limits might become important, as your load or number of tenants increase. Plan how you'll deploy additional resources as you scale, and test the plan.
Not planning to bin pack. Even if you don't need to grow immediately, plan to scale your Azure resources across multiple resources, resource groups, and subscriptions over time. Avoid making assumptions in your application code, like there being a single resource when you might need to scale to multiple resources in the future.
Scaling many individual resources. If you have a complex resource topology, it can become difficult to scale individual components, one by one. It's often simpler to scale your solution as a unit, by following the Deployment Stamps pattern.
Deploying isolated resources for each tenant, when not required. In many solutions, it's more cost-effective and efficient to deploy shared resources for multiple tenants.
Using separate Azure AD tenants. In general, it's inadvisable to provision multiple Azure AD tenants. Managing resources across Azure AD tenants is complex. It's simpler to scale across subscriptions linked to a single Azure AD tenant.
Over architecting when you don't need to scale. In some solutions, you know with certainty that you'll never grow beyond a certain level of scale. In these scenarios, there's no need to build complex scaling logic. However, if your organization plans to grow, then you will need to be prepared to scale—potentially at short notice.