Azure Blueprints

Azure blueprints

When creating a landing zone for your new Azure resources do you have to repeat the same set of configurations on your Azure subscriptions each time?  For example:

• Do you create the same Resource Groups and Azure resources (such as VNETs, Subnets, Recovery Service Vaults etc.)?
• Do you have to apply the same Role Based Access Control (RBAC) permissions to the Subscription or Resource Groups?
• Do you have to apply the same Azure Policies to each subscription to meet a regulatory compliance or company policy? For example, apply policies to restrict deployments to approved Azure regions, VM sizes etc.

Have you wondered if there was a better way to complete this repeatable configuration?  There is and it’s called Azure Blueprints.

Azure Blueprints is a Microsoft governance tool which works with Azure Policy and Azure Resource Manager (ARM) templates to define a set of Azure configurations.  An Azure Blueprint can be used to expedite the deployment and build of an environment to a particular set of standards, in a repeatable way.

With Azure Blueprint you can deploy the following artifacts:

1. Resource Groups.
2. Apply subscription permissions with Role Based Access Control (RBAC).
3. Launch Azure Resource Manager (ARM) templates to deploy Azure resources.
4. Apply Azure Policies and Initiatives to lock down the subscription.

Once a Blueprint has been built and tested it can be exported and redeployed to each new subscription(s) you have in your organisation.

At the time of writing Azure Blueprints is in Preview and is expected to be released into general availability shortly.

 How do Blueprints work?

The Azure Blueprint package can be built from the Azure Portal and applied to a specific subscription or to Azure Management Groups, including multiple subscriptions. Each Azure Blueprint package contains a group of artifacts, an artifact defines the deployment parameters such as Policy, Role, ARM or Resource Group.

During the build process a Blueprint will go through the following stages:

Stage 1 – Draft

Once a Blueprint has been built or changed, the Blueprint is saved as a Draft version.

Stage 2 – Published

Once the Draft version is complete the Blueprint is Published. This requires a version number and change note to be added to the Blueprint.  Azure always defaults to the latest version of the Blueprint.

Stage 3 – Assigned

Once the Blueprint has been published it is ready to be assigned to either a subscription or Management Group.  During the assignment process, it is possible to apply a lock to the deployed resources.  There are three possible locks for an assignment:

1. Don’t Lock – Deployed resources can be deleted.
2. Do Not Delete – Deployed resources cannot be deleted, even by subscription owners; they can be modified.
3. Read only – Deployed resources cannot be deleted or modified, even by subscription owners.

Once the Blueprint has deployed the specified resources, permissions, and policies the Assigned Blueprints section will show the latest version of the Blueprint.

If Azure Policies have been defined in the Blueprint, the specific policies are shown in the Azure Policy section of the Azure Portal.  Using the Azure Policy portal, we can see which resources are compliant or not.  Azure Policy will be discussed in a future blog.

Azure Blueprints will save you time when deploying your Azure landing zones and ensure your environment meets defined standards for a consistent approach when setting up Azure subscriptions.

If you would like more information on how to use Azure Blueprints for your deployments, please contact hello@cobweb.com for a demonstration and walk-through.