Before you start using Azure, you need to first design how you want your workloads to run and consider whether to use multiple Azure subscriptions for each workload/client or to use 1 Azure tenant with multiple Azure Resource Groups and restrict access at the Resource Group level to your users/workloads.
I’ve put together this best practice model with pros and cons for each design model. This can be used as a starting point when designing your Azure patterns.
In this tutorial i will walk you through the following:
- First you need to choose how you want to design your Azure subscription model. I’ve put together 2 options below.
- Next you need to decide how you want to design your Azure Resource Group model. I’ve put together 2 options below
- Then you need to plan how you’re going to manage access and implement an role based access control strategy.
- You also need to think about your naming standards best practice, especially if you have several teams deploying resources into Azure.
Ok lets first start with choosing your Azure Subscription Model:
Option 1) Azure Multiple Subscription Model Best Practices
In Azure Active Directory (Azure AD), a tenant is representative of an organization. It is a dedicated instance of the Azure AD service that an organization receives and owns when it signs up for a Microsoft cloud service such as Azure, Microsoft Intune, or Office 365. Each Azure AD tenant is distinct and separate from other Azure AD tenants
- An Azure tenant can have multiple subscriptions
- Each subscription can use the same Azure AD
As per the diagram above, we have 4 subscriptions under 1 Azure AD Tenant
1) Azure Subscription for Identity / Management
Host Active Directory IaaS DCs / DNS / ADFS and Any Management Servers. Operational staff members, cloud engineers, cloud security teams would have access to this subscription and manage the infrastructure in this subscription. This subscription would be the heartbeat (hub) of your Azure tenant.
2) Azure Subscription for Testing / UAT Environment
Use for any testing, preview of Azure features in a test environment. As the name suggests this will be used for testing new features that you want to implement into production environments. Testing teams would have access to this subscription.
3) Azure Subscription for Production
All production servers and applications will be hosted here. This is where you need to get your access controls (RBAC) in order, as you will have alot of project teams and your production systems/applications running here. To add an extra layer of protection, you could have separate Azure subscriptions that each project team has ownership of, depending on your company size, some very large companies have separate subscriptions for different application teams and only their department who needs access, has access.
4) Azure Subscription for Development
Use for application development work. This is where your application developers work and build out, test their applications before deploying into your production environment. Again similar to production, you could have separate development subscriptions for each dev team.
Azure Multiple Subscription Pros
- Multiple Subscriptions allow a company to easy view billing for each Subscription and limit who can access the Microsoft Azure services associated with that subscription
- Overcome any Azure limits and constraints
- Development and project team agility
Azure Multiple Subscription Cons
- Complex
- Increased Management and costs
- Network circuits
- Edge gateway devices
- IP Address space
- Routing and firewall configurations
- Monitoring, patching and anti-virus for VMs
- Storage / Backup vaults
Option 2) Azure Single Subscription Best Practices
The single Azure subscription is under 1 Azure AD Tenant. You segregate all servers and resources using VNets, Subnets, Firewalls and role based access controls (RBAC) on Resource Groups.
Each workload is in its own Resource Group. RBAC is applied at the Resource Group level to the teams/services who need access to those resources they only need. This model is ideal for smaller size companies.
Single Azure Subscription Pros
- Easier Cost Control. Project based billing via Tags and Resource groups
- Centralized Operations
- Reuse of Shared infrastructure (Networking)
Single Azure Subscription Cons
- Azure Limits and constraints (e.g 250 storage accounts per subscription)
- Less agility for development & project teams
- Requires more granular permission model (RBAC)
Azure Resource Groups Best Practices
Once you have decided on which subscription model to choose from, the next step is defining how you are going to utilise resource groups within your subscriptions. Within each subscription resources can be segregated using Azure resource groups and role based access controls can be applied to users for their respective resource groups they need access to. At the moment resource groups can’t be nested but this may change in the future
There are 2 ways to design the Azure resource group model as follows:
Option 1) Segregate Azure Resources by Department
By separating each department into their own resource group and putting all their resources they need access to into a resource group (e.g Virtual Servers), you can apply role based access controls at the resource group level, that way they only have permission to view and access only the resources in their respective department and not access any other departments resources. You will also be able to track their billing at the resource group level also.
Option 2) Segregate Azure Resources by Workload Deployment
Another option is to segregate your resources into types of workloads, for example – Web Tier, Application Tier, Management, Database Tier, etc
You can then apply RBAC to Active Directory groups and assign the AD Group to the Resources the users need access to. You then apply the Resource TAGs to resources that are being used by each department. You can then track the billing based on resources using the associated TAG as shown in the following image:
Role Based Access Control
Role based access control (RBAC) allows you to control who has access to what resources within your Azure subscriptions.
- You’ll need to connect your corporate identity store (E.g Active Directory) to Azure Active Directory using the AD connect tool.
- Control the Admin/Co-Admin of a subscription using a managed identity. Don’t assign Admin/Co-admin to a new subscription owner. Instead, use RBAC roles to provide Owner rights to a group or individual.
- Add Azure users to a group (for example, Application X Owners) in Active Directory. Use the synced group to provide group members the appropriate rights to manage the resource group containing the application.
- Follow the principle of granting the least privilege required to do the expected work. For example:
- Deployment Group: A group that is only able to deploy resources.
- Virtual Machine Management: A group that is able to restart VMs (for operations)
- Department managers: A group that has only read access to view billing and run reporting features
Azure Naming Standards Best Practices
Well-designed naming standards enable you to identify resources in the portal, on a bill, and within scripts. Most likely, you already have naming standards for your on-premises infrastructure. When adding Azure to your environment, you should extend those naming standards to your Azure resources. Naming standard facilitate more efficient management of the environment at all levels.
Recommendations on how you should name your resources in Azure are to use camelCasing for example ProductDevteamResourceGroup and vnetProduction
Consider using Azure Resource Manager polices to enforce naming standards
awesome amalgamation
Thanks Deepak 🙂
After deploying both models previously, I have to disagree on the multiple subscription being more complex. The single subscription requires significantly more complex RBAC configuration as well as Azure policy and management group considerations. Resource Groups should not be treated as ‘mini-subscriptions’; organizations which have administrative control over certain workloads should have a subscription created to contain the workloads they maintain. Additionally, infrastructure items like hub vnets and NVAs, certificate authorities / identity servers, and monitoring resources should be in separate subscriptions for easier RBAC & Azure Policy application.
Thanks for sharing your experience on this topic Rob, much appreciated.