Additional subscriptions
An organization is not limited to a single subscription; resources can be consumed from multiple subscriptions within the same tenant or another tenant the organization owns. Any additional subscriptions can be created for access control management or billing management purposes as a subscription acts as a billing and resource management boundary.
There are subscription soft quota limits; this means that a service request must be made to Microsoft support to increase resource quota limits. Typically, this request would be for a virtual machine core count exceeded. To set the number of virtual machine cores needed, the subscription quota would need to be increased.
A subscription can be a boundary of access control. A subscription could be created for each different environment, such as creating a subscription for User Acceptance Testing (UAT), production, or staging. Alternatively, a subscription could be created per team or project as shown in Figure 3.22 in this section. This approach ensures control of access to resources, with individuals or groups only having the least amount of access they need to the minimum amount of resources. This is one of the core principles of governance and compliance, and through RBAC, the approach and principle of least privilege can be adopted. The subscription can also be used as a layer at which to enforce Azure Policy.
In addition to being used as a boundary of access control, a subscription can also be used as a boundary of billing control; this means costs incurred from Azure resources created can be allocated with a charge-back or show-back approach. With the resources being consumed being billed to that particular environment, team, or project, an organization can see precisely what environment, team, or project is costing the organization without all resources being aggregated into one subscription. Tags can be used to break down resources within a subscription but are out of scope for this section and covered later in this book.
A subscription is associated with only one tenant; the parent tenants control its access to Azure AD. Resources must also be associated with a subscription, which acts as the billing mechanism and billing boundary. The following diagram outlines the relationships between subscriptions, tenants, and resources:
Figure 3.22 – Additional Azure subscriptions
Looking back to the bar tab analogy from the previous section, each resource can only be billed to one bar tab, although resources can be moved between subscriptions so that another subscription can be used to pick up the bill (their own bar tab) for those resources consumed. The scenario here could be that for a particular reason that may be appropriate, some resources that you no longer wish to be billed for under the existing resources subscription, in this case, the resource, can be moved to another subscription that is maybe more appropriate to pay the bill for those consumed resources. The resource move is a simple operation that can be done within the Azure portal.
We can see from the example shown in Figure 3.22 that the three subscriptions associated with Tenant A can’t be associated with Tenant B simultaneously; they can only have their own parent owner. Likewise, with resources, these resources can only exist within one subscription, which acts as the billing mechanism for the consumption of those resources. The resources cannot be associated with another subscription within another tenancy simultaneously. They can move owners from subscription to subscription within the same tenancy and from the parent subscription to a different subscription in a different tenancy.
This section looked at the reasons and benefits of creating additional Azure subscriptions to a tenancy. The following section takes a look at ARM.
