How to – Azure Policy via ARM Template

If you’ve worked with Azure for a while, you would know that one of the most efficient methods of deployment is ARM templates and one of the most powerful services is Azure Policy. What you might not know, is that you can combine the two for efficient, iterative and defined deployments.

A great point I saw recently on Twitter was that a lot of technical posts highlight features and how to use them but rarely go into why you should use them. Conscious of that, here are a couple of points on why I think you should make use of Policy via Template (PvT):

  • Quick deployment time – hilariously quick.
  • Repeatable defined structures – the exact policy definition, applied to the exact scope, with no possibility of user error.
  • Confident flexibility – Templates are idempotent; need to update the definition? Update the template, deploy the update, job done.

So if the “why” makes sense to you, let’s move onto the “how”. If it doesn’t, let me know! I’d love to hear your horror stories/use cases…

Templates can be deployed in several ways, for the sake of simplicity, I’m going to use two tools here. Visual Studio Code and Powershell. Currently you can only deploy subscription scope resources via Powershell or CLI.

There are some other differences to note. The schema for the template must be:

https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#

When deploying the template, it must be deployed to a location and given a name (the name of the template will be used if none is specified), that combination is then immutable for that location. So if you need to change location, you need to use a new name etc.

Now, let’s create our template. For this post, I am going to use an existing Template Definition and scope it to my Subscription. While you can pass the Template Parameters via Powershell Variable, for this post I am going to define them as a Template Variable. This is tricky piece of logic as they must be defined as a nested, object array. I also define the policyID via Variable. For existing definitions, you can get this via the Portal, or Powershell command

Get-AzPolicyDefinition | select PolicyDefinitionId -ExpandProperty properties | where displayName -Match "allowed locations"
{
    "$schema": "https://schema.management.azure.com/schemas/2018-05-01/subscriptionDeploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {},
    "variables": {
      "policyName":"Allowed Locations",
      "policyDefinitionID":"/providers/Microsoft.Authorization/policyDefinitions/e56962a6-4747-49cd-b67b-bf8b01975c4c",
      "policyParameters":{
        "listOfAllowedLocations":{
          "value":["NorthEurope","WestEurope"]}}
    },
    "resources": [
        {
            "type": "Microsoft.Authorization/policyAssignments",
            "name": "[variables('policyName')]",
            "apiVersion": "2018-03-01",
            "properties": {
                "scope": "[subscription().id]",
                "policyDefinitionId": "[variables('policyDefinitionID')]",
                "parameters": "[variables('policyParameters')]"
            }
        }
    ]
}

Now are Policy deployment is defined and ready for use, we deploy using Powershell:

New-AzDeployment -Name "pvtDeployment" -Location northeurope -TemplateFile 'C:\Users\username\Documents\WDA\PvT.json'

You should receive a succeeded message within your shell and you can verify via the Portal. As it was a subscription level deployment, head to your Subscription blade and check the Deployments tab. You should see the Template listed as the same name as you ran for the deployment.

You can then confirm your settings via heading to Azure Policy and the Assignments blade. You will see your Policy Definition assigned at the scope you set, using the Parameters you set.

Just to go back to an early point on why you’d use this option. Look at the duration of the deployment in the above screengrab – 1 second. You simply cannot beat that!

This can obviously be used for much more complex deployments, for example, defining your own policy inline and deploying via template. The possibilities are endless with one current exception; Subscription is highest scope you can currently use, hopefully Management Groups are on the roadmap and therefore the scaling capability is excellent.

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

How to – Choose an Azure Naming Convention

When working with Azure, as with many cloud based services, one of the difficulties you may have to deal with is naming standards. Common sense would lead you to applying a single naming convention to all resources. However, in Azure, as the name of the resource can actually be used for many different things, one single convention is quite difficult to achieve. Especially if your convention requires any real degree of complexity.

The most simple reason for having a good naming convention? You cannot rename resources in Azure.

In one of my earlier posts, I discussed the benefits of using the Azure Architecture Center, we visit this again for naming conventions. The general recommendations are as follows:

