Cost Governance with Azure Policy

[fbinotto]

Introduction

Hi folks! My name is Felipe Binotto, Cloud Solution Architect, based in Australia.

This post is about how you can implement Cost Governance with Azure Policy.

I have delivered many Well-Architected Optimization Assessments and some of the policies here can help you to get closer to that Well-Architected state.

Cost governance is an essential aspect of managing any cloud infrastructure. Azure Policy is a powerful tool that can help implement cost governance measures within your Azure environment. With Azure Policy, you can define and enforce rules to control costs, monitor usage, and optimize your resources.

These policies can be used to prevent the creation of resources that are not compliant with cost-saving measures or to apply tags to resources that identify them as cost-related resources. You can also use policies to track resource usage and generate alerts when certain thresholds are reached, allowing you to take proactive measures to optimize your resources and control costs.

Throughout this article I will provide some examples of Azure Policies you can use for cost optimization.

Naming convention

A good naming convention is important for cost governance because it helps ensure that resources within a cloud environment are properly identified and categorized, making it easier to manage and control costs.

When you have a standardized naming convention, you can easily identify which resources belong to which projects, teams, or departments, and how they are being used. This information can help you better understand your cloud usage patterns and identify areas where you can optimize your costs.

For example, with a good naming convention, you can easily identify which resources are being used for development and testing, and which resources are being used for production. This can help you avoid over-provisioning resources for development and testing that are not being utilized to their full potential, which can save you money.

Additionally, a good naming convention can help you track usage and spending over time. By consistently naming resources in a standardized way, you can easily generate reports and analyze usage trends over time, allowing you to identify areas where you can further optimize your costs.

Overall, a good naming convention is a crucial part of cost governance in a cloud environment. It can help you identify and categorize resources, track usage and spending, and optimize your costs over time.

Here is how you can enforce naming convention using Azure Policy.

"policyRule": {
      "if": {
        "anyOf": [
          {
            "allOf": [
              {
                "field": "type",
                "equals": "Microsoft.Network/virtualNetworks"
              },
              {
                "field": "location",
                "equals": "australiaeast"
              },
              {
                "not": {
                  "anyOf": [
                    {
                      "field": "name",
                      "match": "aue-prd-net-###"
                    }
                  ]
                }
              }
            ]
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }

In the example above, we evaluate if a Virtual Network will be deployed in Australia East and if so, it must adhere to the naming convention in the format aue-prd-net-### - the ### means any three numbers as a suffix of the string.

We are using the match operator which accepts “#” for digits, “?” for characters and “.” for numbers or characters.

We could also use the like operators instead and require the following format – aue-prd-net-* - which implies we allow any number of characters or digits as a suffix of the string.

Allow only LRS Storage Account on Non-Prod environment

I have seen many companies which have GRS or ZRS or even RA-GRS Storage Accounts in non-production environments. Sometimes that was intentional but most of the time it is not.

LRS storage accounts can be a cost-effective and reliable storage option for non-production environments. With high durability and availability, and easy implementation and management, LRS storage accounts can help you optimize costs while still ensuring that your data is protected and accessible.

Here is how you can enforce the use of LRS type of Storage using Azure Policy.

    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
          },
          {
            "field": "Microsoft.Storage/storageAccounts/sku.name",
            "notEquals": "Standard_LRS"
          }
        ]
      },
      "then": {
        "effect": "deny"
      }
    }

In the example above, we evaluate if the Storage Account to be deployed has the Standard_LRS sku and deny the deployment otherwise.

Audit orphan resources

Auditing orphan resources is an important part of cost optimization in a cloud environment because it helps you identify and eliminate resources that are no longer being used but are still incurring costs. Orphan resources are resources that are no longer associated with a project, application, or user, but are still consuming resources and incurring costs.

Some resources don’t incur any costs, but it is good practice to track and remove them for other reasons such as security, compliance, and governance.

Here is how you can audit Public IPs which are unattached using Azure Policy.

    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.Network/publicIPAddresses"
          },
          {
            "field": "Microsoft.Network/publicIPAddresses/ipConfiguration.id",
            "equals": "null"
          }
        ]
      },
      "then": {
        "effect": "audit"
      }
    }

