Cloud Reference Architecture CRA P3 – Enterprise Structure

This is part three of the Cloud Reference Architecture (CRA) blog series and here I am going to guide you on how to establish an enterprise structure in the cloud.

• Check out part 1 – Cloud Reference Architecture or CRA – Foundation
• Check out part 2 – Cloud Financial Governance

In this blog post, am going to guide you on how to plan you Enterprise Structure in the cloud. First, I am going to help understand how to plan your Enterprise Enrollment Hierarchy through proper implementations of Departments, Accounts, Subscriptions and Resource Groups. Next, I am going to guide you on how to logically group your Azure Subscriptions for better access and policy enforcement by carefully planning your Management Hierarchy in Microsoft Azure .

Note: if you want to learn more about the cloud reference architecture, cloud security and cloud migration, then make sure to check my published book here.

Most organizations do not pay attention to the importance of planning their subscription model and how to deploy resources with a subscription design that ensures better cost management, access control and adhere to subscription scale limitations. If this is something you are interested in learning today, then keep reading.

In fact, all what is discussed in this blog series is just scratching the surface of what I am covering in the Cloud Migration Handbook. The book covers other major topics for architects and security professionals such as:

• Chapter 1: Practical Foundations for Cloud Computing.
• Chapter 2: Types of cloud migration.
• Chapter 3: Cloud Governance.
• Chapter 4: Cloud Reference Architecture (CRA).
• Chapter 5: Security in the Cloud.

Previous Talk: Cloud Reference Architecture (CRA)

In a previous blog post, we’ve introduced the concept of the cloud reference architecture(CRA) as defined in ISO/IEC 17789 standard, and why you should consider having one. The end result of a cloud reference architecture is to achieve a balance between cloud agility from one side, and security and governance from the other side.

Simply put, the Cloud Reference Architecture (CRA) helps organizations address the need for detailed, modular and current architecture guidance for building solutions in the cloud.

We’ve also covered that the Cloud Reference Architecture (CRA) serves as a collection of design guidance and design patterns to support structured approach to deploy services and applications in the cloud. This means that every workload is deployed with security, governance and compliance in mind from day one.

To accomplish this, we need to define the components of the cloud reference architecture (we call it an Enterprise Scaffold) that we will use to build secure, compliant and flexible framework that developers can build application on top with agility and speed of delivery in mind.

We also covered the cloud financial governance layer and how this can help you better manage your cost, plan your budget, and establish financial accountability in the cloud, and why all this matters to you.

In this blog post, we are going to start unfolding another layer of the cloud reference architecture which is the cloud Enterprise Structure that includes how to manage your enterprise and management hierarchy.

Enterprise Structure

The first layer of the Enterprise Scaffold is the Enterprise Structure, and at the foundation of the Enterprise Structure are two hierarchies. First, an Enterprise Hierarchy that reflects your cost model across corporate departments, and a Management Hierarchy that helps you group subscriptions for better granular access control management and policy enforcement.

First Hierarchy: The Enterprise Hierarchy

I will start by addressing the first hierarchy, the Enterprise Hierarchy. Here you can think about cost and billing. The main purpose of establishing and planning such hierarchy is driving financial accountability, which is the process of assigning each dollar spent to the appropriate business function, this can be a cost center like a business unit, a manager or even a specific application.

In simple words, when you provision cloud resources, you need to ask yourself “which department or cost center in your organization is going to pay for these resources?” and “who can provision resources for each cost center so that you don’t end up with many resources that will cost you a lot of money without properly tracking who create these resources and who will pay for them?“..

What we need is a concept of delegation and a hierarchy of responsibilities to establish financial accountability in the cloud which is exactly what we are going to talk about next.

As we are going to talk about specific cloud features that may vary from cloud provider to another, I will be using Microsoft Azure as the cloud provider of choice to explain some key concept, but the same principles apply to any other cloud platform as well.

Azure Enterprise Enrollment Hierarchy

The foundation that Microsoft come up with is hierarchy and a relationship of the Azure Enterprise Enrollment through Subscriptions and Resource Groups. In such hierarchy , you can divide your Enterprise Agreement EA into Departments, Accounts and finally Subscriptions and Resource Groups to match your organization’s billing structure as shown in figure 3.