So let’s look at those in some more detail.

Short and Simple

This somewhat explains itself. However there are technical justifications too. For example, a Windows VM name has a maximum character limit of 15. Keeping it simple allows you to re-use the same logic regardless of resource type, location or service.

Affix some affixes

Where possible, make use of a prefix or a suffix to add clarity to your resource names. the most common are based on environment (prod, dev, test) or instance (A, B, C or 01, 02, 03).

While trying to do the above, make sure to reference back to the matrices of support.

Policy

Depending on whether your environment is brand new, or you’re trying to implement some control on an existing environment; applying your naming convention via Policy can speed things up. You can choose all of the usual options when it comes to policy, my preferred method is to create several policies scoped to resource types that deny deployment if naming convention doesn’t match. This avoids conflicts with any auto-deployed resources. Then a catch all policy to audit everything for compliance. An example policy for VMs is below:

{
     "properties": {
         "displayName": "VM naming pattern",
         "description": "Require naming patterns for VMs.",
         "mode": "All",
         "policyRule": {
             "if": {
                 "allOf": [
                     {
                         "field": "type",
                         "match": "Microsoft.Compute/virtualMachines"
                     },
                     {
                         "not": {
                             "field": "name",
                             "match": "az-????-##"
                         }
                     }
                 ]
             },
             "then": {
                 "effect": "deny"
             }
         }
     }
 }

This checks all of the fields listed, so for Virtual Machines, where Name is Not a Match for “az-????-##” then Deny. The match pattern is defined using standard Azure Policy conditions.

Tagging

Tags can form a one to many relationship for resources. Tagging all resources that are part of a project, or have a commonality adds additional metadata to resources without adding increased complexity to your naming convention. Tagging should be viewed as a complimentary option to a good naming convention rather than an alternative. They can also be applied via Policy, saving you time and effort!

As always if there are any questions, or suggestions on how you do naming in Azure, get in touch and I’ll add them to this post!

How to – Use a Public IP Address Prefix with a Virtual Network Gateway

On a recent project, a client had a requirement for all Public IP addresses to be part of a Pubic IP Address Prefix. This ensured they could both re-use and predict their IPs. Greatly simplifying Governance requirements and white-listing with partners.

However, once the Prefix was active, I went to create a Virtual Network Gateway to test some connectivity options. Being a simple test, I was using the Portal for deployment. I realised that the parameter defaults prevent you from using a Prefix IP as they are on the Standard SKU by default. If you’re creating a single VNG that is not linked to an Availability Zone, the Portal looks for a Basic SKU and you receive this error:

Now a quick fix was to simply select one the AZ SKUs, but I didn’t want that. Thankfully, Cloud Shell was my answer. Out of curiosity, I then tried the same process, but via Powershell. Using the exact same resources and parameters.

And…success! My guess is the flag that prevents you from using a Standard SKU Public IP address for a VpnGw1 SKU VNG is a parameter limitation rather than a technical one. The VNG works exactly as expected.

Hopefully this can save you some time if you find yourself in the same situation!

Bonus tip! When working in Cloud Shell, if there is a parameter you are unfamiliar with and not sure what it expects as input, type out the parameter and hit tab, it will list all allowed inputs:

How to – Troubleshoot your Azure Virtual Network Gateway

One of the most popular methods of connecting to Azure privately is via VPN. This can be a relatively simple process and is well documented by both Microsoft and 3rd party blogs. However, if you encounter problems, it can be difficult to get the data you need to troubleshoot efficiently. Especially if you don’t have access to both Azure and the local connection appliance.

In this post, I’m going to show you how to troubleshoot a Virtual Network Gateway and its VPN connection. As part of this, there are some required specifics:

If the above lines up with your environment, then let’s get started! (If not, get in touch and I might be able to help)

Troubleshoot a Virtual Network Gateway

Login to the Azure Portal, then click the search bar at the top, type “Network Watcher” and click on it to open your resource.

In the Network Watcher blade, underĀ ‘Network Diagnostic Tools” select ‘VPN Diagnostics’.

