What is an Azure Landing Zone?

Recently I’ve been involved in a few client projects that are making use of Azure Landing Zones for their platform and application deployments. Landing zones are an interesting concept and so, in this blog post, let’s cover the basics.

What is an Azure Landing Zone?

I think there are a couple of different ways to frame the concept of a landing zone.

From a cloud adoption framework you can think of landing zones as the technical end-game. They represent the prescribed architecture that considers the people/process/technology guidance (as best as it can) laid out within the cloud adoption frameworks. Where required, assumptions are made about how the organization will want to interact with cloud resources, and those assumptions are baked into the deliverables.

The other way to frame landing zones is that they provide building blocks for organizations to use while adopting the cloud. The building blocks take into account Azure/product limitations along with a host of “best practices” as it relates to scaling, security, governance, networking, and identity. Organizations adopting the cloud can choose to use some or all of the prescribed components to build out their environment.

What is in the box?

I think it’s important to look at the design principles that went into creating the Azure Landing Zones.

Subscription Democratization

With this design principle, Azure Landing Zones utilize subscriptions as both a unit of scale and a as a unit of management. The idea is that centralized platform teams can create/govern core parts of a subscription (think networking, identity, governance via Azure Policy) but ultimately the management of a subscription belongs to the workload or business unit teams for which the subscription was created.

There are reasons why organizations would not find this a suitable approach to building out the cloud. One of the main reasons here is that it pushes various aspects of management (of cloud infrastructure) to teams that might not be well equipped to manage at that level. I would say that it takes more of a “DevOps approach” to cloud management rather than a “platform engineering” approach. Those teams are heavily overloaded, so, another way to think about it is that it forces the developers of an application to manage the infrastructure as well, rather than having a centralized team of cloud infra experts that work with development teams to create appropriate infra. Scaling, for example, is a far more nuanced topic than simply adding or removing subscriptions.

Policy-Driven Governance

In a policy-driven governance approach, cloud ops teams will make use of Azure Policy (and apply said policy) on top of democratized subscriptions. The idea is that the policy controls provide the guardrails by which Azure services can be used in the given context. Some of the Azure policies are easy enough to think about, such as ones that restrict the type of services that can be deployed and others that restrict the locations where services can be deployed.

There is a lot more to Azure policy than that, however. While Azure does release policy guidance (some which adhere to various security frameworks) that guidance is generic and requires tuning. This tuning goes beyond the traditional “exception” management. Many frameworks do not cover all services that Azure has, cannot deal with certain security controls, and do not reflect any corporate standards.

The key point here is that adopting Azure Landing Zones requires corporations to have proactive (rather than reactive) policy governance teams that are constantly evolving / testing the policy code to ensure compliance.

Simplified Management

The idea here is that the landing zones take into account best-practice patterns for usage of both infrastructure-as-a-service and platform-as-a-service tooling. This ensures that you are not restricted, at least initially, to service choice.

Application-Centric Service Model

The policy/governance tooling provided within the base landing zone configuration are designed to provide a set of services at the “application” level, not at the infrastructure component level. What this basically means is that you need to think about resources in terms of the application lifecycle. You’ll move away, for example, from deploying a centralized SQL server that hosts many application databases to creating application specific SQL servers. While this tradeoff may increase work for traditional infra teams (such as your DBAs) it’ll decrease work at the Azure policy/governance/management level.

Align with Azure-native design and roadmaps

Azure landing zones, obviously, make use of Azure-native services when addressing scale, security, governance, etc. When adopting Azure Landing Zones, you need to think about Azure services managing Azure, and then, from a corporate level, integrating reporting with other centralized systems.

Conclusion

I’ve never been a fan of generic advice as I feel like the whole role of architecture is to ensure that a solution is fit-for-purpose for a client environment and context. That being said, Azure Landing Zones seems like a great place to start for most organizations. I like that the landing zones are not just paper based, but there are ARM/BICEP/Terraform artifacts to deploy required components along with a CI/CD framework that seems easy enough to use. I’m hoping over the next few blog posts to dive into key areas within the Azure Landing Zone framework and discuss some possible architectural alternatives.