Let’s start with the Enterprise Enrollment level at the top of the hierarchy. The Enterprise Enrollment is nothing but a billing contract also known as the Enterprise Agreement EA you have with Microsoft. This agreement simply means your organization can use Azure and gives you access to the Azure EA portal where you access billing information and also manage this hierarchy.

At the Enterprise Enrollment level, there is an Enterprise Administrator. An Enterprise Administrator is the first account created at on-boarding and have full access and visibility across all resources of your enrollment. You can have multiple Enterprise Administrators per Enrollment. This is when the hierarchy start getting its shape.

At the Enterprise Enrollment level you can also have Notification Contacts. These contacts receive communications regarding the enrollment such as weekly billing reports.

Think of the Enterprise Enrollment Hierarchy as a way to map cloud resources to your company’s departments (specific business unit or even a geography within your organization). And the root user, or the main user that creates this hierarchy is the Enterprise Administrator, and this is the account that you will have when you get an Enterprise Agreement with Microsoft.

Both the Enterprise Administrator account and the Notification Contacts can be either “Azure Active Directory accounts” in your tenant or Microsoft accounts (Hotmail, Live, Outlook,..). You can also have Read-Only Enterprise Administrator accounts at this level of the hierarchy.

Now the Enterprise Administrator can optionally create Departments in the hierarchy in the Azure EA portal, depending on your organization’s structure. You can have Departments that reflects functions, business units or geographies.

There is also a Department Administrator for each Department you define in the Azure EA portal. Departments are nothing but a way to govern who can create resources so that you can track cost to specific function or department in your organization, and keep in mind that Departments are optional.

Each Department Administrator delegates the task of creating Subscriptions to one or more Azure Accounts as shown in figure 4. Now this might be confusing a little bit but simply put, Department Admins are usually senior managers in your organization and they only want to track cost, they are not going to create Subscriptions themselves. Therefore, there is a need for an abstraction layer so that Department Admins, the senior people in your company, can delegate the task of creating Subscriptions to people down in the management hierarchy of your organization. This abstraction layer is called Azure Accounts and you create and manage these Accounts from the Azure EA portal.

Now each Azure Account that you (as an Enterprise Administrator) define in the Azure EA portal can only have a single Account Owner, and that Account Owner cannot be assigned as an Account Owner to any other Account.

Accounts, and subsequently Account Owners, are primarily responsible for creating and managing Subscriptions. Now Subscriptions can be moved between Accounts with one condition, Subscriptions can only belong to a single Account at any given time and this is because we want to establish accountability for the cloud consumption.

Now when Account Owners create Subscriptions, they become the “Service Administrator” or the Subscription Owners for Subscriptions they create. Once a Subscription is created, an Account Owner can delegate the role of Service Administrator to a developer or IT admin to start creating resources inside that subscription.

In this hierarchy, Subscriptions represent the highest-level container for deploying resources, assigning permissions, and they enable you to isolate environments across business units. Within each Subscription, you can organize resources into Resource Groups through the Azure portal, and a best practice is to group resources that share the same life-cycle into one Resource Group (such as the resources for an n-tier application may be created or deleted as a group).

Resource Groups also represent a good policy and access enforcement level. This means you can assign Azure locks, Azure policies and RBAC at the Resource Group level, and all child resources inherit whatever you assign at the Resource Group level.

Here is the important part, at each level of this hierarchy (Enterprise level, Department level, Account level, Subscription level and the Resource Group level), consumption and cost can be rolled up and isolated at each level to get better visibility on your spending in the cloud.

As an example, an Account Owner has visibility and resource consumption for all Subscriptions he manages but not for subscriptions created by other Account Owners. Therefore, an Account Owner is financially responsible for all Subscriptions he creates and manages

Enterprise Enrollment Hierarchy Example

Let us look at a quick example. Let’s assume you are migrating three line of business applications as shown in figure 5:

• The Marketing Portal App: which is the public portal for your company.
• The HR Payroll App.
• The Financial App.
• You also want to migrate some IT workloads.

One simple approach is for you as an Enterprise Administrator to log on to the Azure EA portal and define four Departments:

• Marketing Department.
• HR Department.
• Finance Department.
• IT department. 

