Deploying and managing your first Landing zone with Azure Blueprints

Wesley Haakman -

In my previous post I explained about Landing zones, their benefits and how Azure Blueprints fit into that picture. But how would you go about building your first Landing Zone for your customers? How many Blueprints do you need and are you going to write them from scratch? What about the learning curve? These are many topics and questions that have been discussed before and even though the Microsoft documentation on Azure Blueprints is really good, it can also be overwhelming. Let's find out what you need to get started.

So first of all, to get started with Azure Blueprints you really don't need a masters degree in Azure Resource Manager or JSON. Yes, when you're progressing and deploying more complicated environments this becomes somewhat of a requirement but you can ease into it, and manage that learning curve.

Getting started

Azure Blueprints come with a list of samples that you can use and build upon. This greatly increases efficiency when you're looking to implement specific standards or just looking to get started and familiarize yourself with Blueprints.

For this post, I'm going to focus on deploying and managing your Blueprint across different subscriptions using the Azure Portal. We're going with a single tenant and multiple subscription scenario here. Yes, this is documented very well by Microsoft but going through this with a use case provides context and it helps to understand the fundamentals of Blueprints before you're going full scale. For example leveraging Blueprints cross tenant with Azure Lighthouse or implementing pipelines and source control to manage your infrastructure with automation. Because in the end, this is what you want to do if you want to leverage the capabilities of Blueprints at scale.

Use Case

Let's do this based on a use case I've been using during Workshops. I find that it helps well to illustrate the concept and well.. Everything can use some Star Wars sauce.

JJ Binks – CEO of Cloud Adventures, just landed a contract with 3 large manufacturers: Incom-FreiTek, Sienar Fleet Systems and Astromech.

The contract includes hosting their solutions on Microsoft Azure and implement guard rails to ensure the environments are conforming with applicable laws and regulations. Even though the industries these manufacturers operate in are largely similar – there some nuances in the required guard rails. Each company also requires a landing zone to deploy their solutions in. All environments must be separated from each other.

To simplify management for Cloud Adventures, all solutions should be managed from a single tenant with a single source of truth.

  • Incom-Freitek operates out of Europe and requires their data to remain within West Europe and North Europe. Incom-Freitek is developing X-Wing Planes and requires an environment to deploy their consumer portals
  • Sienar Fleet Systems operates out of the United States and requires their data to remain within the US. Sienar Fleet Systems is building a prototype Stealth plane called "Corvette" and requires a safe environment for their developers to deploy solutions to.
  • Astromech operates globally but requires their data to remain in France. Astromech is building droids and wishes to leverage the IoT Capabilities that Azure provides.

Right.. So what's important here, let's sum it up:

  • We're dealing with 3 large manufacturers
  • We need to implement guard rails
  • There can be nuances in configuration per manufacturer
  • But we want a single source of truth

Then we have some specific requirements:

  • Incom-Freitek operates out of Europe and requires their data to remain within West Europe and North Europe
  • Incom-Freitek is developing X-Wing planes and requires an environment to deploy their consumer portals
  • Sienar Fleet Systems operates out of the United States and requires their data to remain within the US
  • Sienar Fleet Systems is building a prototype Stealth plane called "Corvette" and requires a safe environment for their developers to deploy solutions to
  • Astromech operates globally but requires their data to remain in France
  • Astromech is building droids and wishes to leverage the IoT Capabilities that Azure provides

Building Landing zone

As we're going with a single tenant approach and the customers are largely similar, we will separate them based on subscriptions. We can leverage Management Groups to group our customers and their subscriptions as "Manufacturers".

We will "store" the Blueprint at the management group level, making it available to all the subscriptions within the management group.

Ready to build that landing zone now. By navigating to the Blueprints and going with the "Create new" option you will be presented with the samples as mentioned earlier. Because we're not in the business of reinventing wheels - let's go with the "CAF Foundation" sample Blueprint.

You now have the option to name your Blueprint and define a location where you want to store the Blueprint. You can store the Blueprint at a subscription level, making that specific Blueprint only available to that subscription or store it at a Management Group Level which makes it available to any subscription within that group. As we want to manage the Blueprints with the least amount of effort and we're only going with slight nuances between our customers, let's go with the Management Group option.

