Azure Blueprints are used in much the same way as traditional blueprints are. In much the same manner that an engineer or architect uses a traditional blueprint to design and build to spec, IT engineers can use Azure Blueprints to design and deploy a repeatable collection of Azure resources that adhere to certain requirements and standards.
Azure Blueprints allow the IT professional to orchestrate the deployment of resource templates and other Azure artifacts, including role assignments, policy assignments, resource groups, and resource manager templates. The service is backed up by Azure Cosmos DB, which is globally distributed. Objects are replicated to multiple Azure regions to provide both highly available and low-latency access to those objects, regardless of where the Azure Blueprints objects are deployed.
Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as:
Role Assignments
Policy Assignments
Azure Resource Manager templates (ARM templates)
Resource Groups
The Lifecycle of an Azure Blueprint
Most resources in Azure have a natural lifecycle. Blueprints in Azure Blueprints are no different as they are created and then deployed. When they are no longer needed, they are deleted. As such, Azure Blueprints supports typical lifecycle operations and even builds upon them. Azure Blueprints provides support for typical continuous integration and for continuous deployment pipelines for companies that manage infrastructure as code.
The typical Azure Blueprint lifecycle consists of:
Creation of a blueprint
Publishing of the blueprint
Creating or editing a new version of the blueprint
Publishing a new version of the blueprint
Deletion of a specific version of the blueprint
Deleting the blueprint altogether
Blueprint definition
A blueprint is composed of artifacts. Azure Blueprints currently supports the following resources as artifacts:
Resource | Hierarchy options | Description |
Resource Groups | Subscription | Create a new resource group for use by other artifacts within the blueprint. These placeholder resource groups enable you to organize resources exactly the way you want them structured and provides a scope limiter for included policy and role assignment artifacts and ARM templates. |
ARM template | Subscription, Resource Group | Templates, including nested and linked templates, are used to compose complex environments. Example environments: a SharePoint farm, Azure Automation State Configuration, or a Log Analytics workspace. |
Policy Assignment | Subscription, Resource Group | Allows assignment of a policy or initiative to the subscription the blueprint is assigned to. The policy or initiative must be within the scope of the blueprint definition location. If the policy or initiative has parameters, these parameters are assigned at creation of the blueprint or during blueprint assignment. |
Role Assignment | Subscription, Resource Group | Add an existing user or group to a built-in role to make sure the right people always have the right access to your resources. Role assignments can be defined for the entire subscription or nested to a specific resource group included in the blueprint. |
Azure Blueprints vs Resource Manager Templates
Azure Blueprints is intended to assist with environment setup. Such environments often include Azure resource groups, role assignments, different policies, and Resource Manager template deployments. Blueprints are essentially packages that pull these types of resources and artifacts together. These packages can then be composed, versioned, and assigned to a subscription. Such blueprint packages can also be audited and tracked.
Now, with all of that being said, almost everything that you’d want to do with Blueprints can also be done with Resource manager templates. So, what’s the difference?
Resource Manager templates are documents that don’t natively exist in Azure. Such templates are typically stored locally or in source control. Once a Resource Manager template has been used to deploy Azure resources, there are no longer any active connections or relationships between the template and the resources deployed from it.
Azure Blueprints differ from templates because even after deployment of resources from a blueprint, the relationship between the blueprint definition and blueprint assignment (i.e., what was deployed from the blueprint) remains intact. Preserving this connection allows for tracking and auditing of deployments. Another benefit of blueprints is that a single blueprint can be used to upgrade multiple subscriptions at once.
Because blueprints can consist of Resource Manager template artifacts, previously developed Resource Manager templates are reusable with Azure Blueprints.
Azure Blueprints vs Azure Policy
An Azure policy is essentially an access system that provides default allow and explicit deny on new and existing resource properties to which the policy is applied.
An Azure Blueprint is a package for creating specific sets of standards and requirements that govern the implementation of Azure services, security, and design. Such packages are reusable so that consistency and compliance among resources can be maintained.
A policy included in a blueprint offers the ability to create the correct pattern or design when the blueprint is assigned. Additionally, a policy inclusion ensures that only approved changes can be made to the resources or environment to which the blueprint was assigned. This ensures ongoing compliance with the blueprint.
Summary
Azure Blueprints are essentially no different from architectural blueprints that building architects use to design and build large buildings. They are actually used in much the same way. While architects use traditional blueprints to design and construct building to certain standards and specifications, Azure architects and admins use Azure Blueprints to design and architect Azure solutions to specific standards and specifications.
The lifecycle of an Azure Blueprint begins with the creation of the blueprint and then the publishing of the blueprint. New versions of the blueprint are then created and published as needed. The lifecycle of an Azure Blueprint ends with deletion of specific versions of the blueprint, and then of the blueprint itself.