This means you can look at your cloud bill and then isolate the cost for each of these four Departments separately. Let’s say you get a 20,000$ bill by the end of the month, and because you defined four Departments in the Azure EA portal, you can breakdown the cost per department. Perhaps 15000$ of the total 20000$ is spent by the HR department, which quickly helps you focus on why the HR Department is causing you so much money.

We also need to hold someone financially accountable at the Department Level in this Enterprise Hierarchy we are building. This means we need to define four Department Administrators who are going to look at the cost roll-up for their respective Departments.

Now this has to be a senior person in your organization. For example, the  Department Administrators are going to be the CMO, CHO, CFO and CTO for their related departments. Each head of Department gets roll-up consumption for all resources deployed under his department. The Department level in this hierarchy is considered the PO level.

But the CFO, who is the Department Administrator for the Finance Department will not create Subscriptions himself. Instead, he will delegate this task to his assistant by creating an Azure Account under the Finance Department in the Azure EA portal, and make his assistant the Account Owner for that account, and this gives him the power to create as much Subscriptions as he wishes.

Same applies to other department. Each Department Administrator delegates the task of creating Subscriptions to an Account Owner. This Account Owner can be a contractor or a partner who is going to create that application on behalf of the local IT team.

Now the IT Department Administrator which is the CTO in this example, might choose to create two Accounts under the IT Department in this hierarchy. One might be given to a partner to deploy a service and the other is given to his Infrastructure Manager to create other IT infrastructure workloads like domain controllers and bastion hosts.

Now Account Owners are going to create Subscriptions, and by doing that, they become Financially Accountable for any consumption from Subscriptions they create, and this is where the financial accountability concept is realized.

An Account Owner gets visibility and cost of all Subscriptions he creates and manages, but not for Subscriptions created by other Account Owners. And this creates a level of separation of concern and duties.

When an Account Owner creates a Subscription, he becomes the “Service Administrator” for that Subscription. This means he can create resources inside that Subscription. But Account Owners are not going to create resources themselves, instead they delegate the Service Administrator role to a developer who becomes the Service Administrator for that Subscription to start creating resources.

Let’s assume that your HR department wants to create a Payroll Application and a Training Portal for internal employees. This means you have two applications that you want to deploy in the cloud for the HR department as shown in the below figure 6.

The Chief HR Officer (CHO) is assigned the Department Admin for the HR Department in the Azure EA portal. This means he can look at the consumption for these two applications, and he can issue the PO accordingly.

Now let’s assume that the CHO decided to give a third party or a partner the responsibility of creating one of these two applications, the Training Application for example. As the partner needs to create one or more subscriptions to host that application in Azure, he needs access to do so.

The partner would ask the CHO for an Azure Account that enables him to create one or more subscriptions. The CHO responds by logging into the Azure EA portal using his Department Admin account, creates an Azure Account and gives that Account to the partner organization. That partner is now an Account Owner and can create one or more Subscriptions to host the Training Application.

On the other side, the CHO decided that he needs also a new Payroll Application, but he wants the local IT team to deploy that application in Azure. Therefore, he creates a different Azure Account in the Azure EA portal and gives it to the DevOps Manager in his organization and says “here you go, you can create whatever Subscriptions you need to deploy the Payroll Application“.

Now the DevOps manager is now an Account Owner, which means he can log on to the Azure EA portal and create subscriptions to host his resources. He realized that he needs to create three Subscriptions to host the Payroll Production Environment, the Payroll QA Environment and the Payroll Dev Environment as shown in figure 6.

He uses his Azure Account to log on to the Azure EA Portal and creates three Subscriptions, and by doing so, he becomes the Service Administrator or Subscription Owner for all three Subscriptions.

Now the DevOps Manager wants John (who is his DevOps member) to actually deploy the Payroll Application, so he delegates the Service Administrator role to John, and now John can create whatever resources he wants in these three Subscriptions.

Let’s say that after one month, you (the Enterprise Administrator) received a big bill for all subscriptions in your enrollment, and you realized you are spending way too much than you predicted.

Here is where the financial accountability shines. You can isolate the cost per Department in the Enterprise hierarchy you are managing, and you can quickly realize that the HR Department is causing that spike in cost

