Welcome to this video, Azure Cost Management
Setup, Organization and Tagging
Part B - Setting up Azure Entity Hierarchies
my name is Terry Clancy
This is the part 2 of a 4 part video series,
the series covers setting up Azure environments,
azure hierarchies, secure access and settings,
and reporting by dimensions and tags.
One of the most important considerations when setting up
your Azure environment for success
is how you set up your entity Hierarchy.
In this context Entities can either be
Billing Entities or Resource Entities.
Let's first look at Billing Entities. Billing entities are different
depending on how you buy Azure.
For example there are different billing entities
for each of Enterprise Agreements (or EAs),
Microsoft Customer Agreement (or MCAs),
pay-as-you go (PAYG)
and for customers of Cloud Solution Providers (CSPs).
Over time each of these channels will be unified into the
Microsoft Customer Agreement (or MCA) channel
which supports all these purchasing scenarios.
In this video we will look at the billing entities for Enterprise Agreements
and Microsoft Customer Agreements.
The Enterprise Agreement or EA Billing Entities
determine your Invoice Structure and your
top-level groupings for costs.
For Enterprise Agreement or EA customers
there is one Billing Account per EA,
and one Invoice per Billing Account
Under the Billing Account, using the EA Enterprise
Portal, you can set up multiple
"Departments". Each Department will
appear as a separate section in your invoice
and can be grouped and filtered separately
in Azure Cost Management. Each
"Department" can have multiple "Enrollment Accounts"
which determines the subscription owners
and provides another level of granularity
by which costs can grouped and filtered separately
in Azure Cost Management. The "Enrollment Account" is the lowest EA billing entity,
underneath of that are the Resource Entities, first
"Subscriptions" and under that, "Resource
Groups". Now lets look at the Microsoft
Customer Agreement Entity hierarchy.
Microsoft is improving the Azure
purchase experience for all users by introducing the
Microsoft Customer Agreement (MCA)
) as primary way to purchase Azure for all customers including,
over time, EA customers. It allows for pay-as-you-go
purchasing with no upfront commitment. The Microsoft Customer Agreement is a simplified,
fully digital, non-expiring contract
that enables you to start using products and services faster
and delivers enhanced billing and
cost-management capabilities. For MCA customers there is one
Billing Account per Agreement. But unlike the EA
case, with MCA you can configure multiple "Billing
Profiles" in the Azure portal and each
Billing Profile will be issued separate invoices
which can optionally be in different currencies.
And, each Billing Profile can be grouped
and filtered separately in Azure Cost Management.
Each "Billing Profile" can have multiple "Invoice Sections"
which will appear as a separate section
in your invoice and can be grouped and filtered
separately in Azure Cost Management.
So, ...... whether you are purchasing Azure through EA or MCA
you should use "Billing Entities" to define the main high level
groupings by which you want to group costs
and see them appear on your invoice.
Above subscriptions there is a separate
Resource Entity Hierarchy
which is separate and unrelated to
the Billing entities we have already discussed.
This is the "Management Group" Hierarchy.
So Subscriptions exist in two largely unrelated hierarchies.
This can be confusing for some people.
Because they are independent of Billing Entities,
Management Groups can span, or include,
subscriptions from different PAYG,
CSP, EA
and MCA accounts. They can also be helpful for
historical reporting because, with a Management
Group Scope, history is maintained
through EA renewals or the transition from one
purchasing channel, such as EA,
to another, such as CSP
or MCA. Azure Resources and Resource Entities such as Management
Groups, are not impacted by changes
in how you purchase Azure. The limitation of Management
Groups is that they cannot span Azure AD Directories.
So you should define one Root Management
Group per AD Directory. You can build a flexible structure
of "Management Groups" and "Subscriptions" to organize your resources into a hierarchy.
The primary role of management groups
is for unified policy and access management.
This way permissions, policies and resources can be assigned
appropriately at for example a Management
Group level and so they cascade down to the child Management
Groups Subscriptions, Resource
Groups and Resources. The Management Group hierarchy
should be more focused on how you run Azure and on
operational requirements. However,
if possible, the structure should ALSO allow costs
to be scoped and roll up in a useful way.
For example "if" Cost Centers are a useful demarcation for assigning RBAC
roles and policies, as well as being useful for aggregation
of costs, then you are lucky and you should strongly consider using them as nodes in the hierarchy.
Note that currently in Azure Cost Management
you can set the "Scope" for Azure Cost Management
to a Management Group, but you can not Group
by or Filter by Management Groups.
If costs need to be aggregated in ways that do NOT
align with any of the Resource or
Billing Entities then as
discussed in the Part A of this video series
Tags can be used to aggregate
costs in multiple different ways.
Now let's look at best practices
for organizing hierarchies.
Across both Billing and Resource Entity
Hierarchies there are some common organizational patterns
that may be useful. The Business unit
pattern groups subscriptions and accounts
based on profit and loss category, business unit,
division, or profit center. For organizations with
global operations, the geographic
pattern groups subscriptions and accounts
based on geographic regions. The functional
pattern organizes subscriptions and accounts along
functional lines, such as finance, sales, or IT.
But note however that this approach can be susceptible
to corporate re-organizations.
Depending on the size and scale of an
application and organization
it may be appropriate to separate applications
by Workload, Application or Subscription.
As an organization
grows other application categories
often emerge that form logical boundaries for subscriptions.
For example: Applications that are Mission
Critical. Apps that are part of Cost of
Goods Sold (COGS) for the company.
Apps that are subject to regulatory
requirements such as HIPAA or FedRAMP
In general these are good categories because
they would each require different policies and RBAC
assignments. Finally It is generally a good idea
to keep production data, apps and other assets out of your
dev/test environments. They should at least
be in different subscriptions. Management group
hierarchies can be up to six levels deep (not including the root)
and 10,000 management groups can be supported in a single directory.
This provides you with the flexibility to
create a hierarchy that combines several of the Organizational
patterns to meet your organizational needs.
For example, this diagram shows an organizational hierarchy
that combines the business unit pattern
the geographic pattern, the environment pattern,
the Application Category
Pattern, and the Workload Separation Pattern.
But beware, this is probably more complexity than you need.
You should design a hierarchy that provides the scaffolding
you need to grow, but without unnecessary
complexity. Think in terms of the Minimum Viable
Product (or MVP) to provide the framework you need for the foreseeable future
without too much complexity. This
brings me to the end of Azure Cost Management,
Setup Organization and Tagging,
Part B - Setting up Azure Entity
Hierarchies. All the best with Azure
Cost Management.