Keeping track of what resources you have in Azure, how they’re being used, and who’s responsible for them are key steps to maintaining an efficient Azure environment. So we hosted a webinar with Microsoft’s Jussi Roine (@jussiroine) and Azure MVP Stephane Lapointe (@s_lapointe) to discuss how to create and run a good governance plan in Azure.
The cloud offers amazing agility, but sometimes that kind of freedom can be daunting. Microsoft Azure has several tools to help you manage your environment, but understanding how they work together and when to use one versus another can be hard to figure out.
In their recent webinar, Azure Policy essentials: Elevate your governance from plan to best practice, Jussi and Stephane provided an expert overview of the Azure landscape, explored the tools within it, and presented some best practices for using them.
We wanted to make life easy for you, so you can watch the webinar or you can keep reading to review the main takeaways below.
The foundations of a governance plan
Governance is all about organizing your infrastructure in a way that makes sense for users and gives you the visibility you need to stay in control.
Before starting a governance plan, it’s important that you know:
- Who you want to have taking actions in your tenant,
- What your naming and tagging conventions will be,
- and, how you’ll organize your subscriptions into management groups.
Centralized vs. federated management models
Before the cloud, it was normal to put a firewall in place to maintain control of your servers. Some cloud architects still use the same kind of approach in Azure.
However, the flexibility of the cloud makes it easier for developers and IT professionals to deploy the resources they need without constant monitoring. This legacy process was in place simply because a limited number of people in the organization had the ability to create resources on their own.
Typically, you can choose to organize your governance structure in Azure following one of two structures, a centralized or a federated model. The centralized model is typically IT-led; whereas the federated model is usually project-led. And, as I’m sure you could guess, there are pros and cons to each.
On the one hand, a centralized system gives you control over your environment, but it might suffer from delays because the deployment of every new resource and project has to go through IT—leading to a real potential of bottlenecks.
On the other hand, a federated model gives users more power, which can free up both your time and theirs. However, your users may spin up resources unnecessarily or mistakenly delete something because it’s currently inactive despite the fact that you may need it for future use.
Jussi and Stephane’s advice?
Take your time and figure out what will work best for your organization. There are even ways that you can try to have the best of both worlds.Jussi Roine and Stephane Lapointe, Azure Policy essentials: Elevate your governance from plan to best practice
Some organizations operate with a centralized model where IT manages the hardware, cabling, and other assets, and then have a virtual federated model with self-service in the cloud.
Set naming and tagging conventions
Establishing naming and tagging standards are crucial for governance. Unfortunately, there are a lot of different ways to approach naming and tagging in Azure.
“If I asked 10 people on Twitter what the best naming convention is, I’ll get 20 answers,” Jussi joked. “There’s about 40 pages of content on this from Microsoft, not because it’s especially complicated but because there are a lot of ‘what if’s and a lot of choice.”
“Naming is hard—be it your kids or Azure resources—you need to come up with something that everyone is happy with,” said Jussi.
The best advice Jussi and Stephane could give to listeners: be consistent and take your time coming up with your Azure naming convention. “You can’t rename something in Azure. You can move it, but you can’t rename it. So think about it upfront, don’t do it in an iterative way,” reminded Stephane.
When naming resources, for example, try to keep it simple and consistent. Jussi suggested starting with a prefix of the type of resource, followed by the application name and the environment. In this way it’s easy to quickly glean what the resource is and what it’s being used for.
Tagging can help shed even more light on the function of a resource, resource group, subscription, or management group. Tags allow you to group resources together in different ways. You can have multiple tags for each resource. And unlike names, tags can be changed.
A few examples of useful tags include naming the owner, providing billing information, labeling the environment, and indicating if it’s meant to be confidential. When you’re organizing your tenant a few years after deploying your resources, these types of tags will help you figure out if each item is still needed or whom to ask to find out.
Make use of management groups
No matter how cool your company is, within your tenant, there is a hierarchy. At the top are management groups, underneath which—in descending order—are subscriptions, resource groups, and individual resources. You can have multiple management groups, and multiple subscriptions within each management group.
Why is this so important? Because you can set policies, blueprints definitions, and role-based access controls (RBACs) at the management group level.
That means that if you want to set the same policy across multiple subscriptions, you can easily do so if they’re all in the same management group. That policy will be pushed to all resources, resource groups, and subscriptions in the management group, saving you time and manual tedium.
Creating policies in Azure
Azure Policy allows you to create policies—essentially rules for your resources—so that your Azure environment meets your corporate standards and service level agreements. When you enforce a new policy, the Azure Policy Engine checks all current and future resources in the area you specify and notifies you of any non-compliance with assigned policies.
Azure has more than a hundred built-in policies you can choose to enforce, or you can create custom policies to better suit your needs.
In the webinar, Jussi did a demo in his own tenant to show us how Azure Policy Engine detects and notifies you of non-compliance. (Jussi had 23 non-compliant resources, but we won’t hold it against him!)
“This is the feature [in Azure] with the most capabilities,” explained Jussi. That’s because whether you use the Azure portal directly or you use a third-party tool, every rule you want to enforce in your tenant has to go through the Azure Policy Engine.
If you’re just getting started with Azure Policy, Stephane recommended assigning the policy an audit so that you can see the impact of that policy first. This way, you can catch unwanted side effects and adapt the policy as needed.
Jussi also recommended creating a test management group to define and test your policies before distributing them through multiple management groups and subscriptions.
Understanding Azure Blueprints
Similar to how a building architect uses blueprints, Azure Blueprints helps cloud architects design and deploy a collection of assets—including policies, Azure Resource Manager (ARM) templates, RBACs, and more—to ensure Azure resources comply with certain requirements.
Blueprints act like a template to helps engineers build and deploy new environments that meet your organization’s standards much faster than if you had to build and deploy resources one at a time.
“You can really fine tune what can be done at the subscription level as opposed to trying to keep multiple policies together and keeping track of those individually, you can bundle them together in a blueprint,” said Jussi.
So if you want certain subscriptions to be modeled with the same baseline structure, for example, the same policies, automatically deployed resources and resource groups, a certain type of virtual machine (VM), and RBACs, you can create a blueprint and deploy it in those subscriptions instead of deploying each one manually.
Managing hybrid environments with Azure Arc
Jussi also gave us a brief demo of Azure Arc, a new Azure feature currently in public preview. This powerful tool allows users to monitor, manage, and govern services that are not in Azure. So if you have on-prem and cloud infrastructure, or if you have services in another cloud as well as in Azure, you can push Azure policies across all of your platforms.
You can try out Azure Arc with VMs today as long as you have at least one VM anywhere other than Azure.
- Through your Azure portal, you open your lefthand menu and select Azure Arc down near the bottom.
- From there, you select one of your VMs that aren’t in Azure.
- Once you select a VM, you’ll see that there are several kinds of policies that you can push down to it.
Not only is this more convenient than having to switch in and out of portals for deploying policies, you also get data on those VMs in your Azure portal—making it a kind of one stop shop.
As an FYI: The billing details haven’t been announced, so there is still some uncertainty around how usage of this feature will be priced.
There are lots of aspects to cover when it comes to Azure tools and Azure governance. If you’d like to dive a bit deeper and actually see how some of these features work, you can watch the webinar.
ShareGate is also hosting Deploy, a full-day virtual event focused on Azure governance on May 7th. Jussi, Stephane, and six other Azure experts will offer their advice, tell you about the latest news, and answer your questions throughout.