You’ll have to choose a Storage Account and a Container within to run the tests. If you don’t have one, you can create one from Network Watcher. The Storage Account doesn’t have to be in the same location as your VNG.

Click the checkbox for the VNG you want to troubleshoot, then click ‘Start Troubleshooting’

Once complete, you will see your ‘Troubleshooting Status’, you can see that for mine above it is shown as ‘Unhealthy’. To get more details, there is a Details pane just below with a ‘Status’ blade giving you more information about the problem and an ‘Action’ blade which gives suggestions on how to resolve the issue.

In this instance, the VNG as a resource is healthy, but the Connection it’s facilitating is not, so we need to dig further.

Troubleshooting a Virtual Network Gateway Connection (VPN)

In the same location we ran troubleshooting for the VNG, we will repeat the steps and select the Connection instead of the VNG this time. Select your Storage Account etc. as before and then click the Connection to troubleshoot. Then click ‘Start Troubleshooting’

Once complete, you will again see a ‘Troubleshooting Status’ and can get more information from the ‘Details’ pane.


As you can see from the above, I have a very simple fix to make, as my pre-shared keys do not match.

Hopefully this helps you out when trying to figure out why those VPN tunnels aren’t working.

As always, if you have any questions, get in touch!

How to – Reduce your Azure IaaS Costs

A regular starting point for most people when first using Azure, or any public cloud, is a virtual machine. Depending on your environment, VMs can be one of the most expensive resources. It’s no surprise that this can be a strong negative when considering a move to cloud.

Before anything is deployed, it’s important that you are aware of the tools that Microsoft make available to help you estimate your costs in advance. This can help both understand and avoid unwanted surprises with your bill.

First up is the Azure Pricing Calculator, with a bit of work, you can achieve an acceptably accurate cost estimate for an environment. I normally choose the default settings when it comes to pricing options (such as PAYG) as it gives me the most expensive and therefore safest estimate for a quick quote. If you have access to other consumption offers, ensure you are signed in so you can access their rates.

For this post I’m going to use a single VM estimate to display cost and changes. As it’s a single VM I have chosen a beast – M128m

Once you have your worst case estimate, it’s time to start making some adjustments to get that price down as low as possible. To do this, I recommend the following three options.

  1. Reserved Instances
  2. Automation
  3. Hybrid Benefit

First up, and most straight forward – Reserved Instances. They are a billing object that allows you to save money over a fixed period of time by paying for the usage up-front. From the screen grab you can see the savings can be approx. 64% for a three-year reserved instance. I have an old post that is still valid on RIs over here.

Again, you will pay the entire price up front, but look at the difference it makes to the monthly rate for our beast:

Next, modifying your usage hours using Automation. Now, this doesn’t have to be using Azure Automation and its Start/Stop solution as there are alternative like over on Azure MVP, Gregor Suttie’s blog. Whatever method you choose, update your usage hours in the cost calculator to see your savings, for this post I’m going to first remove weekends (average 8 days a month = 192 hours) and cut the remaining workdays in half (538/2). So instead of 730 hours, we get 269 hours and the appropriate reduction in price to our beast:

One thing to note at this point, if you’re using Reserved Instances, there is no point in using Automation to save on costs. RIs cover the full usage for the period.

Finally, the simplest to implement but arguably most complex option, Azure Hybrid Benefit. This is a licensing option that allows you to reuse your on-prem licenses in Azure. This is an option that can only be used in Azure and therefore a unique cost saving method. Applying it is simply a tickbox within your VM blade. Microsoft have a calculator to help you work out the licensing side of things, I’d recommend leaning on your LSP for this part as it can be a bit complicated and you need to make sure you’re compliant. You can see the savings below for our beast:

You’re probably already thinking it, can I layer these together and save even more? Absolutely.

Check out the reduction to the price of the beast if we apply AHB and a three year RI:

So what are you waiting for, head over to your Azure tenant and start saving some money on those VMs ASAP. As always, if there are any questions, get in touch!