You would then talk to the CHO who is the HR Department Admin and ask him to investigate. Now the CHO can look at the roll-up for his HR department and even get a breakdown cost per all Azure Accounts under his Department.

He then quickly realized that the spike in cost is caused by the Azure Account related to the Payroll Application. The CHO can then email his DevOps manager, because he is the Account Owner for that account and he is financially accountable for the cost of all subscriptions he creates.

Now the DevOps Manager gets breakdown cost for all the three Payroll Subscriptions under his Azure Account and he realizes that the QA Subscription is causing the spike in cost. He sends an email to his DevOps member who is the Service Administrator for the QA subscription, asking him to investigate.

As you can see, at each level, the cost is rolled-up and isolated and you can track back who created what and where your money is being spent the most. Below is a figure that summarized all levels of the Enterprise Enrollment Hierarchy and different accounts related to each level.

Subscriptions Design Models

We are left with one fundamental question “what is the best way to create subscriptions?“. I mean should you create one big subscription to host all your cloud workloads? Or perhaps there are some best practices that you can follow to optimize your design?.

Subscriptions are very important building block in the Enterprise Hierarchy, without subscriptions, you cannot create resources. In fact, each Azure resource is a child to only one subscription, and this is how the cost is managed inside Azure, which makes sense after all. Microsoft wants to charge you for resources you consume in Azure, and by requiring that each resource is deployed inside only one subscription, they can compute the overall cost at the subscription level which is the sum of the cost of all child resources in that subscription.

What Subscriptions Represent?

To answer the original question of the best way to create subscriptions, we need to really understand what a subscription represents in Azure. Only by doing that, we can understand what works better and how to distribute our workloads among different subscriptions.

Let’s say that you want to create couple of workloads in Azure, and of course each resource costs an amount of money. You might be wondering how are you going to pay for these resources? Are you going to logon to the Azure portal, go to that resource and search for a place to pay specifically for that resources? What if you have thousands of resources. It wont make sense to pay individually for each resource.

And what if you have different payment methods for example. Let’s say you have an office in the United States and another office in Europe, and then you have an application that only serves Europe office, and you want to have different payment method, or different payment card for applications serving the Europe office. How could you define different payment method for a group of resources in the cloud?

Moreover, how can you identify which resource or resources belong to specific business unit to establish that financial accountability we’ve talked about. and what if you have three applications in the cloud, and you want to limit the spending for one of these applications, and you want a way to group resources belonging to that application to apply a spending limit for all these resources at once.

This is why you need sort of logical container to group resources that share a common criteria, and then define a payment method at the container level. You can then say “I want to use this payment method for these resources, and for other resources I want to have a different payment method“.

You can also define who can manage a group of resources by assign access control on that container or subscription, and also place some spending limits instead of doing so for each child resource.

You can think of subscriptions as containers where all cloud resources are contained regardless of their geographic location. Therefore, you can have resources from different Azure regions under the same subscription. One resource can be created in US-West region while the other is created in the South Africa region and both are contained under one subscription. Subscriptions are just a logical container. They are billing units in Azure. Therefore, without a subscription you cannot create resources.

You can roll up consumption at the subscription level. This means you can get the cost of all resources deployed inside a specific subscription and if you deploy your applications inside different subscriptions so that each application is hosted inside one subscription, you can know how much each application is costing you.

Subscriptions also represent the logical limit of scale by which resources can be allocated. For example, you are limited by the number of virtual CPUs that can be provisioned in a single subscription. If you reach that soft limit, you might consider distributing your resources across more than one subscription. Therefore, scalability becomes a key factor when planning your subscription model.

Applying RBAC permissions at the subscription level is also a common practice because a subscriptions represents an administration boundary. You can assign admin roles at the subscription level. They can also be used as a security boundary. If you have a contractor who is helping you develop a new CRM application in Azure, you might create a separate subscription, and give the contractor owner right at that subscription, so all what he can see and manage are resources he creates inside that subscription and nothing else.

Shall I Put All My Resources In One Big Fat Subscription?

You can, but you shouldn’t. Now why this is not a good idea? Well, because of all the reasons we’ve talked about. If you have all your apps in one subscription, then you don’t have the isolation you need to manage resources belonging to different applications. You might have a contractor who wants to deploy an application and you cannot make him a subscription owner because the same subscription hosts resources serving other applications.

