Azure subscriptions
Azure subscriptions can be considered the logical containers of Azure resources that share the same billing boundary and an access control boundary.
An Azure subscription is a billing mechanism for the Azure resources you consume within a tenancy. It can be likened to a bar tab, a method of paying for everything you have consumed all together and itemized at the end of the night without paying individually each time you consume a drink. When a bar tab is opened, a payment method must be provided, such as a credit card, so that there is one bill to settle for everything put on the tab at the end of the night; you can think of the subscription as the tab.
Every time a resource is created within Azure, an Azure subscription must be selected against which to associate the consumption of resources (or tab in our previous example). This means the Azure subscription(s) would be created first to be able to create any resources.
At the end of the month, all the Azure resources created in that subscription will be billed in a single itemized invoice.
The following diagram outlines Azure subscriptions:
Figure 3.19 – Azure subscriptions
The Azure subscription will need to be created in an existing Azure AD tenancy or a new Azure AD tenancy; this is the foundation and starting point. Management groups are then created if required, and finally, resource groups are planned as needed. We will cover management groups and resource groups in a later section of this chapter.
Subscriptions cannot be merged, but resources can be moved into another subscription and delete the subscription or allow it to expire; any resources in the subscription are deleted when the subscription is deleted. However, when a subscription expires, the resources remain. In either case, the tenancy remains in place; this is not removed.
The billing owner of the subscription can also be changed, much like a bar tab could be run up and transferred to somebody else to take it over and settle the tab.
When planning to start creating resources in Azure, you must first define access and billing control; this will shape the subscription and resource group strategy. You should create the tenancy, subscription, and resource groups in that order.
Planning is to be considered for your subscriptions and whether you will have multiple subscriptions within a tenancy. You may wish to have one for production resources and one for development and testing purposes to isolate access to the resources through the subscription or just to control who will receive the invoice for any resources created within each subscription. This will depend on your needs, and we look at creating additional subscriptions later in this chapter.
This section introduced the concept of Azure subscriptions and how they are a billing mechanism, as well as a billing and access control boundary.
The following section looks at the relationships between subscriptions and tenants.
The relationship between tenants and subscriptions
As we saw in the last section, there are certain relationships between subscriptions and tenants. The relationships also extend to other entities such as resource groups and the Azure resources themselves. There are also relationships between users, groups, and apps such as a Microsoft 365 subscription. Resource groups are logical containers for resources; these will be covered in more detail later in this chapter.
The following diagram outlines the relationship between these entities:
Figure 3.20 – Azure subscription and tenant relationship
In a nutshell, an Azure AD tenant contains users, groups, Microsoft 365 subscriptions, and Azure subscriptions. Azure subscriptions contain resource groups, which contain resources. The following facts should be observed concerning these relationships:
- Each subscription in Azure can be associated with only one Azure AD tenant, in a parent and child relationship, with the Azure AD tenant being the parent.
- A subscription can be moved to a different Azure tenant.
- The subscription billing owner can be changed, such as moving from being invoiced by Microsoft to being invoiced by a Cloud Solution Provider (CSP).
- Each subscription can have multiple resource groups; each resource group can be part of only one subscription.
- Each resource can be associated with only one resource group; in a parent and child relationship, the resource group is the parent.
- Each user can be associated with only one Azure AD tenant, with the Azure AD tenant being the parent.
- Each user can access more than one Azure AD tenant.
- Each group can be associated with only one Azure AD tenant, with the Azure AD tenant being the parent.
- Each Microsoft 365 subscription can be associated with only one Azure AD tenant (a <name.onmicrosoft.com> domain), with the Azure AD tenant being the parent.
This section looked at the relationships between subscriptions and tenants and the broader relationships between resource groups, resources, users, groups, and other subscriptions such as Microsoft 365. The following section looks at Azure subscription management.
Azure subscription access control
It is essential to control access to subscriptions to ensure governance of creating resources within a subscription (who is adding drinks to the tab from our previous section’s analogy); this utilizes RBAC.
RBAC provides the ability to assign multiple accounts different access levels to a subscription as needed by an organization. Multiple owners are set for a subscription, although the number of owners should be limited to a maximum of three for best operational security practices as defined in Azure Security Center. Azure AD accounts are primarily used to assign access to Azure subscriptions through role assignments.
We will cover RBAC in more detail later in this book; we will cover the basic concepts only in this section.
There are two levels of access control, authentication (often shortened to AuthN) and authorization (often shortened to AuthZ):
- Authentication is proving who you say you are.
- Authorization is what actions you are allowed to do as that identity, such as read data, modify data, delete data, or give others access to data.
In terms of managing access to an Azure subscription, authentication comes from Azure AD and authorization comes from Azure RBAC roles.
The following diagram shows the span between roles:
Figure 3.21 – Azure subscription access control
The following information should be noted from the previous diagram:
- By default, the Azure roles and Azure AD are isolated and do not span or overlap from Azure AD, as in Microsoft 365 roles.
- Being assigned an Azure AD role gives no assignment of any Azure roles.
- By default, there is no access to Azure resources with an account with the Global Administrator role.
- Access to Azure resources must be explicitly allowed and can only be granted with an account that has the Owner role for a subscription
This section introduced the concepts of access control to Azure subscriptions. The following section looks at the Azure roles.
