The Azure Bakery series: Management groups

Welcome back for the second layer of our cake. The first layer was Azure Active Directory. Today, we’ll examine management groups, the enterprise-scale landing zone architecture framework, and Azure Resource Manager.

The landing zone framework’s core consists of management groups and subscriptions and is a great tool to help you design the fundamentals of your Azure environment. Going through Azure Resource Manager, its scopes, inheritance, and templates solidify your Azure understanding.

Management groups

Azure’s management groups manage access, policies, and compliance. A management group is like a container for your subscriptions, enabling you to govern the subscriptions within that management group.

Most organizations have multiple subscriptions. Management groups provide the possibility to organize subscriptions into subgroups. The subscriptions inherit the configuration from the management groups above. We’ll look at subscriptions in detail in the next layer.

Management groups are always a cake by themself. Even though it’s possible to nest management groups up to six levels deep, the recommendation is to keep the hierarchy primarily flat with no more than four levels for an efficient and flexible management strategy. The first level in every Azure tenant is the so-called Tenant root group management group. It’s built-in and allows you to apply governance at the directory level.

Create a top-level platform management group to combine and govern the subscriptions used for the foundation of your Azure environment. The top-level sandbox management group allows your organization to experiment with Azure. The sandbox is isolated from the rest of the environments.

You can design and utilize management groups and their subscriptions in multiple ways. For example, you can mirror the billing hierarchy, categorize workload or application, model your organization, or use the enterprise-scale landing zone architecture framework.

The design of your management groups goes hand in hand with your subscriptions. We’ll focus on the enterprise-scale landing zone architecture framework for this layer. In the next layer, we go through the other design strategies in more detail.

Even though the landing zone framework is initially meant for enterprises, it benefits every organization. It allows you to design your management groups and subscriptions and, thereby, your Azure environment in a modular and scalable way.

Enterprise-scale landing zones

Landing zones represent a multi-subscription Azure environment that includes security, governance, networking, and identity. They consider all required resources and ensure they’re available when engineering and deploying your solutions.

A good analogy to a landing zone is the set of services required to build a city. Before creating buildings and moving into them, certain essential services must be in place, like power infrastructure and water and sewage facilities.

Landing zones follow eight critical design areas to translate your requirements to the capabilities and constructs of Azure.

[A] Enterprise Agreement enrollment and Azure Active Directory tenants: This agreement represents the relationship between Microsoft and your organization’s Azure usage. Enrollment provides a hierarchical structure to govern the management of subscriptions.

Azure Active Directory (Azure AD) is Microsoft’s cloud-based identity and access management service. The Azure AD tenant represents your organization and is the first layer of our Azure cake. You can have multiple Azure AD tenants in the same enrollment. However, this is not preferred.

[B] Identity and access management: This area acts as the security boundary within your Azure environment and allows you to implement role-based access control (RBAC) and the principle of least privilege.

[C] Management group and subscription organization: This area supports organizational mapping, and you must design accordingly to enable you to use Azure at an enterprise scale.

[D] Management and monitoring: This area supports operating your Azure environment by centralizing platform management and monitoring. Ensure that you include visibility as your platform’s foundation.

[E] Network topology and connectivity: This area supports creating a secure network design that ensures end-to-end connectivity between the different platforms. Identify, deploy, and configure the needed services and resources, such as firewalls and gateways.

[F] [G] [H] Business continuity and disaster recovery: This area supports meeting the availability and recovery targets for your workloads. Including high availability and disaster recovery capabilities in your design is essential.

[F] [G] [H] Security, governance, and compliance: This area ensures that the proper guardrails are in place to protect against unintended configurations that could expose your organization to risks.

[I] Platform automation and DevOps: This area supports the software development lifecycle to ensure a repeatable and consistent delivery of your infrastructure using infrastructure-as-code.

Azure Resource Manager

Azure Resource Manager (ARM) is the service for managing and deploying resources in your Azure environment. ARM enables you to manage your resources by using multiple tools. The same API handles all the requests, whether using the Azure portal, Azure PowerShell, Azure CLI, or REST clients. Therefore, you’ll have the same capabilities and get consistent results with different tools.

When working with ARM, you have four levels or scopes: management groups, subscriptions, resource groups, and resources. The lower levels inherit the settings. For example, when you assign a policy to a management group, the subscriptions in that management group inherit the policy configuration. Management groups usually have multiple subscriptions, subscriptions, numerous resource groups, and resource groups various resources.

Templates

Azure Resource Manager templates allow you to implement infrastructure-as-code for your solutions.

Working with infrastructure-as-code has several benefits:

• Lower potential for human errors.
• Identical environments by using the same template multiple times.
• Cost reduction by creating test environments on-demand.

ARM templates are written in JavaScript Object Notation (JSON), a lightweight data-interchange format. JSON is easy for humans to read and write and for systems to parse and generate.

There are different approaches when writing infrastructure-as-code: declarative (what) vs. imperative (how). The declarative approach defines the desired state, and the system executes what needs to happen to achieve that state. Imperative defines the commands that must be performed appropriately to get the desired infrastructure. ARM templates use the declarative approach; you’ll specify the required resources and their properties.

When you deploy a template, the following takes place:

• The JSON file is parsed.
• The passed-in parameters are filled in.
• The template functions are executed.
• The resource type APIs are called to create the resources.

Working with ARM templates gives you repeatable results; you can deploy the same resources similarly. They allow you to automate your resources’ deployment by integrating them with your favorite automation tools.

Up next

Thank you so much for taking the time to read this post. I’d love to hear what you think, and I hope to see you next week when we’re going through the next layer of our cake, subscriptions. Bye for now!