And since you can roll-up cost at the subscription level, its hard to tell how much each application is costing you. Deploying your applications across different subscriptions however, gives you that cost breakdown and provides better visibility into your cost.

We’ve also mentioned that subscriptions are logical limit of scale, so you might have a maximum number of virtual CPUs you can have in one subscription, and you might reach that limit easily if you have many applications in that subscription, which also becomes a problem.

Subscription Design Pattern 1

One way to think of how to manage your subscriptions is to host each LOB application into its own separate subscription. If you have four different applications, you can spin four subscriptions and deploy each application within its own container or subscription. You can now assign access control at the subscription level to give relevant teams access only to the resources they need to manage. If you have four applications and different DevOps teams managing these applications, you can easily give each DevOps team access at the subscription level to the relevant subscription hosting their application. Problem solved!

You can also roll-up and isolate the cost per subscription and per LOB application with such design pattern as shown in figure 9, and there is little chance you would reach the scale limit of a subscription since each application lives in its own subscription.

Let’s take the Financial Application as an example. You have a separate subscription that is dedicated purely to host the Financial Application, and inside that subscription, you would create a Virtual Network (VNET) and three Subnets (web tier subnet, business tier subnet, and data tier subnet). This way, you have complete separation and control even within different tiers in the same application as shown in figure 10.

For the four applications we’ve talked about, you will end up with four subscriptions, each with three subnets for the different application tiers as shown in figure 11.

But then you might thinking “this sounds great, but for each application, I need to maintain a production environment, a QA environment and a Dev environment, so how could this design adjust accordingly?”

Well, one way to do that is to have different VNETs inside each subscription for each application life-cycle environment. Therefor, in the Financial App subscription, you would have three VNETs, one for the production environment, one for the QA environment and one for the Dev environment. Within each VNET, you would have three subnets (web tier, business tier, and a data tier subnet) a shown in figure 12.

You still have some control over which users can manage which application, but little control on which teams manage which environment within the same application, because all three application life-cycle environments for the same application are hosted under one subscription. This is where the next subscription design comes to the rescue.

Subscription Design Pattern 2

Another way to design your subscriptions model is to extend the previous design pattern so that each application has three subscriptions. Yes you heard me right. Each application needs three subscriptions. One subscription to host the application’s production environment, another subscription to host the application’s QA environment, and of course a third subscription to host the application’s Dev environment as shown in figure 13.

It all depends on how many application life-cycle environment you need. If you require four different application life-cycle environments (production, dev, staging and QA) for each application, then you might consider having four different subscriptions for each application.

In such design, each subscription will have one VNET and three subnets (web, business, and data). You can have separate DevOps teams managing different application life-cycle environments by simply assigning permissions at the subscription level. You could also apply relaxed policies on non-production subscriptions and more strict policies on the production subscription (and by that I mean the subscription hosting the production environment of the application).

In our example, we have four applications, so in total we would have 12 subscriptions as shown in figure 13.

Now if you find it too much to have that number of subscriptions, You can keep the production environment separated and hosted into a dedicated subscription, and all other application life-cycle environments deployed into one subscription. For four applications you then need 8 subscriptions.

So why it’s recommended to have a separate subscription for the production environment, you might be asking. Because such environment is critical and changes should be controlled in a strict way. You could apply an Azure Lock at the production subscription level to prevent any changes on the production environment. You also might have a different DevOps team managing all production environments, so it is easier to plan your access control when production environments are hosted in their own separate subscriptions.

Subscription Design Pattern 3

A third design pattern is to host all production environments for all applications under one subscription, all QA environments under another subscription, and all Dev environments under a third subscription. I don’t think this design pattern is going to scale well if you have many LOB applications though. The only benefit of such design is that you can assign access control at the subscription level so that one team manages all production environment, and other teams manage all QA and Dev environments, and it is easy to just configure RBAC at the subscription level with such design.

Second Hierarchy: Management Hierarchy

Now that we’ve talked about this first hierarchy (Enterprise Hierarchy) which is basically a billing hierarchy, it is time to talk about the second hierarchy, the Management Hierarchy.

