Azure Policy - Allowed Resources

In previous articles we have discussed some of the challenges of managing an architecture on Azure. Once of the items we discussed was an approved list of services that can be used.

With Azure one of the features is called Azure Policy. The definition of Azure policy is:

Define and apply standards to resources in your environment. Prevent the creation of undesired resources, enhance new resources with additional elements, and audit and remediate resources already in your environment.

With Azure Policy there are some specific policies which will allow you to control the types of resources that you can use. The specific policies I am referring to are:

• Allowed resource types

In this policy it will allow me to define specific types of resources on Azure which can be setup and if the resource I try to create is not on the list then I will be blocked from creating it and there will be an error when the resource is deployed due to a policy violation.

From an architects perspective this policy is a great way to get a lot of control on your Azure Estate. You can apply the policy at many levels and also can have different implementations of the policy at different levels or scopes. A scope for a policy might be:

• Management Group
• Subscription
• Resource Group

I think in the real-world how I might choose to use this is to have different policy implementations at different levels for example I might use management groups to define the following management groups:

• R&D
• Development
• Testing
• Production

In R&D I might allow all resource types so that people can choose any resource to evaluate a service on Azure and to see if it adds value to us.

In production I would lock things down the most. These could be only services that have been "approved" to be used. The approved services would allow agile teams to deliver on a set of technologies that are established for the organisation. It might mean that we have plenty of experience in development and operations with these technologies. As an architect I would be able to block the agile team deciding to use something which is not approved and they would follow a process of proving the value of the Azure Service in the R&D area and then the if the service was found to be suitable then we would involve a service introduction process which means we would define principles and Blueprints about where we would use the service and we would ensure that developers had some training using it and the support and operations team would be trained to support the solution. This would create a good process which makes sense and stop the scenario where a team implements something completely differently to another team or implements something then the team is disbanded and we identify they have been using a technology that no one knows how to use.

Within the management group level scope we can also use the subscription and resource group levels. This gives us very fine grained control over the levels we apply the policy at. Lets imagine within the production management group we have subscriptions for centres for excellence. Maybe our web app team has a subscription. In here we could control the services used within resource groups so that all apps could use App Service and Application Gateway, Traffic Manager, SQL Azure DB. We may however restrict most other things (in particular virtual machines). This would make sure that the web app teams are working inline with the centre of excellence for Web Apps in our organisation which wants people to build apps on PaaS services on Azure.

Hopefully this article gives a great view of how the Allowed Resource Type policy can be a significant win for managing your Azure architecture and applying some governance over the services you choose to use.