Azure Blueprints vs Azure Resource Manager template specs

Hello folks,

I've had a few conversations lately with IT pros and operations folks that made me think that there may be a disconnect or some confusion about the role of Azure blueprints and ARM templates specs.

There were comments like “are blueprint still even a thing?” and “I'm not bothering with Blueprints since templates specs are almost here.”

Maybe I'm missing the meaning of these interactions. Or there is a disconnect. I'm not 100% sure, however, if there is a chance that someone in the community is confused, I decided to cover the difference and when you would them. We're not going to take you through the creation of each of these since there are many tutorials and resources available online already.
For example:

The same can be said for ARM Templates Specs

So, let's start.

What Is Azure Blueprints?

In any enterprise you always have teams that are responsible for defining what and how resources are deployed in your environment. (on-prem, in the cloud or in both).  Your networking team defines the design, the IP addressing, the routing…  Your security team defines what services are allowed, who has access… Your legal department may have requirements for compliance such as where you can deploy your resources…  You get the picture.

Without any tools to allow you to tie all these requirements together you end up with a deployment process that can take a long time because every teams wants and needs to sign-off on your deployment.  And it makes it difficult to replicate since in most cases its tied together with custom scripting.

Azure Blueprint allows you to create a way to package all these components together and makes it super easy to “stamp” your blueprint on any environment dev, test, prod or other.


There are samples available here

What is Azure Resource Manager (ARM) Templates Specs?

new template specs.png

One of the greatest problems when managing your (IaC) with Azure templates is marrying the need for manageable, secure, versions-controlled way while sharing templates.  You can use GitHub, or any other “repo”, however if you're deploying linked templates for example the link requires either a publicly accessible point or a shared access signature to a blob therefore making them secure is more problematic.

Template Specs is a new resource type for storing ARM templates in a resource group.  The purpose of doing that is to allow more efficient sharing, deployment, and control of the Templates shared within an organization.  In effect your templates become a first party resource type stored in your subscription.  They can be standalone or modular, thus providing you with a very flexible way to deploy them.

And yes, Templates Specs also includes an RBAC (Role based access control) but it's to control who has access to the template itself and what I can do with it (Read access, vs contributor access for example). Not RBAC in terms of controlling what is the access of the resource deployed by said template.



Now that we've covered what both Blueprints and Templates Specs are, we understand that:

  • Yes, Azure Blueprints are still a thing and you should be investigating them in your own environment if you're not already, to ensure all your deployments conform to all the requirements of your organization.
  • Azure Resource Manager Template Specs will NOT displace the need for Blueprints since they server a completely separate purpose.

I can even see in the future, Azure Blueprint pointing at Templates Specs as artifacts within a blueprint.

There you have it folks.  Let me know in the comments below if you'd like us to cover specific subjects.



Thanks @Pierre Roman for Sharing with the Community !
Great Blogpost 8)

@James van den Berg Glad you like it.


This article was originally published by Microsoft's Entra (Azure AD) Blog. You can find the original article here.