Do you remember when we’ve talked about the Enterprise Hierarchy for the HR department as shown in figure 6? We had a need to deploy two line of business applications, the Payroll App and the Training App. We defined two Azure Accounts, and under each Account, we had couple of subscriptions for the production environment and Dev environment. This gave us the opportunity to isolate the cost per environment and establish financial accountability.

But now let’s forget about the cost for a minute and focus on access management and policy enforcement. You might agree with me that it makes sense that all production environments share common need to apply strict policies and access control requirements. You might have an Azure Policy that requires all subscriptions owner to have MFA enabled, and you want to enforce this across all your production environments.

But the Enterprise Hierarchy does not help here as it is designed with cost in mind. It would be great if we can group subscriptions based on policy and access management needs aside from their billing hierarchy, and this is what the Management Hierarchy is all about. By using Azure Management Groups, we could group all subscriptions hosting production environments under one Management Group, and then apply RBAC and Azure policies at the Management Group level as shown in figure.

The Need For The Management Hierarchy

Better explained by example (as shown in figure 16), let’s assume you have three applications, the Marketing App, the HR App and the Finance App. You want to maintain a production environment and a dev environment for each application. You decided to deploy two subscriptions per application to host these two environment, so you end up with six subscriptions:

• Marketing Dev Subscription.
• HR Dev Subscription.
• Finance Dev Subscription.
• Marketing Prod Subscription.
• HR Prod Subscription.
• Finance Prod Subscription.

You also want to give DevOps team 1“Subscription Owner right on all Dev subscriptions, and DevOps team 2 Subscription Owner right on all production subscriptions.

What you would do then is to go to the Marketing Dev subscription and grant “DevOps team 1” that right, and then do the same for the HR Dev subscription and the Finance Dev subscription. Well, it is manageable so far.

Now let’s do the same for production subscriptions and grant “DevOps team 2″ the required rights at the subscription level. That’s going to be fun.

Your security team then asked you to apply an Azure policy that prevents creating public IP resource inside any subscription hosting the Dev environment. You spent some time configuring that Azure policy and then it took you some time to go to each of the three Dev subscriptions and apply that policy at the subscription level.

You also got a request to limit the type of VMs the DevOps can create in any Dev environment. It’s definitely not your lucky day. Here you are again configuring such policy and then assign it to the three Dev subscriptions manually.

It’s a lot of work depending on the number of subscriptions you have, but so far, it is manageable. However, you can start see a trend here.

Now for the all production environments, you have couple of Azure policies that your security team wants you to apply to enforce some business or security rules. You created three or four Azure policies and then you go manually to each production subscription and assign these policies at the subscription level. Be careful not to forget one of these production subscriptions however.

You can see things might go out of control here as the number of subscriptions you have increase over time, which is a normal thing as your business grow.

Things can get worse if you decided to deploy a new CRM application. You would create two subscriptions to host each environment of course. You then forget about giving each DevOps team access to the right CRM subscription, but after you receive some calls from them, you remember to do so. You might also remember to assign one of the previously created Azure policies at one of these two new CRM subscriptions, but what about other policies? Will you remember to assign them too? Not doing so will leave your CRM resources under risk after all.

What if you have a new Azure policy (Azure Policy 4 in figure 16) to apply to all subscriptions, Will you remember to apply it to the new CRM subscriptions? may be, and maybe not.

You can quickly find out that there is a clear need to manage group of subscriptions as one management unit so you can centrally apply permissions and policies at a higher level. This is where the Management Hierarchy comes into the picture.

Azure Management Groups

The Management Hierarchy is all about creating and maintaining Azure Management Groups. Each subscription can be a member of one management group, and management groups can be nested up to six levels. Therefore, you can group all subscriptions hosting production workloads (regardless of their location in the Enterprise Hierarchy) under one management group, and all dev subscriptions under another management group. By doing that, you get more granular access management and policy enforcement options, because you can define RBAC and Azure Policies at the management group level, and those got inherited by all child subscriptions as shown in figure 17.

By default, all subscriptions are member of a default built-in management group called the Root Management Group. You can then start creating more management groups to group subscriptions in a way that makes it easier for you to deploy permissions and Azure Policies. You can have for example a Production Management Group, to group all subscriptions hosting production environments.

You also could create a Dev Management Group and a QA Management Group to host corresponding subscriptions, so that subscriptions hosting dev workloads are hosted under the Dev Management Group for example.

