In this post, I will cover some of the key design decisions when considering subscriptions in Azure. Let’s start by answering what is a subscription?
In Azure, subscriptions are the foundation building block. All your resources are logically located inside a subscription. Subscriptions also offer granular control over cost, where cost can be applied and tracked per subscription. The subscription also offer logical isolation between resources.
One of the common design questions I get is how many Azure subscriptions should we have? I will walk you through some of the common design patterns and explain the pros and cons.
Single Subscription
For enterprises that have a small scale Azure environment, a single subscription per account is enough. This is subscription pattern is mostly implemented by organisation that is just starting their cloud journey with Azure. Usually, this would be a small PoC or a Dev environment.
Application Life Cycle Subscription
This design pattern the life cycle of an application. In most organisations, they will have a development subscription, a user acceptance testing subscription, a production subscription etc. This is a very common pattern as it allows relevant policies to apply to application based on its life cycle. For example, in a development environment subscription, costly high-performance SKUs can be blocked. In production subscription, only storage SSDs are allowed is another example.
Department Subscription
In this subscription, each department (sales, finance, HR, etc.) is given its own subscription. This pattern is not often used as it ignores the application life cycle.
Application Subscription
This pattern dedicates a unique subscription per application. This allows an application to utilise maximum resources per subscription without an impact on other applications in the same subscription. Also often developers will need access to certain applications and this pattern will limit the risk of any changes impacting other applications. The disadvantage of this pattern is the high number of subscriptions. Another application-centric approach is to have a subscription per application category (Web Services, Databases, Business Analytics, Collaboration tools, etc.).
Hybrid Subscription
It is common to a hybrid. For example, a common pattern will see different business units have their own subscription per application life cycle (Sales: Dev, UAT, Prod).
When I am asked for my preference, with the absence of specific requirements, my answer is less is easier management. Start with production and none production subscriptions and build up from there as your Azure footprint grows.
Thank you for reading and sharing.
Regards,
Nick
