Azure Policy – Where to Start?

One of the positives of Azure is that it can offer you so many possibilities when it comes to deployment options. However, if you don’t implement the correct governance, this can very quickly become a negative. Historically, Cloud has had difficulties when it comes to sprawl; Azure Policy is a service that will help prevent that.

Azure Policy isn’t only a tool for prevention either. With the right policies, you can audit and enhance your environment in terms of efficiency, security and compliance. This gives you greater insight into your Azure deployment and confidence in your requirements.

Governance in Azure is addressed in many ways; a good place to start for overall strategy is the Azure Architecture Center. It has specific sections on Governance as well as overall design guidelines.

So how does Azure Policy work? At its core, it is an assessment service. You create policies with specific rules and scopes. Once the policies are active, they audit all resources in the included scope for compliance. Policies can range in complexity; you can use the default templates or create a custom one to meet your needs.

There are two core areas when dealing with Azure Policy:

Policy Definition

Every policy must have a definition. The definition contains all the details of the conditions under which it’s enforced. It also has the defined effect that occurs if the conditions are met. Definitions are created using JSON and the full structure is defined here. You will need familiarity with this if you are going to write your own custom policies.

Allowed Locations Policy Example:

{
    "properties": {
        "mode": "all",
        "parameters": {
            "allowedLocations": {
                "type": "array",
                "metadata": {
                    "description": "The list of locations that can be specified when deploying resources",
                    "strongType": "location",
                    "displayName": "Allowed locations"
                },
                "defaultValue": [ "westus2" ]
            }
        },
        "displayName": "Allowed locations",
        "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
        "policyRule": {
            "if": {
                "not": {
                    "field": "location",
                    "in": "[parameters('allowedLocations')]"
                }
            },
            "then": {
                "effect": "deny"
            }
        }
    }
}
Policy Assignment

A policy assignment is a policy definition that has been assigned to take place within a specific scope. Assignments range from Management Groups to a single Resource Group. The scope of the assignment refers to all the Resource Groups, Subscriptions, or Management Groups that the Definition is assigned to. Inheritance is enabled for all assignments. Therefore, a policy applied to a resource group is also applied to all resources in that resource group. However, you can include exclusions as a sub-scope of the assignment. For example, a Definition is assigned to a Subscription; all Resource Groups inherit the Definition but you need a single Resource Group excluded. Rather than redo the Assignment for each Resource Group, you can simply exclude it from the Subscription assignment.

Your First Policy

Now that you understand what Azure Policy is, let’s get started with our first policy. For this example, I’m going to prevent Public IP addresses being deployed within a Subscription. This is something I commonly add to IaaS projects that are connected to a local LAN.

Once you’ve logged in to the Azure Portal, make your way to the Azure Policy service, I normally use the search bar as below as it’s quick!

Once you’re on the Overview blade, a handy option for your first time is to click the Getting Started option. This details the steps to take and we’re going to start by browsing default Definitions so click that View Definitions option as below:

This will bring you to the Definitions blade. You will see a lot of built-in policies. To simplify things, click the search bar and enter “not allowed”, this will bring up the Definition we will use, then go ahead and click on the Policy name “Not allowed resource types” as below:

You’re now in the Definition page, where you can see the exact structure in JSON format. We’re going to jump straight to Assignment from here by clicking “Assign” as below:

This will bring you the assignment blade. Our first step is to set a scope. I’m going to go ahead and choose my Subscription and a Resource Group, then click “Select” as below:

We’re going to leave most of the settings as they are, but you can where you can set Exclusions below. We’re going to click the drop down arrow as highlighted:

This opens a huge list of resource providers and types. Thankfully, there is a search bar, so type in “public” to narrow the list and tick the checkbox for Microsoft.Network/publicIPAddresses, then click away from the list as below:

We’re almost there! You can see that publicIPAddresses are now defined as a parameter. So click the blue “Assign” button as below:

Now your policy is assigned, we need to give it a couple of minutes to propagate. Now, when I try to create a Public IP resource in my scoped Resource Group (I’ve used POSH in Cloudshell, but deployment method doesn’t matter) I’m told I cannot as it’s disallowed by policy:

You’ve now successfully applied your first Azure Policy! As you can see, even though this is a single Definition it is still very powerful. Your options to layer Definitions and apply custom ones allow for full control of your environment with very little effort. Azure Policy should be high on your list of priorities for your Azure deployments.

As always, if there are any questions, please get in touch!

Azure Migrate – Where to Start?

If you’re thinking about making a move to Azure, it’s important to first understand how to approach it. With the correct approach and sufficient planning, a migration can be straight forward, efficient and void of surprises.

Therefore, the place to start is the Microsoft Cloud Operating Model. This is a detailed white paper that allows you to create a strategy for migration. Covering cloud readiness, people strategy and technical analysis, it’s a comprehensive document. Once you have an understanding of your business strategy, read “Why am I moving to Azure?” and your people strategy, read “Who is moving us to Azure?” you can progress to the technical phase.

The vast majority of initial moves to Azure are often re-host migrations, or “lift and shift”, as these are most common, I will reference this scenario as an example. There are four stages:

The first step of the technical phase is to Assess. This means understanding what it is that you are moving and what the best process will be. This includes everything from involving the business stake holders, to cost calculation to application evaluation. This analysis should give you an output that not only details where the application could go but more importantly, where it can go.

Microsoft offer several tools to help with some of this. First up is Azure TCO. This allows you to estimate the cost savings you could make by migrating to Azure. Next is Azure Migrate, this is an assessment tool that is FREE and allows you to discover, document and assess your workloads and their dependencies. You can then create cost estimates for running them in Azure.

Azure Migrate Dependencies Example

Now that you have your environment discovered, grouped and sized correctly, you can begin to migrate your workloads. Microsoft provide a service for this also, Azure Site Recovery (ASR). This service allows you to replicate your servers from your on-premises environment. For most services it is application aware, meaning it can replicate services like SQL server without any data loss. Before you implement ASR it is important to use your data from Azure Migrate to capacity plan for your replication requirements. Taking this step allows for greater speed and efficiency during replication and migration of workloads.

Microsoft also provide a script repository for migrating large numbers of VMs at once. These can be from VMware, AWS, GCP or physical servers. There are some limitations, most restrictive is lack of support for Managed Disks, but you can always flip these manually later. The scripts and guide can be found here.

How long it takes to migrate your workloads is determined by your business requirements. However, once complete, it is vital that you revisit these workloads for optimisation. Azure Advisor can provide recommendations but the key areas to focus on are:

  • VM sizing – Ensure the VM is running on an appropriate size to gain maximum cost efficiency
  • Storage tier – Ensure the disks associated with the VM are using the correct tier to balance performance requirements against cost.
  • Reserved Instances – Once the VM is sized correctly, purchase Reserved Instances to achieve the maximum discount to run your workload for one to three years.

Now that your workloads are migrated and optimised, your final step is to ensure they’re secure and managed correctly. The best place to start with this process is Azure Security Center. This provides unified security management and allows you to take action to mitigate risk and implement actionable recommendations. This will include common requirements like disk encryption and anti virus. More advanced and platform specific features like Just In Time Access are also available.

So to recap, there is 1 prerequisite then 4 main steps:

  1. Understand and create your Cloud Operating Model
  2. Assess your current environment
  3. Migrate it!
  4. Optimise your utilisation
  5. Secure and Manage it

If all of the above is completed and optimisation and security are reviewed regularly you can be confident in the quality of your environment state. If you have any questions, feel free to tweet me @wedoAzure or leave a comment!