Azure Landing Zone

An Azure landing zone consists of platform landing zones and application landing zones. It’s worth explaining the function of both in more detail.

  • Platform landing zone: A platform landing zone is a subscription that provides shared services (identity, connectivity, management) to applications in application landing zones. Consolidating these shared services often improves operational efficiency.
  • One or more central teams manage the platform landing zones. In the conceptual architecture, the “Identity subscription,” “Management subscription,” and “Connectivity subscription” represent three different platform landing zones. The conceptual architecture shows these three platform landing zones in detail. It depicts representative resources and policies applied to each platform landing zone.
  • Application landing zone: An application landing zone is a subscription for hosting an application. You pre-provision application landing zones through code and use management groups to assign policy controls to them. 
  • In the conceptual architecture the “Landing zone A1 subscription” and “Landing zone A2 subscription” represent two different application landing zones. The conceptual architecture shows only the “Landing zone A2 subscription” in detail. It depicts representative resources and policies applied to the application landing zone.
Getting the “As-is” of the current Azure Infrastructure

To get the current infrastructure and all relevant ID’s that we would be needing in subsequent Bicep scripts, you can use the Microsoft provided “Azure Resource Inventory” tool: https://github.com/microsoft/ARI

Decision Making: Design parameters of the Landing Zones

Design the Landing Zones and tailor how you would want it. There are several decision options.

Management Group Module

Visualisation on how the resulting Azure Landing Zones will appear when using the Microsoft Accelerator Tool. Note: this is not the end-state, as we are about to determine the desired end-state.

The recommended approach would be to apply Microsoft best practices, which basically is to deploy the standard management groups​ as per the CAF/WAF (Cloud Adoption Framework & Well Architected Framework) based on the earlier Conceptual Architecture.

In addition also add​ management groups that are NOT in enforcement mode, as we will be moving the existing subscriptions under these management groups in future.

  • Landing Zones \ Corp — (Audit Only)​
  • Landing Zones \ Online — (Audit Only)
  • Platform \ Connectivity — (Audit Only)​
  • Platform \ Identity — (Audit Only)​
  • Platform \ Management — (Audit Only)​

Design Questions:

  • Is a Confidential Corp & Confidential Online management group also required?​
  • Any other Landing Zones already required from the initial setup?​

Resulting parameters for the Bicep:

  • parPlatformMgAlzDefaultsEnable = true​
  • parPlatformMgChildren = Add the 3 Audit Only management groups​
  • parLandingZoneMgAlzDefaultsEnable = true​
  • parLandingZoneMgChildren = Add the 2 audit only management groups​
  • Depending on the answers there can be additional parameters.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.