This article will discuss the concept of Azure Landing Zones, and how Formula5’s Modular DevSecOps framework can help with their adoption and implementation. However, before we deep dive into the Modular DevSecOps framework, we believe we should review and explain some core concepts of landing zones first. Azure cloud provides acceleration for building innovative solutions. There are many benefits of utilizing the cloud:
- Cost Savings
- Disaster Recovery
- Loss Prevention
However, it is important to properly plan your Azure cloud environment so you can realize these benefits while also avoiding problems like increased cost, security threats, and lack of standardization across a portfolio of workloads. Understanding how to operate in the cloud and how to prepare for cloud environment structure is very important, especially in highly regulated industries like Financial and Insurance, Healthcare and Life Science, or Energy. This is where Microsoft Cloud Adoption Framework for Azure can help. It provides best practices, documentation, and tools that help create and implement business and technology strategies for the Azure cloud. One of the most important parts of it is the readiness to host the workloads that we plan to build in or migrate to the cloud. This is where Azure Landing Zones come to play.
Azure Landing Zone concept
Azure Landing Zone is a multi-subscription Azure cloud environment for hosting workloads, pre-provisioned through the code, that accounts for scale, security governance, networking, and identity. Azure Landing Zones enable creating consistent Azure environments utilizing configuration kept as a source code (Infrastructure as a Code approach). Here is an example of a multi-subscription Azure Landing Zone:
It is worth underlining that not all enterprises adopt Azure cloud in the same way. This is why there is no fit-them-all solution and architecture for Azure Landing Zones implementation. However, there are some core concepts that are important to understand when planning Azure Landing Zone architecture for our organization.
When looking at the above architecture, we can see many different components. First of all, it is worth noting that the single landing zone is nothing else like Azure subscription created with specific purpose and with specific constraints around it. Each subscription (landing zone) is assigned to Management Group. Management Groups provide a governance scope above subscriptions. We organize subscriptions into management groups to apply cascade governance by inheritance to all associated subscriptions. There are two types of landing zones: platform, and application.
Platform Landing Zones
Platform landing zones represent Azure subscriptions deployed to provide centralized, key services that often benefit from being consolidated for efficiency and ease of operations. Examples include identity, networking, and management services like Azure Log Analytics, Azure Automation, Azure Sentinel, ExpressRoute, VPN Gateways, or Azure Active Directory Domain Services.
Depending on the size and characteristics of the organization, we can create dedicated platform landing zones for grouping services such as those mentioned. We can also assign Azure Policies to harden and manage the resources in each landing zone (subscription) like those outlined in the image above.
Application Landing Zones
Application landing zones represent Azure subscriptions deployed specifically to host an environment for application workloads. Within these subscriptions, there can be Azure resource groups that contain Azure services like Azure Web Apps or Azure SQL databases. Application landing zones can be categorized in the following way:
- Centrally managed – a central IT team applies controls and platform tools to both the platform and application landing zones. All landing zones are operated by the central IT team.
- Technology platform – applied when utilizing Azure Kubernetes Service which is often centrally managed. Applications running on top of the service are managed by application teams.
- Workload team managed – The entire landing zone administration is delegated to a workload team to fully manage and support the environment however it is also controlled by the Azure Policies applied from the Management Groups above that the platform team control.
Azure Landing Zones relation to secure DevOps
I mentioned Azure Landing Zones configuration is kept in a source code repository. This means we can apply secure DevOps practices and automation. Platform resources are managed by a cross-functional platform team which consists of specialists responsible for:
- Management and deployment of subscriptions, management groups using the Infrastructure as a Code approach, and the respective CI/CD pipelines.
- Definition and management of Azure Policy and RBAC permissions on the platform for landing zones and platform management groups and subscriptions kept in the GIT version control.
- Definition and management of the common networking components in Azure like the hybrid connectivity with ExpressRoute, and firewall resource to control Internet-facing networking traffic.
In the case of application landing zones, a very common and popular model is to hand over their management to the DevOps teams responsible for the application workloads. They can independently operate within the security guardrails provided by the platform team. These DevOps teams manage several workload environments (like DEV, STAGE, PROD) deployed to individual landing zones/subscriptions but also plan deployments of specific components of application solutions (like the set of web APIs deployed to Azure Web Apps).
We can say that secure DevOps is the core fundamental for Azure Landing Zones.
Modular Azure Landing Zones approach with Formula5’s Modular DevSecOps
I mentioned at the beginning that not all enterprises adopt Azure cloud in the same way and at the same pace. Some organizations can be at the beginning of the cloud journey, others can be already onboarded and connected to the cloud. The huge benefit of Azure Landing Zones is the modular structure, extensibility, and scalability. At Formula5 we are aware that some of the organizations can be already migrated to the Azure cloud and utilize the concepts above. This is why in our Modular DevSecOps accelerator we focus on Secure App Zones, predefined templates for creating landing zones for different kinds of workloads. They enable teams to deploy application workloads to secure and compliant Azure cloud environments. We are also aware that there can be different architectural decisions behind each solution and different compliance requirements. This is why we do not create a single solution that fits all technical environments. We rather focus on extensible templates which can be used as the foundation for building Azure Landing Zones for application workloads.
The above templates can be stored in source code repositories in Azure DevOps or GitHub and deployed using Azure DevOps Pipelines or GitHub Actions. With such approach, we can follow an Everything as Code approach for full transparency and configuration control of the Azure platform. We utilize GIT version control to store:
- Azure Infrastructure templates as Code
- Azure Policy templates as Code
- Secure App Zones templates as Code
- Workload Deployment templates as Code
With Azure Landing Zones we can avoid problems like increased cost, security threats, or lack of standardization in our organization. Utilizing a modular approach we can reduce complexity and start with the proper configuration of Azure cloud environments at any stage of our cloud journey. Managing Azure cloud environments utilizing secure DevOps automation provides many benefits and help maintain a predictable and secure posture of workloads running in the Azure cloud.
I also encourage you to watch the video where together with Jack Tracey from Microsoft we discussed Azure Landing Zones and their relation to secure DevOps.