'S' is for Subscriptions

Introduction

In my first blog entry Getting started with Azure we touched upon subscriptions. We talked about redeeming a free $200 (or your regional equivalent) trial subscription as well as setting up your own ‘Pay as you Go’ subscription, but what I didn’t cover at least not directly is what are subscriptions? and that is the question I hope to answer.

What are Azure Subscriptions

Fundamentally you can think of subscriptions as a sort of ‘container’ for any resources you might want to create within the Azure Cloud platform be that Virtual Machines, Storage Accounts or Databases. Any resource you create will belong to a subscription within your Azure environment. Now notice I said ‘subscriptions’ at the start of this paragraph? well, that’s because you can have multiple subscriptions within a single Azure tenant. By default, Microsoft allows up to five hundred subscriptions per Azure tenant/ instance.

Now if you’ve been following along in this ‘A-Z’ blog series so far perhaps you’ve recently started your journey into Azure and are sat there thinking “Why would I need so many subscriptions?” and for an individual person or even a small independent business, a singular subscription would be sufficient in most scenarios. However, as the size of your Azure environment grows its best practice to add extra subscriptions for several reasons.

Now remember about 30 seconds ago when I mentioned that ‘subscriptions are a sort of container’ and while fundamentally that is true, subscriptions act more like a boundary for both your billing and access control, now let me explain using some examples:

Let’s say you work for a software development company, typically in software development you will have three production stages.

• Development Stage - This is where the Development team will create new features and updates to the application(s)

• Testing / Sometimes called ‘UAT’ (User Acceptance Testing) - Once a feature/ update is completed, it’s then pushed into testing stage before being pushed to Production.

• Production - This is the live/ current available version for the customer and or internal use.

What you would find is that typically most businesses will have either an allocated budget as a whole department or each development stage will be assigned a budget. Each one of the subscriptions will then be divided up around that budget either monthly, quarterly, or yearly from the finance department and then that monthly spend on resources can then be tracked and managed within each of the three-subscriptions.

Access Control

As I touched upon, subscriptions can also act as a boundary using what is called access control, and for the more technical term Azure Role-Based Access Control, or 'RBAC' for short. If you are not familiar with the term access control, think of it like you would the security of a building. Access control dictates who is allowed inside the building, or in this case it sets the rules of what users are allowed to access the subscription and to go one level further it also says what those individuals are allowed to do within the subscription, we’ll cover RBAC in more detail in a later entry but for now I’ll provide some more real world examples.

Let’s take our UAT stage as an example, this is typically going to be looked after by a certain team of Quality Assurance (QA) testers. This team needs permissions to deploy and test the new application code, but you don't want them to have any access to the live Production environment. Likewise, you might want to prevent the core development team from making direct changes to the UAT environment to ensure the testing process is controlled and unbiased.

By placing these resources for UAT in their own subscription, you can assign specific permissions (using Azure Role-Based Access Control, or 'RBAC') to the QA team for that subscription only. The Development and Production environments, sitting in their own separate subscriptions, would have entirely different sets of permissions assigned to different teams. This creates clear security boundaries and enforces the principle of ‘least privilege’, which is a fundamental security concept we’ll cover in a later series entry.

Service Limits

The third and less common reason you would have multiple subscriptions is service limits, and what do I mean by service limits? For every Azure subscription there is a limit on the number of resources you can deploy per Azure Region for example things like the number of virtual CPU cores, and while these limits are very generous and won’t affect most users. Organisations with a large global presence and or requirements would exceed these limits very quickly so by having multiple subscriptions, across multiple regions allows organisations to essentially ‘refresh’ their quotas to scale resources up and down as required.

Final Conclusion

While a subscription is fundamentally a container for your Azure resources; they’re real power lies in its function as a management boundary. Think of them as the primary tool in your organisational toolkit for:

• Billing Separation: Isolating costs by department, project, or environment (Dev, Test, Prod).

• Access Control: Creating secure silos where you can define precisely who can do what.

• Scaling: Providing a mechanism to work around service limits for massive-scale deployments.

Regardless of if you are someone just starting out, or a seasoned cloud engineer practicing at home a single subscription in most cases will suffice. But should you have the opportunity or resources to do so and start to build out more complex Azure environments or solutions, it’s important to understand how to leverage multiple subscriptions. This is crucial for maintaining and organising an Azure environment.