After selecting the location you can choose to inspect and edit the artifacts (the stuff you're going to deploy using your Blueprint). But, for the sake of simplicity let's go with the defaults and save the draft.

Now that we have saved the definition we can pull it back up by navigating to to the "Blueprint Definitions" and click on the Blueprint we just created.

We can now choose to "Edit" or "Publish" the Blueprint. Note that you will always edit the definition and then publish it so that you can assign it to a subscription. Edit, Publish, Assign.

Click Publish Blueprint and version your Blueprint (make sure your versioning makes sense to you). Click Publish once more to publish your Blueprint

Now when you wait for the Blueprint to be published or navigate to an already Published Blueprint you will notice that the "Edit Blueprint" option magically transformed into an "Assign Blueprint" option.

We now have a Blueprint available for assignment with some basic policies to get started.

Back to the use case.. If all customers would have the same requirements, we could easily deploy the Blueprint to all three customers with a single assignment. But, all have slightly different requirements, specifically regarding the region their solutions will be deployed in. Let's take "Astromech" for example.  

"Astromech operates globally but requires their data to remain in France."
"Astromech is building droids and wishes to leverage the IoT Capabilities that Azure provides."

Cool. Let's assign the Blueprint. When choosing a location for the deployment of resource we will go with "France Central". This is where the Blueprint will deploy any resources that it requires. Additionally we're allowing a deployment of resources in "France South" as well. Last but not least, make sure none of the Resource Providers they need to deploy their IoT solutions are denied by the Azure Policy.

Once you've entered all the configuration you like, hit assign and the Blueprint will start deploying any configurations you have set. Note that you can choose a version you wish to deploy. As we've only published a "0.1" version, this is what we'll go with.

After the assignment is completed, you repeat the tasks for each customer but configure the assignment based on their requirements (for example: Assigning the Blueprint to Sienar Fleet Systems requires you to allow all United States regions.

What you will end up with is 3 subscriptions, configured with unique assignments but based on a single definition. In theory that means we only have to maintain that one definition and only manage the unique parameters for each customer. That's already a big win as opposed to maintaining a definition for each customer. As I've mentioned in my previous post - If you really look at your customers, they're probably not that different.

And if we look what was actually deployed, we can see that identical configurations but with different parameters were deployed for each customer. The same goes for Azure Policy. Note that Azure Policy can also be deployed on a Management Group level, just like Blueprints. However, this doesn't scale well as Management Groups are not cross-tenant. More on that in later posts.

With the basics set up, we can start benefiting from what we've build. If we edit the current Blueprint definition (Home >Blueprints > Blueprint definitions > BP-CAF_GettingStarted > Edit Blueprint) we can save it, publish it once more with a newer version and then update the assignment.

As an example, let's add a Policy that ensures threat detection is configured for SQL servers. You can achieve this by adding an Artifact and choose the Policy Assignment option. Once you've selected your policy click "add" and the artifact will be added to the Blueprint definition.

This specific policy doesn't take any parameters. If you're going with a Policy that does take parameters you can choose to configure the parameters at assignment time or hard code them into the definition. If it's a Policy that can have a different configuration per customer - go with the configuration on assignment.

When you're done, save the draft and once more click Publish Blueprint. Update the version of your new definition (In this example 0.2 would be the logical next version) and publish.

If we now look at the original definition a version 0.2 has been added.

Once published, if we go back to the assignment for a subscription (Blueprints > Assignments) we can choose to update the assignment and select our latest version.

Choose the version you wish to assign and click "Assign". If whatever you added does not require any parameters upon assignment, there's nothing you need to change or add as the original values are still there.  

You're now deploying the landing zones based on your own (custom) Blueprint and you can change the parameters per assignment. Notice that a part of the work you're doing here is repetitive. This means that automation can help you add efficiency to this process. This is also where "Single source of truth" becomes important. Even though you're now able to manage one single Blueprint definition, why not do that through Github or Azure Repos?

This is where managing your Blueprints as code will be a big win (knowledge of Azure Resource Manager and ARM Templates becomes somewhat of a requirement here, depending on what you're trying to achieve).

More on this in my next post on automating the process based on this use case with Blueprints as code somewhere in the next few days :)