When I saw that there was a repository available where Azure Landing Zones (previously known as Enterprise Scale Landing Zones) was being “bicepified”, I had to test it out! 💪

Since I haven’t been working extensively with Bicep lately, I needed to play around with it and get more comfortable using it. I also wanted to see how this could be orchestrated. Plus this gave me an excellent excuse to tinker some more with GitHub workflows! 🚀

Now the ALZ-Bicep repository has launched version 0.7.1 with a mini orchestration module, but before this there was only a orchestration for demo purposes that could not be deployed.

I started looking at the deployment flow article for tips on logic, and worked from there. This was only about playing around anyway, and not something for production use.

There was also a GitHub workflow that I can’t find at the moment, but it now seems to be obsolete anyway.

During the course of testing ALZ-Bicep I was made aware of a management group module made by Tao Yang, and immediately incorporated this instead of the builtin. It is more flexible, and I like that it does not assume a managment group hierarchy, but enables you to create it yourself. Also it sets a default management group for your new subscriptions, which I previously did not know about.

Here you can find guide for deployment (not extensive, and might require some tinkering).

Here you can find a readme which explains structure, workflows, and some thoughts.

Basically:

• The deployment is done in “levels”:
  • Level-1: Management Group Hierarchy, Custom RBAC Definitions, Custom Policy Definitions.
  • Level-2: Default ALZ policies, hub networking (FW, Bastion, vnet++), central logging, policy assignments, and RBAC assignments.
  • Level-3: Spoke subscription placement in management groups, and spoke networking.
  • Level-4 (planned): Should have deployed resources to spokes/hub, but will most likely not be realized.
• Each level is a separate workflow here.
• You deploy the level by updating or touching the parameter files.
• Pull Requests from another branch to main will trigger an ARM What-If and post comment to PR.
• Pushes to main will ask for confirmation and deploy infrastructure if confirmed.
• Level-4 in the repo is just my initial thoughts on possible resource deployments into hub and spokes.

I also had to edit some of the modules in CARML (Common Azure Resources Module Library) and ALZ-Bicep, but did not want to commit any of my shenanigans to the official repositories. Therefore I just made a local copy in my repo and pointed to that.

Take this for what it is, an experiment with the great ALZ-Bicep library/framework. This tool holds great potential, and will help many organizations embrace Infrastructure as Code. This is not the end-all be-all of IaC, and more tools are available, but it does provide clear instructions on how to deploy an entire org structure with Bicep.

I am looking forward to future versions of this! Seems to be an important focus for Microsoft, and together with the CARML (mentioned above) we are seeing lots of Bicep improvements. I love it!

Please let me know if you find it useful or if you see any obvious errors.