Landing Zones: What are they? and Why should I use one?

This post is the first in a series about Azure Landing Zones. We’ll start with the basics of what a landing zone is and why you should use one.

The House-Building Analogy

Imagine you’re building a house. You wouldn’t start by constructing the first room that comes to mind and then randomly adding other rooms as you think of them. Without proper planning, this approach would likely result in a structurally unsound and unsafe building. Foundations and structure are paramount to a building’s lifespan, safety, and functionality.

This concept directly applies when starting out in Microsoft Azure. While experimenting and building resources as you learn is great for individuals, adopting the same ad-hoc approach as a business can spell disaster. Proper planning is essential for a successful and sustainable cloud adoption journey.

The Importance of the Cloud Adoption Framework

Microsoft has developed the Cloud Adoption Framework (CAF) to help organisations begin their cloud journey in a planned and managed way. Azure Landing Zones are a critical component of this framework. We’ll talk much more about CAF in upcoming posts, but for now, let’s focus on landing zones.

What is a landing Zone then?

An Azure Landing Zone is an environment that adheres to key design principles to facilitate workload migration, modernization, and innovation. Technically, this involves using subscriptions to isolate and protect resources. Landing zone subscriptions typically fall into one of two categories:

• Platform Landing Zones
• Application Landing Zones

However, a landing zone is more than just a collection of resources and subscriptions. This planned structure allows you to leverage features like Management Groups for controlling access and Azure Policy for governing each landing zone or the environment as a whole. It also enables the sharing and reuse of common resources across your application landing zones.

Example Architecture

Below is an example of a management group structure from Microsoft’s Learn site. This illustrates how management groups can be organised within an Entra ID tenant and how subscriptions are nested within these groups. While this doesn’t encapsulate a landing zone entirely, it provides a great initial look at how a landing zone might be structured.

For a more detailed view, consider Microsoft’s architectural diagram of a landing zone:

As shown in the diagram, logical areas are separated, such as Management, Identity, Connectivity, and several example Application Landing Zones. The appropriate resources reside within their own subscriptions. If you were to decommission the “Landing Zone A2 Subscription,” you could do so knowing that you won’t disrupt connectivity or your identity provider.

Real-World Scenario: Launching “AI Holidays”

Suppose you want to spin up a new business unit but are unsure of its potential success. Let’s call it “AI Holidays,” a travel agency’s first venture into the world of AI. The company already has its domain controllers in the Identity subscription and connectivity to its offices via Azure ExpressRoute in the Connectivity subscription.

By utilising existing platform resources, they can deploy “AI Holidays” in its own application landing zone without impacting their already established, revenue-generating application landing zones. This approach allows the company to innovate and take risks while maintaining the integrity of its core infrastructure.

What’s next?

This introduction only scratches the surface of what Azure Landing Zones entail. In future posts, we’ll explore more in-depth aspects of this topic, including best practices, implementation strategies, and how to align landing zones with your specific needs.