In my last post I went through want Azure Landing Zones are. In this article I’ll break down the 8 core areas that make up the Azure Landing Zones.
What Are the 8 Core Blocks of the Azure Landing Zones and why do we have them? The Azure Landing Zones are broken down in to 8 sections this is to offer better administrator and create logical boundaries for roles that are going to support the environment.
- Enterprise Enrolment
- Identity and Access Management
- Management Groups and Subscription Organisation
- Management Subscription
- Connectivity Subscription
- landing Zones
- Sandbox Subscriptions
- DevOps
These are our 8 areas, but what do they do?
Enterprise Enrolment
This is an area that gets over looked at lot when companies start using Azure, and that is how do you manage and administer your Azure Subscriptions? Do you have a CSP, EA MCA, MCP or PAYG? Who creates the Subscriptions? That’s all part of this section and you ease a lot of that pain by having a think about the process of creating new subscriptions and who become the owner of that subscription. Microsoft have recently brought at a module to help with this called Subscription Vending and this can be added directly to you infrastructure as code (IaC) to help automate the provisioning of subscriptions. I’ll go more into this in a future article.
For more info on Subscription Vending Subscription vending – Cloud Adoption Framework | Microsoft Learn
Identity and Access Management
Identity is a critical piece to think about as without user accounts the environment can’t be accessed or used. In this section you start to think about security assurance and identity authentication and what controls you want to put in place to help protect your cloud environment. Azure is backed with Azure Active Directory or Microsoft Entra as it is now known. For businesses that have on premise Microsoft infrastructure you’re likely to already have Active Directory, you may have already started to consume cloud service like Office 365, Microsoft 365, or Dynamics. This will mean that you’ve already got lots of users with usernames and passwords and it’s in this section that you start to look at how you’re going to manage these within your Azure Landing Zones, so a section has been made to cover this so you can bring your existing Azure Tenant that you may have with an existing cloud presence and reuse that. Or you may want to migrate your users to Microsoft Entra/Azure Active Directory. All is possible with this section.
Management Groups and Subscription Organisation
This section is at the core roots of what the Azure landing Zones are all about. In our management group structure Microsoft offer a suggested structure that is advised not to deviate from too much without having to create lots of addition code and comes with an administrative overhead. Its suggested that you keep with the default structure as in the diagram above. But under Landing Zones, feel free to do whatever suits you. The reason behind this thinking is that Azure Policies are assigned to each Management Group and if deviate from the default structure the Azure Policies don’t quite get assigned to the correct management group.
Azure Policies? These are the gold dust of Azure Landing Zones as these provide governance to your Azure environment and be adjusted to meet whatever compliance standard you need to. for example, if you’re in Canada and need to conform to the Canadian federal government PBMM compliance or NHS and UK government you can use Azure Policies to ensure you have automated auditing, security, and enforcement of governance policies in place to meet your compliance requirements.
Management Subscription
This area is where all logs, monitoring and things like Sentinel go. This is ideal for support staff so they can go and find out what is happening within the Environment. Log Analytics is configured here, and all logs are saved into this central location so reports can be run on security, audit, and diagnostics. All monitoring is also configured here.
Connectivity Subscription
This is the core element for all connectivity and networking. This area will host your express route or Site to Site VPN on either a HUB and Spoke or VWAN network topology. Also, your Firewalls Web Application Firewall will also be hosted here so you have a single point of entry in/out of your environment.
Landing Zones
This area can be customized to suit your companies’ requirements. There is limitation on how many level of Management Groups you can have (currently 6). Ideally this needs to fit with how your company operates, it could be for example you have 3 tiers Online, Production and Test.
Online
would hold all application that are internet facing.
Production
This would hold all non-internet production applications.
Test
This could hold all dev or test environments that require connectivity to the core network.
What you choose will be dependent on your requirements.
Sandbox Subscriptions
This can be used in 2 different ways; its main purpose is to provide an area for developers or users to play and learn/develop in without having to worry about impacting the production environment. here there is no connectivity by default to the core network and all virtual networks are hosted in complete isolation. Therefore, its ideal for testing and developing. Some uses are to have this subscription on a temporary basis to help reduce costs or to have all your core development done here before moving into Test/Pre-prod under you landing zones where network connectivity is present for testing.
DevOps
This kind of full outside the ALZ but is linked by the fact this is where you’ll be deploying your ALZ via IaC. This can be done using any DevOps management system that you like, but I’ll only be looking at Azure DevOps and GitHub as they are currently the only ones Microsoft have created Pipelines for and code is readily available and tested with these systems. There are 3 ways to deploy the ALZ:
ARM templates
This is done using a wizard style process and will create you the basic environment and a GitHub repo with GitHub action to manage. This is very limited and is likely to not to be developed much going forward due to the limitations of ARM templates.
Bicep
This is deployed into either Azure DevOps or GitHub and uses Microsoft IaC Bicep.
Terraform
This is deployed into either Azure DevOps or GitHub and uses a purpose built terraform Module.
I’ll be going through each of these deployments in future articles, so watch this space.