Other management groups can be created to host subscriptions providing Shared Services or Auditing and Monitoring Services. Nested management groups are also possible. In fact, management groups can be nested up to six levels.

With all that in mind, you can now apply an Azure Policy to restrict creating public IPs, and apply it at the Dev and QA management groups. This will apply that policy to all child subscriptions, allowing you to easily enforce governance at higher level (the management group level), instead of the subscription level.

In big organizations, there might be a hundred of subscriptions, and it is hard for each subscription you create, to assign the right permissions or remember to enforce corporate policies. Well, with management groups, central IT can define which management groups to create, and the permissions and policies for each management groups.

Whenever someone creates a new  subscription, they should only add it to the right management groups, and immediately all corporate policies are enforced. There is less chance that a subscription lacks proper policy enforcement with such management hierarchy. This creates the proper consistency and governance for all your subscriptions. as shown in figure 18.

Putting It All Together

I know this is too much to figure out if you are new to these concepts, that’s why I have one extra thing for you. I want to use all what we’ve learned today and apply it to a sample organization. This organization is trying to migrate couple of application to the cloud.

The organization decided to create two departments, the IT Department and the Marketing Department since all what they are planning to deploy in the cloud are the Marketing App which belongs to the Marketing Department and the Intranet App which belongs to the IT Department, in addition to some IT shared services as shown in figure 19. We have the CTO as the Department Admin for the IT Department, and the CMO as the Department Admin for the Marketing Department.

The CMO creates one Azure Account and give it to a contractor so that the contractor can create subscriptions. The contractor then creates the Marketing App Dev Subscription to host the dev environment and the Marketing App Production Subscription to host the production environment for the Marketing App.

From the other side, the CTO creates three Azure Accounts and he assigns his Infrastructure Manager as the Account Owner for one of the three Accounts, to create the IT Shared Services Subscription, he assigns his Security Manager as an Account Owner for another Account to create and manage the Logging and Monitoring Subscription, and finally he assigns his DevOps manager as an Account Owner to the third Azure Account so that he can create subscriptions to host the Intranet Dev and Production Environments.

Now this is what the Enterprise Hierarchy looks like. It helps establish Financial Governance, good isolation model, and cost can be isolated at the subscription level, and roll-up at the department and enterprise level.

Now as for the Management Hierarchy, we have the default Root Management Group and then we have two management groups under the Root Management Group. One is called the Business Apps Management Group, and the other is the Corp Services Management Group as shown in figure 20.

Under the Business Apps Management Group, we have another two management groups, the Production Management Group and the Dev Management Group, and each group hosts the respective application life-cycle environment subscriptions.

Under the Corp Services Management Group, we have also two child management groups, the IT Services Management Group and the Logging Management Group.

Access control and policies can be applied at any management group level in this Management Hierarchy. If we have a requirement to apply an Azure Policy to all LOB applications, then we can assign it at the Business Apps Management Group and it will be applied to all child subscriptions, while if we have a policy that should be applied to all dev environments across all apps, we can assign that policy to the Dev Management Group level and all child dev subscription will get that policy

Moreover, if we have a new line of business application and accordingly we created a dev and production subscriptions for that new app, then just by placing these two new subscriptions under the right management group, they get all the access controls and policies assigned at higher levels in the hierarchy.

Featured Posts

You Can Also Become Microsoft MVP

How To Start Your Own Blog – Microsoft MVP Story

Cloud Reference Architecture CRA P1 – Foundation

Azure Bastion Step-by Step Guide

Azure advanced threat protection lateral movement

 Get my latest book about Cloud Migration

This book covers a practical approach for adopting and migrating on premises systems and applications to the Public Cloud. Based on a clear migration master plan, it helps companies and enterprises to be prepared for Cloud computing, what and how to successfully migrate or deploy systems on Cloud, preparing your IT organization with a sound Cloud Governance model, Security in the Cloud and how to reach the benefits of Cloud computing by automation and optimizing your cost and workloads..

Get the book here and learn more.

Subscribe to my YouTube Channel

In my YouTube channel, I post videos about cloud security and Microsoft MVPs story to help people understand cloud and cybersecurity in simplified and professional way.