Most of the cloud service providers have similar subscription models but have some unique features. We are going to concentrate on Microsoft Azure as this is the cloud service we are going to cover in this book. From now on, all features we are going to discuss are going to be Azure-specific.
For Microsoft Azure subscription, the highest level of administration is that of a tenant. Azure is a public cloud with data centers all over the world that are available to everyone. There are a few exceptions such as the US government's data center that is available only to US government institutions, the Chinese government's data center for Chinese official institutions, or the German data center only available to companies registered in Germany.
As a public cloud provider, Microsoft has to keep data separate for each user. Azure fabric is used to separate resources in the data center and tie them to a specific customer. So, even if you are sharing physical resources such as network, servers, and storage, your services can be accessed and managed only by you.
As the highest level of Azure, a tenant is created by default when you create your first Azure subscription. Many people don't realize that they already have an Azure tenant if they use Office 365. Office 365 requires Azure Active Directory and creates your first Azure tenant. I have seen many people making the mistake of creating a new Azure tenant even when they had Office 365 in use. The issue is that the tenant is tied to Azure Active Directory and creating a new tenant creates a new copy of Azure Active Directory. This makes Azure Active Directory hard to manage as you have two copies and differences appearing over time.
Creating your first Azure subscription creates a new Azure tenant and a new Azure Active Directory. There are multiple options for managing Azure Active Directory but we'll discuss that in Chapter 8, Azure Active Directory – Identity in the Cloud. Creating an additional Azure Active Directory creates a new Azure tenant as well.
The next level under tenant is Azure subscription. You can have multiple Azure subscriptions under a single tenant. Creating a new tenant will result in an empty tenant with only an Azure Active Directory without subscriptions. As Azure Active Directory has multiple tiers, you will not be able to change Azure Active Directory from Basic (that is free) to another tier without a valid subscription. A subscription is needed in order to collect usage information, generate a billing report, and finally issue an invoice for service usage.
An Azure subscription can be used to separate Azure environments by financial and administration logic. This can be done in many ways and you can design it to fit your needs. One example would be to have a single tenant at the company level and an Azure subscription for each department. This way you can assign a different administrator to each subscription/department and keep track of how much each department is spending. Another example for subscription separation would be to have different stage environments. I've seen many companies dividing their subscriptions into development, testing, and production environments and having different Azure subscriptions for each of these environments. This approach gives you the ability to administer and manage each environment separately but provides insight into how much you are spending on each environment as well.
The third part of separating resources would be using resource groups. Resource groups were introduced with the ARM model and bring many benefits. As with subscriptions, you can use resource groups to separate resources in terms of logical or billing level. An example would be to have a different resource group for each department or development/test/production environment. You can then assign different administrators to each resource group and track billing for each resource group. Note that for billing, you will still receive a single invoice at the end of the month and need to manage and track spending manually. Billing separation is much easier on a subscription level. If you need to separate invoices per department/environment, you should go with subscription separation.
Every resource in Azure can be tracked using hierarchy. Resource belongs to a resource group, resource group belongs to subscription, and subscription belongs to tenant. Logging in to the Azure portal will connect you to the default tenant. You can manage which tenant is going to be the default one as a single account can be in multiple tenants. For example, my corporate account is by default in my corporate tenant but I'm a guest user in multiple client tenants. By default, I connect to my company tenant but can select client tenants from a drop-down list. I can change my default tenant as well and select in which tenant I want to be logged in by default when I sign in to my Microsoft Azure account.
To look at this from a Microsoft Azure perspective, when you log in to Microsoft Azure with your account, Azure fabric determines to which tenant you have access, signs you in to your default tenant, and you have access to subscriptions that are in that tenant. From there you can manage all subscriptions, resource groups, and resources that belong to that tenant. By switching tenants, you have access to different subscriptions, resource groups, and resources that belong in that tenant. All this is handled by Azure fabric in order to separate client environments.
This approach is much better since the ARM model was introduced as things were much different in ASM. In ASM, after login you would have access to all subscriptions that were under that single account. Azure Active Directory wasn't tied to a specific tenant and you could have multiple Azure Active Directories in a single tenant. It was difficult to keep track of resources as there were no resource groups and the only thing separating them was the subscription level.
A similar hierarchy can be applied to resources administration too. You can assign a user to have certain access to your resources as well. The access level can have different kinds of permissions such as owner, contributor, reader, and so on. You can build custom permissions to achieve your own rules and policies. User roles can be assigned on the level of tenant, subscription, resource group, or single resource. Managing user access at the resource level can be hard and time-consuming and I wouldn't recommend this approach.
On the other hand, access to the tenant level is something you will often want to avoid because in most cases you don't want users to have same access to all resources. A few administrators can be exceptions, but this approach is something you want to avoid in general. The best and most common option is to assign users access at the subscription or resource group level. Subscription-level access can be used if you have different departments or environments for each subscription and you can assign an administrator for that department or environment as a subscription administrator. Access to the resource group level can be applied if you have a single application or environment in the resource group and assign an application/environment administrator for corresponding resource groups. These aren't the only options or models you can use but you can adjust and create whatever option best fits your needs. For example, I have seen where organizations have placed similar resources in a single resource group and assigned an administrator based on their on-premises role. All network resources would be in a single resource group and network engineers assigned to a network resource group. All databases would be placed in another resource group and a database administrator assigned as administrator for that resource group and so on.