Using Azure Blueprints to Simplify Cloud Environments

Gain awareness around some important elements related to Azure Blueprints. You may find specific use cases for this feature and consider how to maintain governance and compliance for an Azure cloud environment.

January 26, 2020 8 minute read

Building out and managing your cloud presence can be a daunting task. It may be simple enough when there’s a single environment, but as your company grows it may be necessary to branch out into additional environments within your organization. 

Making sure that each environment meets standards, requirements and compliance can quickly become a problem. The Microsoft Azure Blueprints feature seeks to make this easier. 

Similar to blueprints used in architecture to sketch a project’s design factors, Azure Blueprints allows cloud architects and information technology groups to build out and stand up new environments with a set of components to speed up delivery and development.

Blueprints can be used to deploy a number of resource templates and other cloud artifacts such as:

  • role assignments;
  • policy assignments;
  • Azure Resource Manager templates; and
  • resource groups.

Governance made easy

Azure Blueprints provides integrated tooling to help keep your resources under control and make sure everything is deployed as intended. Blueprints provide mechanisms to support typical lifecycle operations, ensuring that there are no surprises when deploying your environments.

The Azure Blueprint lifecycle works as follows:

  • Creation of blueprint (assigning all resources and artifacts that will be deployed)
  • Publishing the blueprint (this allows for the assignment of the blueprint to various environments)
  • Creating a new blueprint or modifying existing blueprint
  • Publishing the new version of the blueprint
  • Deleting older versions of blueprint
  • Deleting entire blueprint all together

One of the key factors in helping manage and govern your environments is when new blueprints are created or existing blueprints are edited, they are put into “draft” mode. When a blueprint is in draft status, it cannot be deployed until it’s officially published. 

In order to publish a blueprint, a version number must be applied, along with any notes that state any changes made to the blueprint. This allows administrators and owners to identify any changes that have been made and establish guidelines to ensure consistency and validity of any edits.

In addition to the change controls in place, Azure Blueprints also offers a resource locking functionality. The resource lock allows the protection of new resources from being tampered with, even with accounts that have the Owner role. Resources protected by resource locks have four states:

  • Not Locked;
  • Read Only;
  • Cannot Edit/Delete; and
  • Cannot Delete.

These assignments can only be removed by updating the blueprint itself and changing it to a different locking mode. Unlike other resources in Azure that can have locks overridden by users with the appropriate role-based access controls, this isn’t the case in Azure Blueprints. This security measure protects the consistency of the defined blueprint and the environment it was designed to create from accidental or programmatic deletion or alteration.

Additionally, Azure Blueprints can deploy a single compliant package to multiple subscriptions, streamlining environment creation; for example, ensuring matching environments across production, development and QA subscriptions.

Regulatory compliance 

Maintaining compliance with various regulations can quickly become a headache, especially when managing multiple environments at once. While Azure Blueprints can be used to create custom templates, they also help when there isn’t an established framework. The service offers a number of built-in blueprints for compliance with common scenarios and external regulations such as:

  • FedRAMP Moderate;
  • ISO 27001 (Standard, Shared Services, and ASE/SQL workloads);
  • PCI-DSS;
  • Canada Federal PBMM.

There are a number of other scenarios currently available with Microsoft adding new blueprints regularly. Utilizing these built-in samples can help speed up the deployment of compliant environments matched to production standards. 

Azure Blueprints vs other Infrastructure as Code options

There are a number of options available when it comes to making a decision on Infrastructure as Code (IaC) tooling. Additionally, upon first glance, ARM Templates and Azure Blueprints seem to overlap and perform the same tasks, adding yet another layer of confusion when there are two native solutions. 

Both features can be used to package an environment together and deploy Azure artifacts and resources. So, what’s the difference?

ARM Templates are documents that don’t exist natively within Azure – these templates are normally stored locally or in a central code repository such as Github or Gitlab. Once these templates are deployed, there is no connection between the template and the resources that have been deployed. This can lead to issues such as templates not being updated in a timely manner for any changes that are required for the resource (and future resources) or templates being updated without proper documentation as to what might have changed.

Azure Blueprints attempt to resolve this issue by maintaining the connection between blueprint definition and blueprint assignment. This relationship allows for tracking and auditing of deployments along with allowing blueprints to update multiple subscriptions at the same time. 

Microsoft Azure Blueprints architecture

ARM Templates and Azure Blueprints can also work hand in hand. There’s no need to abandon your existing templates in exchange for blueprints, as Azure Blueprints also offers the functionality to embed existing templates into your blueprint. This also has the added function of providing a central resource for your templates as well along with the additional assurance that they can be utilized to their fullest extent. 

There are also a number of third-party offerings that have similar features around governance and compliance. These tools offer a lot of the base Infrastructure as Code benefits, namely being able to standardize and automate deployments, but they have a similar problem to ARM Templates: all of your code base is stored outside of your environment. 

This adds another layer of management (Github, Gitlab, etc.) needed to ensure that your templates are secure and accessible. In addition, it lacks some of the features that Azure Blueprints provides, such as resource protection using Resource Locks and having native built-in controls for maintenance. 

How do blueprints work?

Now that we’ve covered the benefits and did a high-level review on the lifecycle of a blueprint, let’s take a closer look at what comprises an Azure Blueprint. A Blueprint consists of the following:

  • Blueprint directory – This will be the default blueprint name.
  • Blueprint.json – This is the main blueprint file.
  • Artifacts directory
  • Artifact files – These are the instructions for various CRUD operations.

Now that the standard blueprint layout has been established, we will take a closer look at each component.


This initial blueprint object includes properties about the blueprint, any resource groups to create and all of the blueprint level parameters, such as default and allowed values. Here’s a small example of a boilerplate blueprint.json:

boilerplate blueprint.json

Artifact files

The artifact files make up the bulk of an Azure Blueprint. Artifacts are also .json files and include resource groups, resource manager templates, policy assignments, and role assignments. Below is an example artifact for creating a policy assignment:

example artifact for creating a policy assignment

As you can see, these artifact files closely resemble ARM templates. As they follow similar syntax and composition, existing ARM templates can be used as artifacts to help integrate pre-existing workflows or configuration work that has been completed. There are a few common properties for an artifact:

  • Kind – This tells the blueprint what type of resource you are deploying. This can be template, roleAssignment, or policyAssignment.
  • Type – This will also be Microsoft.Blueprint/blueprints/artifacts.
  • Properties – This defines the artifact with any definitions, display names and parameters. You can optionally specify a different resource group from the one defined in blueprint.json.


There’s no doubt that Azure Blueprints is a powerful product with a number of great benefits for those who choose to utilize it. Organizations that choose to implement Azure Blueprints into their workflows will be able to deploy consistent environments in a streamlined fashion, speeding up the development and delivery of solutions hosted in Azure.

There’s no cost to use Azure Blueprints. As with other Azure Governance services on the platform, the only costs come from the resources deployed with the blueprints themselves. During the timeline of producing this article, the Azure Blueprints service is in preview status.

Getting everything configured can certainly be overwhelming with all of the moving components integrated into blueprints, but the Azure experts at WWT can help assist on your journey to a better, streamlined and compliant cloud strategy.

Get started today. Cloud Workshop
Share this