Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
An Azure landing zone is the standardized and recommended approach for all organizations utilizing Azure. It provides a consistent way to set up and manage your Azure environment at scale. It ensures consistency across your organization by aligning with key requirements for security, compliance, and operational efficiency through platform and application landing zones. They provide a well-architected foundation aligned with core design principles across eight design areas.
Azure landing zone architecture
An Azure landing zone architecture is scalable and modular to meet various deployment needs. The repeatable infrastructure allows you to apply configurations and controls to every subscription consistently. Modules make it easy to deploy and modify specific Azure landing zone architecture components as your requirements evolve.
The Azure landing zone conceptual architecture (see figure 1) represents an opinionated target architecture for your Azure landing zone. You should use this conceptual architecture as a starting point and tailor the architecture to meet your needs.
Figure 1: Azure landing zone conceptual architecture. Download a Visio file or PDF file of this architecture.
Design areas: The conceptual architecture illustrates the relationships between its eight design areas. These design areas are Azure billing and Microsoft Entra tenant, identity and access management, management group and subscription organization, network topology and connectivity, security, management, governance, and platform automation and DevOps. For more information on the design areas, see the Azure Landing Zone environment design areas.
Resource organization: The conceptual architecture shows a sample management group hierarchy. It organizes subscriptions (yellow boxes) by management group. The subscriptions under the "Platform" management group host shared services that comprise the platform landing zone. The subscriptions under the "Landing zone" management group represent the application landing zones. The conceptual architecture shows five subscriptions in detail. You can see the resources in each subscription and the policies applied.
Platform landing zone vs. application landing zones
An Azure landing zone consists of one platform landing zone and one or more application landing zones. It's worth explaining the function of both in more detail.
Platform landing zone: A platform landing zone provides shared services (identity, connectivity, management) to applications in application landing zones. Consolidating these shared services often improves operational efficiency. One or more central teams manage the services in the platform landing zone. In the conceptual architecture (see figure 1), the "Identity subscription," "Management subscription," and "Connectivity subscription" are components of the platform landing zone. The conceptual architecture depicts representative resources and policies applied to the subscriptions that host the platform landing zone shared services.
Application landing zone: An application landing zone contains the resources for hosting a single workload/application. A workload should have an application landing zone for each environment (development, testing, or production). Each application landing zone consists of one or more subscriptions, as needed to accommodate scaling and service limits. You pre-provision application landing zone subscriptions through code, while a workload team is responsible for deploying workload components into their application landing zone. Application landing zones are nested under appropriate management groups, such as "Online" or "Corp," to inherit Azure Policy definitions from the parent management group(s). This structure ensures that workload subscriptions are deployed in a controlled and consistent manner, while still allowing flexibility for individual workload needs. In the conceptual architecture (see figure 1), the "Landing zone A2 subscription", for example, is an application landing zone. The architecture depicts representative resources and policies applied to the "Landing zone A2 subscription".
Figure 2: Azure landing zone conceptual architecture with Application Landing Zones & Platform Landing Zone overlaid. Download a Visio file or PDF file of this architecture.
There are three main approaches to managing application landing zones. You should use one of the following management approaches depending on your needs:
- Central team approach
- Application team approach
- Shared team approach
| Application landing zone management approach | Description |
|---|---|
| Central team management | A central IT team fully operates the landing zone. The team applies controls and platform tools to the platform and application landing zones. |
| Application team management | A platform administration team delegates the entire application landing zone to an application team. The application team manages and supports the environment. The management group policies ensure that the platform team still governs the application landing zone. You can add other policies at the subscription scope and use alternative tooling for deploying, securing, or monitoring application landing zones. |
| Shared management | With technology platforms such as AKS or AVS, a central IT team manages the underlying service. The application teams are responsible for the applications running on top of the technology platforms. You need to use different controls or access permissions for this model. These controls and permissions differ from the ones you use to manage application landing zones centrally. |
Application landing zone accelerators
Application landing zone accelerators help you deploy common workloads in your application landing zone subscriptions. Use the list of available application landing zone accelerators in the Azure Architecture Center and deploy the accelerator that matches your scenario. Make sure you have reviewed and completed the prerequisites before deploying workloads into application landing zones.
AI in Azure landing zones
A common question is whether you need a dedicated AI landing zone alongside your Azure landing zone. The answer is that you don't need a separate AI landing zone. Instead, you use the existing Azure landing zone architecture to deploy AI workloads into application landing zones. The Azure landing zone design areas and principles are sufficient to support AI workloads, as they provide the necessary foundation for governance, security, and management for applications and workloads that both include AI and non-AI components and services.
You can integrate AI services into your application landing zones without needing a separate AI landing zone. The Azure landing zone architecture, design principles, and design areas, such as identity and access management, network topology and connectivity, security, and governance, are already designed to accommodate all workloads, including those that involve AI.
From the perspective of Azure landing zones, AI is just another workload or service that can be deployed, governed, and secured within one or more application landing zone subscriptions, just like any other application, workload, or service, by the platform team by utilizing the existing Azure landing zone architecture, principles, and design areas.
For more information on AI adoption in Azure, see the AI adoption scenario. For specific focus on AI workloads and landing zones, see Establish an AI foundation.
Azure verified modules for your platform landing zone
For infrastructure as code (IaC) deployments, you can use Azure verified modules your platform landing zone. Available for both Bicep and Terraform, these modules provide a set of reusable, customizable, and extensible modules that help you deploy a platform landing zone. The modules are designed to help you accelerate the delivery of the recommended resource hierarchy and governance model. You can integrate shared services, network connectivity, and application workloads into your deployment or manage them independently.
If you want to use Bicep or Terraform, see Bicep and Terraform deployment options.
Azure platform landing zone portal accelerator
This accelerator is a ready-made deployment experience. The Azure landing zone portal accelerator deploys the conceptual architecture (see figure 1) and applies predetermined configurations to key components such as management groups and policies. It suits organizations whose conceptual architecture aligns with the planned operating model and resource structure.
If you plan to manage your environment with the Azure portal, use the Azure platform landing zone portal accelerator. Deploying the Azure landing zone portal accelerator requires permissions to create resources at the tenant (/) scope. To grant these permissions, follow the guidance in Tenant deployments with ARM templates: Required access.
Video explaining Azure landing zones and their implementation principles
Next steps
An Azure landing zone is an environment that adheres to crucial design principles across eight design areas. You should familiarize yourself with these design principles to tailor them to your needs.
You can also review the Frequently Asked Questions (FAQ) to learn more about Azure landing zones and answer common questions such as, "Do I need an AI landing zone?" or "What is the difference between an Azure landing zone and an enterprise-scale landing zone?".