Azure Blueprints enable cloud architects to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements. An Azure Blueprint lays out what the finished product should look like. It’s the design, not the actual construction. A good example is the creation of a new resource group with predefined Contributor access for configurable user accounts. That way developers don’t need access at the subscription level, just at the resource group level. Again there are a lot of built-in blueprints. For instance Basic Networking which configures a virtual network with a subnet and a network security group. See the Artifacts tab in the Portal.
Blueprints can be saved in a management group or subscription that you have contributor access to. Azure Blueprints are currently in preview (status Oct 2021).
Blueprints are a declarative way to set up a new environment. It orchestrates the deployment of various resource templates and other artifacts such as:
- Role Assignments
- Policy Assignments
- Azure Resource Manager templates (ARM templates)
- Resource Groups
Blueprints can be versioned and deployed as a package via a CI/CD pipeline. Nearly everything you want to deploy via Azure Blueprints, can be accomplished with an ARM template. One major difference is the relation between “what should be deployed” and “what is actually deployed”. With Azure Blueprints, the relationship between the blueprint definition and the blueprint assignment is preserved. In ARM that’s not the case. Once deployed there’s no relation with the ARM template anymore. There’s no need to choose between an ARM template and a blueprint. Each blueprint is just a container of zero or more ARM templates. With Blueprints you simply don’t have to build complex, monolithic ARM templates anymore. You publish multiple ARM templates via a blueprint.
Blueprints can also use parameters. You can either enter the parameter value when assigning the Blueprint via the portal or you can use a default value. Let’s say you create an ARM template for a resource group. Then you can specify a default value for the region and have a resource group name specified at assignment time.
You can also implement different versions of a Blueprint.
We can also include policies in Blueprints. Policies make sure that only approved or expected changes can be made to the environment after initial setup. This ensures ongoing compliance to blueprint. Note that you can also choose to lock the Blueprint assignment. That means you can disable modification of resources contained in the Blueprint, even for owners and contributors. Modifications to resources can only be made by re-assigning the Blueprint, or even better, assigning a new version of the Blueprint. Obviously, a contributor or owner can still add resources. As an example, you can define a subscription and resource group containing a VNet with a certain – unchangeable – IP range. But the VNet owner can still give more people access to the subscription or create new resources within the subscription.
Think * Share * Integrate 