In the example above, we audit any Public IP Addresses which don’t have any IP configuration and are therefore unattached.

Next example is how you can audit Disks which are unattached using Azure Policy.

  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Compute/disks"
        },
        {
          "not": {
            "anyOf": [
              {
                "field": "Microsoft.Compute/disks/diskState",
                "equals": "Attached"
              },
              {
                "field": "Microsoft.Compute/disks/diskState",
                "equals": "Reserved"
              }
            ]
          } 
        }
      ]
    },
    "then": {
      "effect": "audit"
    }
  }

In the example above, we audit any Disks which are not attached or reserved and are therefore unattached.

Those are only a couple examples of auditing for orphan resources, but you can extend this to other resource types.

Audit and Enforce the use of AHUB

Azure Hybrid Benefit allows customers to use their existing on-premises licenses for Windows Server and SQL Server to run workloads in Azure. By using Azure Hybrid Benefit, you can save up to 40% on the cost of running Windows Server and SQL Server workloads in Azure.

Here is how you can audit AHUB usage using Azure Policy.

    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "in": [
              "Microsoft.Compute/virtualMachines",
              "Microsoft.Compute/virtualMachineScaleSets"
            ]
          },
          {
            "equals": "MicrosoftWindowsServer",
            "field": "Microsoft.Compute/imagePublisher"
          },
          {
            "equals": "WindowsServer",
            "field": "Microsoft.Compute/imageOffer"
          },
          {
            "field": "Microsoft.Compute/imageSKU",
            "in": [
              "2008-R2-SP1",
              "2012-Datacenter",
              "2012-R2-Datacenter",
              "2016-Datacenter",
              "2019-Datacenter"
            ]
          },
          {
            "field": "Microsoft.Compute/licenseType",
            "notEquals": "Windows_Server"
          }
        ]
      },
      "then": {
        "effect": "Audit"
      }
    }

In the example above, we audit if VMs or VMSS on any of the listed “ImageSKU” are using the “Windows_Server” license type. If they are not, it means AHUB is not enabled. Make sure you include any other SKUs you may be using in your environment.

Now let’s look at how we can use Azure Policy to enable AHUB.

  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "in": [
            "Microsoft.Compute/virtualMachines",
            "Microsoft.Compute/VirtualMachineScaleSets"
          ]
        },
        {
          "field": "Microsoft.Compute/imagePublisher",
          "equals": "MicrosoftWindowsServer"
        },
        {
          "field": "Microsoft.Compute/imageOffer",
          "equals": "WindowsServer"
        },
        {
          "field": "Microsoft.Compute/imageSKU",
          "in": [
            "2008-R2-SP1",
            "2012-Datacenter",
            "2012-R2-Datacenter",
            "2016-Datacenter",
            "2019-Datacenter"
          ]
        },
        {
          "field": "Microsoft.Compute/licenseType",
          "notEquals": "Windows_Server"
        }
      ]
    },
    "then": {
      "effect": "append",
      "details": [
        {
          "field": "Microsoft.Compute/licenseType",
          "value": "Windows_Server"
        }
      ]
    }

Built-in Policies

In addition to the custom policies, I have listed in this post, there are some built-in policies that can help with cost savings too.

Allowed VM SKUs: This policy allows you to specify a list of allowed virtual machine SKUs that can be deployed in your environment. By enforcing this policy, you can prevent users from deploying expensive or unnecessary virtual machine SKUs that can increase your cloud spend.

Network interfaces should not have public IPs: This policy restricts the creation of public IP addresses, except in cases where they are explicitly allowed. By limiting the creation of public IP addresses, you can prevent unnecessary exposure of resources to the public internet, which can help reduce security risks and cloud spend.

Require tag on resource: This policy enforces the use of specific tags on resources in your environment. By enforcing tagging, you can better identify and categorize resources, which can help you track usage and spending, and optimize your costs over time.

Conclusion

In conclusion, Azure Policy is a powerful tool that can help implement cost governance measures within your Azure environment. By using policies to enforce cost controls and track usage, you can optimize your resources and control costs. Implementing Well-Architected Optimization Assessments can provide a framework to assess and optimize your cloud architecture, helping you to achieve a Well-Architected state for your Azure environment.

I hope this was informative to you and thanks for reading!

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.