Skip to content

Contact sales

By filling out this form and clicking submit, you acknowledge our privacy policy.

That didn’t go to plan: The end of the road for Azure Blueprints

Microsoft won't be making Azure Blueprints generally available, instead shelving the service in place of template specs and deployment stacks: here's why.

Sep 13, 2023 • 3 Minute Read

Please set an alt value for this image...

For quite some time, Microsoft has provided Azure Blueprints as a preview service you could use to deploy resources in a consistent and repeatable way. This might sound like a regular ARM template or any other Infrastructure as code (IaC) technology, but there are some key differences.

Blueprints allowed teams to define an architecture that includes resources like resource groups, Azure Resource Manager templates (ARM templates), policy assignments, and role assignments as artifacts in the blueprint. The team could then deploy those artifacts and maintain a connection between the blueprint and the infrastructure deployed by the blueprint.

This connection allowed blueprints to be versioned and teams to update, and even roll back, the blueprint-defined infrastructure using new and previous blueprint versions.

You could also parameterize your blueprints and pass the parameters down to the include resources, which allows you to easily reuse your blueprint to deploy the same architecture many times over.

Blueprints could also be locked, allowing the team defining the blueprint to prevent the deletion or modification of defined resources. Locking a blueprint, not to be confused with resource locks, is the only method available to create deny assignments in Azure role-based access control (Azure RBAC).

Pretty neat, right? 

Well, things don’t always go to plan.

No plan for general availability

Microsoft has decided not to take Azure Blueprints to general availability (GA). Instead, they’ll replace the functionality of Azure Blueprints with template specs and deployment stacks over the next few years.

Template specs allow you to define and store an ARM template for later use. Unlike infrastructure as code from an external repository, template specs are stored in an Azure resource group. The template spec can be versioned and access can be controlled with Azure RBAC. Template specs are generally available and already used to power a number of experiences with Azure, including capabilities like Microsoft Sentinel’s content gallery.

What are deployment stacks?

Deployment stacks are a new feature currently in preview that largely provide the same functionality as Azure Blueprints. They allow you to define a repeatable set of infrastructure as code and deploy that infrastructure across multiple scopes, like resource groups, subscriptions, and management groups.

Deployment stacks have many of the same capabilities as blueprints. For example, you can prevent deletion and modification of resources with DenySettings, similar to how locks worked on blueprints.

But there are some improvements introduced with deployment stacks. You now have greater control over what happens when a resource is removed from management. With Azure Blueprints, the resource was simply forgotten and left behind. With deployment stacks, you can choose to delete resources that have been removed from the stack—similar to how Terraform works.

Out with the old, in with the new

Microsoft doesn’t have any new tooling to help you move from Azure Blueprints to deployment stacks (yet). But you can use some of the existing tools to make the move.

One option is to export your blueprints using PowerShell cmdlets. The script below will export a blueprint and its associated artifacts to a folder.

      Install-Module Az.Blueprint

$BP = Get-AzBlueprint -Name "ExampleBlueprint" -ManagementGroupId "06894c9d-96f0-4b79-ba96-05440b13fd10"

Export-AzBlueprintWithArtifact -Blueprint $BP -OutputPath ExampleBlueprint
    

From there, you can work on converting all artifacts over to standard ARM resource definitions as part of a new deployment stack.

Another option is to employ the existing workflow to migrate to Bicep, using the resources deployed by the blueprint.

Other governance capabilities

Check out my latest course on A Cloud Guru, AZ-500: Manage Security Operations, for more information on Azure governance capabilities available to help you govern and secure your Azure infrastructure. We take a look at Azure Blueprints and other tools, like Azure Policy and Microsoft Defender for Cloud’s Cloud Security Posture Management (CPSM). 

Wayne Hoggett

Wayne H.

Wayne Hoggett is a Senior Author, Cloud at Pluralsight with 20 years’ experience in Microsoft infrastructure including Windows Server, System Center, Exchange, SQL Server and, Azure. He is a Microsoft Certified Trainer that has earned over 20 certifications from Microsoft, Terraform, Citrix and ITIL throughout his career.

More about this author