Tag Archives: enrollment

Explained: Azure Enrollments, Tenants, and Subscriptions

When my customers get started with Azure, one of the first things that trips them up is the terminology.  This is a quick primer of the terms you’ll encounter as you begin your journey.

Azure Enrollment

The Azure enrollment is an Azure usage agreement often tied to an Microsoft Enterprise Agreement.  One enrollment = one bill.  Under the enrollment you create Azure accounts, subscriptions, and ultimately resources (VMs, storage, DBs).

https://docs.azure.cn/en-us/articles/azure-global-purchasing-guidance/go-global-playbook-purchase-process-of-enterprise-azure

Azure Tenant

A tenant is a instance of Azure Activity Directory (AAD).  A tenant is similar to a Windows AD domain.  Within the AAD you can have users, groups, etc.  Each instance of Azure, O365, Dynamics, etc. requires a tenant.  These tenants can be shared or you can use a unique instance for each one.

*each subscription can use a separate tenant*

https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant

Azure Subscription

An Azure subscription is the unit where all resources (VMs, DBs, etc.) reside.  The this is the highest level in an enrollment that can incur charges.  A subscription is equivalent to an AWS account.

image

see also https://docs.microsoft.com/en-us/office365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings

Azure Design Considerations–Enrollments, Subscriptions, and Resource Groups

When I first meet with new Azure EA customers, one of their first topics is “how do I set this up?”  Azure is very flexible, but this means you have design decisions to make:

  • how many enrollments do I need?
  • should I use departments?
  • should I separate teams using subscriptions or resource groups?
  • where do I apply RBAC (define access)?

While there are wrong answers, there is no one right answer.  Each organization will need to evaluate their needs, organizational structure, and use case(s) to see what works best for them now.  And if things change in the future, this design should change too.

Let’s break down the different control points.

image

First off, consider if multiple enrollments are needed or if multiple subscriptions within a single enrollment will suffice.

Subscriptions Enrollments
Separate Invoice X
Able to view charges at this level X X
Can use unique AAD Tenant X X
Can view charges in EA Portal X X
Can share an ExpressRoute X X
Simple to Administer X

Then consider how to further separate resources leveraging subscriptions and resource groups:

Resource Groups Subscriptions
RBAC supported X X
Easy to view Billing X (in Azure portal only) X (in EA and Azure portal)
Resource can be shared across X (natively) Requires additional configuration and only some resources are supported
Azure Policy supported X X
Best for Sandbox X
Best for restricting access in a common environment (i.e. PROD) X
Simpler to Administer X Multiple subscriptions create administrative overhead
Can share a single ExpressRoute X X

Keep in mind subscriptions can be grouped and administered in a hierarchy using Azure Management Groups (https://docs.microsoft.com/en-us/azure/governance/management-groups/).  Management groups allow you to set Azure Policy and RBAC centrally for governance with low overhead support.

image

Finally, in the EA portal itself make sure you are thoughtful in how roles are assigned and controlled.:

image

That’s my two cents on how to get started, but keep in mind this is a journey.  I recommend lots of whiteboard sessions to play with the different options and then test them out again real-world use cases.  The best designs appropriately limit access but are easy to implement and maintain.