Pondering Azure Subscription Architectures

I recently had a conversation with a Microsoft Cloud Solutions Architect regarding subscription architecture for a large client of mine.  He provided some compelling points of view, and the goal of this post is to capture some of my thoughts around subscription architecture.

First things first, what is an Azure subscription anyways?  Put simply, a subscription forms part of the digital agreement between end-users (companies or otherwise) and Microsoft for use of Azure services.  There are a few logical constructs in play here, and a subscription allows you to segment your azure deployments along an axis of billing and management.  Guidance on the use of subscriptions has varied over the years.

So how did we get here?  In the beginning, there was Azure Service Management (ASM).  If you go in the portal today, you can still deploy many services in ASM, they are generally denoted as "classic".   The advice that I would generally give to my clients was that you would need to create new subscriptions based on security/management delineations.  At the time, the only way to grant someone access to the portal was make them a co-admin.  This presented several security challenges for many organizations, and often multiple subscriptions was the only way to go.

Multiple subscription architecture can be complex to deploy.  While most services would generally be unaffected, network and specifically VPN Gateway architecture could get quite complex.  Organizations looking for hybrid deployments would need to make several decisions, sometimes greatly increasing the cost in order to achieve a desired level of security.  A lot of customers simply accepted the risk and moved on.

Azure Resource Manager (ARM) and specifically Role Based Access Control fixed a lot of the issues.  One could now create management roles and assign those users only the access they required.  Networking could still pose a challenge in a multi-subscription architecture, and so, the pendulum swung the other way.  My general advice at the time was to go with one subscription (where possible).  I'm not the only one who thinks this way as a quick google search will reveal.

So what changed?  I think in order to understand this, lets walk through some considerations for subscription layouts.

1. Size of Company

I think that this is always going to be a consideration.  Larger companies with more complex organizational layouts will want a subscription architecture that reflects how they currently do business.  Subscriptions are still a great way to segment management and billing concerns.  Depending on the maturing of processes within the organization, effective subscription management can lead to business units/departments being directly accountable for their IT spend while granting them the ability to securely deploy resources as required without IT involvement.

2. Dev/Test Scenarios

Microsoft has always had the concept of MSDN accounts in Azure.  An MSDN subscription could get you as much as $150 of free Azure spend per month.  This lead to many small (and unmanageable) Azure subscriptions that would be loosely associated with an organization (or that could have organization data on it).  Microsoft came out with the concept of an Enterprise Dev/Test Subscription and this is still a great reason to have a separate sub.

3. Billing

Billing, and the ability to surface IT spend in dynamic ways, has always been a concern.  The cloud makes a lot of this easier to do.  I used to generally not recommend creating new subs solely for billing purposes as the networking complexity, in my mind, far outweighed the benefits of separate billing.  This became more true as ARM released features around tagging, and being able to sort bills by tags and resource groups.  An effective resource group layout and tagging strategy could solve most billing concerns.

4. Management Concerns

This is described above.  ASM used to have only the concept of a co-admin, and no granular controls.  ARM fixes many of these issues and allows for flexible single subscription deployment.

5. Subscription Limits

Each subscription has an associated set of limits.

But that doesn't answer the question!  You're right, it doesn't!  But it was as good a segue as any to chat about considerations at the subscription level.  Reading above, you'll note that my main concern with a multi-subscription Architecture was networking.  Creating complex mesh topologies just didn't seem worth the effort in most cases.  Luckily, late last year, Microsoft announced the idea of VNET Peering.

What is VNET Peering?  The link provided goes into a lot of technical detail on what exactly VNET peering is, but the easiest way to understand this is that this is a function of software defined networking.  Essentially, this service allows you to magically route traffic between VNETs with different address spaces with no overhead and no throughput restrictions.

VNET peering solves the important problem of hybrid networking.  I can now easily connect VNETs in the same region and different subscriptions together without having to create complex mesh topologies.

Here is an example:

In conclusion, I used to typically recommend to keep it simple, and stay with one subscription where possible.  While this is still good advice, VNET peering solves a lot of the technical challenges with multi-subscription hybrid deployments in Azure.  We can now be more free to fit subscription architecture to company requirements without the downsides of a more complex networking topology.