Editor's note: This post is the second in ‘The Azure Bakery’ series: this part is about management groups. Click here for the introduction to the series.
Welcome back for the second layer of our cake. The first layer was Azure Active Directory. Today, we'll look at 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 are a crucial aspect in managing access, policies, and compliance across Azure. A management group is like a container for your subscriptions and allows you to apply governance to all 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 mostly 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.
A management group is like a container for your subscriptions and allows you to apply governance to all subscriptions within that management group.
There are multiple ways you can design and utilize management groups and their subscriptions. For example, you can mirror the billing hierarchy, categorize on 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 the design of your subscriptions. For this layer, we’ll focus on the enterprise-scale landing zone architecture framework. 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’s beneficial for 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 take all required resources into account and make sure these are available when you’re 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 people 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. The 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 it 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 operationally maintaining 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. It’s important to include high availability and disaster recovery capabilities in your design.
[F] [G] [H] Security, governance, and compliance: This area ensures that the right 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 the available tools. The same API handles all the requests, whether you’re 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.
Azure Resource Manager templates allow you to implement infrastructure-as-code for your solutions.
Working with infrastructure-as-code has several benefits:
- Lower the potential for human errors.
- Identical environments by using the same template multiple times.
- Cost reduction by creating test environments on-demand.
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 need to be performed in the appropriate order to get the desired infrastructure. ARM templates use the declarative approach; you’ll specify the required resources and their properties.
The declarative approach defines the desired state, and the system executes what needs to happen to achieve that state.
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’re able to deploy the same resources in the same way. They allow you to automate your resources’ deployment by integrating them with your favorite continuous integration and continuous deployment tool.
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!