My head is still swimming from all the information at Microsoft Ignite this year. In this post I’m going over three reoccurring topics that makes managing and compliance of an Azure environment easier. These are Management Groups, Policies and Blueprints.
I will start with Management Groups. But before that, let’s go back to what used to be the highest level of scoping for managing Azure, the Subscription. That was the highest level to apply role-based access control and other settings. If an organization had multiple subscriptions for development or production, or different business units, settings would have to be applied to each subscription independently. This could become an error prone and cumbersome process.
Management Groups solve this issue by allowing you to create a management group tree up to up to six layers deep. Each group or subscription will inherit settings from management groups above unless blocked. A single directory can contain up to 10,000 management groups. This gives great flexibility in how subscriptions are management and settings apply.
Policies are the next step to simplify Azure Management and adds compliance and enforcement to your Azure Implementation. Azure Policies provides the ability to create management policies and apply them to Azure resources. It runs an evaluation against those resources report on or correct deviations. It can also prevent implementations of resources outside what’s allowed by the policy.
For example, let’s say there is a subscription where no one is allowed to deploy oversized VM’s. You can create a policy that defines the VM size allowed. As another example, you can also set a policy that prevents resources deployment outside of a specific region.
Policies are applied to a management group, subscription or resource group. They can be implemented to audit as well as enforce settings. Policies are also inherited from a parent Subscription or management group.
A collection of policies, such as VM size and allowed regions, is referred to as an Initiative Definition. This gives administrators a lot of flexibility in creating and applying policies.
The last item is Blueprints. Some organizations may need to quickly setup new environments in a reproducible way that conform to a company’s standards and requirements. Policies provide part of the solution by setting a framework of rules that effect the resources. Templates will also help with repeatedly deploying resources in a declarative way into an environment.
Blueprints combine ARM Templates and Policies along with role assignments and Resource Groups to create one declarative blueprint for a complete environment setup. A blueprint brings together these different artifacts to compose one package that can deploy an entire environment in a single operation.
Not only do blueprints help with deployment, they also help prevent configuration drift in a way template alone can’t. For example, let’s say you deploy a VM with a template. Later, someone adds a couple data disks. There is no way for that change to be represented by the deployment template because that template does not exist natively in Azure. Blueprints changes this by tracking the environment in relationship to the deployment template artifacts. Creating a native connection between what is declared and what exists.
The best part; Management Groups, Policies and Blueprints are all free as part of an Azure subscription.