Azure landing zones: a closer look

Prefer to read our insights? Read our transcript below: 

Sam: Hello again everybody and thanks for joining us once again.  

In our last session, we started to explore the Ready Phase of the Cloud Adoption Framework. We saw that for a successful adoption of Azure, organisations need to understand their operating model, and that would lead on to how they plan to deploy to Azure via a landing zone.  

Gina: Yep, that’s right and in this video, we are going to take a slightly closer look at the landing zones, which are the key foundation for all your Azure deployments.  

First up will be the ‘start small and expand’ landing zone, which is a popular choice for many organisations wanting to get into the cloud quickly and build as they go.  

Organisations will deploy their shared resources which acts as their Platform zone, into a resource group on an Azure subscription. They will then deploy other resource groups to act as their application zone into that same subscription.   

To make this a success, the organisation will need to implement a baseline through their Platform zone, known as a minimum viable product or MVP. This will include all the tools and resources needed to meet minimum best practise.  

So, Sam, take us through what we need to include in the management baselines and cover off the first one for us.   

Sam: Thanks Gina, alongside the obvious resources you will need such as Microsoft Entra for your identity service, you will need to consider three key areas to create your baseline. These are:  

• Inventory and visibility/monitoring of your estate.  

• Operational compliance so your infrastructure is less likely to have an outage due to configuration or lack of patching. 

• Protect and recover so you can recover data to another site from a backup and protect against threats to your workloads with security monitoring. 

Arguably inventory and visibility are areas that are under invested in by organisations. However, if done properly, it can both help prevent issues as well as report on failures so that they can be remediated quickly.  

Let’s look at some of the tools to help you in this first area of Inventory and visibility  

You have Azure Service health alerts, Azure Monitor, Azure Network Watcher.  

Azure Monitor is a good tool to focus on here and a powerful tool at that. It can monitor, diagnose, and alert on changes or issues within your environment.   

The best bit is if you are using the start small and expand landing zone approach, Azure Monitor can expand and grow with you.   

You can start with baseline practices like Virtual Machine insights, which can then expand to using specific interactions from Azure Monitor application insights.   

Think of Azure Monitor like driving a car: the infrastructure is the car itself.  

However, Azure Monitor is the dashboard showing performance metrics like CPU usage or storage capacity and the warning lights on that dashboard, which is like showing diagnostic settings.  

Lastly, it would also be the car alarm, which you could compare to the alerting rules for notifying you of issues, maybe through service desk tickets or bug reports being sent back to a developer’s tasks whether this is in Azure DevOps or GitHub. 

Pretty cool huh!  

Gina, what about operational compliance?  

Gina: sure, for operational compliance, some of the tools to use are, Azure Automation update management for ongoing patch management. 

Azure Policy to enforce key policies for the environment like deploy Defender for Cloud if it doesn’t already exist.  
 
Then lastly, configuring infrastructure as code, which could be using Azure Bicep, or an Azure Resource Manager template, or even a third-party option like Terraform.  

Probably one of the most important from that list would be the Azure policies. This is because, yes, it can help with governance for instance by making sure your data is kept in a specific region. But it can also support some of the other items in our list.  

For example, you could create an Azure policy which stated that all Virtual Machines need to use Azure Automation update manager for their patching. The Azure Automation Patch Manager would then handle the actual patching process.   

This then means that no VM is left unpatched due to misconfiguration.  

Sam: Great, so for protect and recover you have Azure Backup and Azure Site Recovery to help recover your workloads and Microsoft Defender for Cloud for the Security aspect.  

We will focus on Azure Backup as it is typically something all businesses will deploy. 

Azure Backup will allow you to define what workloads are getting protected for backup. This is all done through the Business Continuity Centre in the portal. 

The platform manages which type of vault is setup either a backup or recovery vault. You only need to define backup frequency and retention. Advanced features like Instant Restore which allow for quicker restores from snapshots but may incur extra costs. It's about balancing recovery time and recovery point objectives. 

Now, don’t worry if you wanted more depth on these security tools – we have a separate video series that covers these.  

Now Gina will explore how Enterprise landing zones differ from ‘start small and expand’.   

Gina: Okay so even though using the same resources and tools, the unit of measure is now a subscription instead of a resource group.  

So, our Platform zones, which managed by Central IT hold our shared resources and are in separate subscriptions so that they can be independently managed and scaled. 

For example, they manage the identity subscription, ensuring zero trust principles are adhered to and granting only necessary roles to users that really need it and that it is reviewed. Also, that roles are protected with conditional access rules which enforce that each user must use multi-factor authentication to access the environment. It extends to managing privileged roles by using Privileged Identity Management (PIM) for strong, time-bound authentication and full audit history of the actions carried out with that elevated role.  

Sam: That’s right, Gina, and they would also manage other areas like the connectivity subscription if the Azure environment connected with an on-premises environment for any reason. Or a management subscription for automation and or monitoring of the Azure environment. 

Lastly, the organisation can choose to include a specific platform team subscription for your central IT teams, which would hold things like your VM images or the action groups that are called for things like alerts. 

Then, you have the individual application landing zones, which will hold the resources needed for each workload. These are typically managed by the developer team or project teams. 

They could include resources like virtual machines, storage accounts, disaster recovery with Azure site recovery and Azure Backup and many more.  

What you will notice is that the same resources can be deployed in a platform zone subscription as well as an application zone subscription.  

For example, Defender for cloud may be deployed to the management subscription so that central IT can manage general Security recommendations. But then Defender for Cloud may be used in an application zone to use either Defender for Servers or Defender for Database features.  

This is why the approach will take slightly longer than a start small and expand approach, as the organisation needs to be aware of the needs prior to deployment. Then they need to configure it.  

But, oh boy, once that is done, it creates a beautiful synergy between your central IT and development teams to maintain your organisational governance and not hinder innovation. 

Gina: So, there we have it, folks. That’s it for another episode.  

Just to recap what we have discussed, once you know your operating model in Azure, you can look at how you will adopt Azure.  

You will select the landing zone that works best for your business objectives, based on your strategy for adopting the cloud.   

You can decide if you want to adopt quickly with a minimum viable product using start small and expand, then improve your estate over time.   

Alternatively, you can take a little bit more time at the start to make sure every aspect of the environment is configured and built before you migrate.  

And remember, the end result should be achieving an Enterprise landing zone approach so that you can take advantage of standardisation for your central IT team, while supporting innovation from your development teams.  

Next time, we are going to be looking at the migration itself and some of the key things to be aware of.   

See you next time.