Choosing the best Azure subscription service model

When starting on your journey to Azure, you need to get your subscription model in place before you start building your cloud infrastructure.  Its important to get this right before you do anything else.

I’ve put together 2 options to choose from that is most common in large enterprises.

Option 1- Multiple Subscription Model

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. Subscription for Identity / Management

Host Active Directory IaaS DCs / DNS / ADFS and Any Management Servers

2) Subscription for Testing / UAT environment

Use for any testing, preview of Azure features in a test environment

3) Subscription for Production

All production servers and applications will be hosted here

4) Subscription for Development

Use for application development work

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

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 – Single Subscription Model

Single subscription under 1 Azure AD Tenant. You can segregate all servers and resources using VNets, Subnets, Firewalls, RBAC on Resource Groups.

Pros

• Easier Cost Control. Project based billing via Tags and Resource groups
• Centralized Operations
• Reuse of Shared infrastructure (Networking)

Cons

• Azure Limits and constraints (e.g 250 storage accounts per subscription)
• Less agility for development & project teams
• Requires more granular permission model (RBAC)

Resource Group Model

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:

1) Segregate 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.

2) Segregate 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)

Naming Standards

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