Edit

Share via

Deploy Azure landing zones

This article describes the options available to help you deploy both a platform landing zone and application landing zones. A platform landing zone provides centralized services that workloads use. Application landing zones are environments deployed for the workloads themselves.

Important

For more information about definitions of the platform landing zone and its connected application landing zones, see Platform landing zone versus application landing zones.

Choose a platform landing zone approach

The following platform deployment options provide an opinionated approach to deploy and operate the Azure landing zone reference architecture as described in the Cloud Adoption Framework for Azure. The resulting architecture can vary based on the customizations, so it might not be the same for all the deployment options listed in this article. The differences between the platform deployment options are based on their use of different technologies, approaches, and customizations.

Standard deployment options

Standard deployment options address typical enterprise Azure usage.

Azure platform landing zone deployment option Description Azure public clouds Azure sovereign clouds like US Government and 21Vianet
The Azure portal deployment An Azure portal-based deployment that provides a complete implementation of the Azure landing zone reference architecture and opinionated configurations for key components, including management groups and policies. Supported Not supported.

You can deploy individual resources by using the Azure portal. But this approach doesn't provide a unified, guided experience across resources.
Bicep deployment An infrastructure as code (IaC) deployment that uses Azure verified modules and provides a customizable way to deploy a platform landing zone by using Bicep. Supported Not supported.

You can use the Bicep code as a starting point to build a custom implementation that follows Azure platform landing zone best practices. For more information about what customizations the code requires, see the Azure sovereign cloud deployments section.
Terraform deployment An IaC deployment that uses Azure verified modules and provides a customizable way to deploy a platform landing zone by using Terraform. Supported Not supported.

You can use the Terraform code as a starting point to build a custom implementation that follows Azure platform landing zone best practices. For more information about what customizations the code requires, see the Azure sovereign cloud deployments section.

You can also review the implementation options for Azure landing zones to help you choose the best deployment option for your organization.

Azure sovereign cloud deployments

The Azure portal, Bicep, and Terraform deployment options are supported for Azure public, global, and commercial cloud offerings. If you need to deploy into other Azure clouds, like Azure Infrastructure Services for US Government Clouds or Azure operated by 21Vianet, your platform team needs to make manual configuration changes to the deployment assets. Only the Bicep and Terraform deployment options can be modified to accommodate these changes. Consider the following cloud-specific limitations and configuration requirements:

  • Azure Policy definitions, initiatives, and assignments: Not all Azure policies are available across all clouds, so you need to remove unsupported policies before deployment.

  • API versions for some resources: Specific API versions might not exist in some clouds, so you need to adjust resource API versions before deployment.

  • Resource availability: Some resources might not exist in some clouds. For example, Azure DDoS Protection plans aren't available in Azure in China. You need to remove these resources before deployment.

The Azure landing zone architecture is valid and supported in all Azure clouds. But the deployment for that architecture isn't provided in an automated solution that works across all clouds. If you want automated deployment support for these clouds, request the feature.

Variants and specializations

The standard platform deployment options meet the requirements of most organizations across all industries and sizes. For other scenarios, see the following tailored architectures and deployment options to help you deploy your platform landing zone quickly.

The following options provide specialized platform landing zone implementations that you can use instead of the standard deployment options.

Platform landing zone variant Description
Sovereign landing zone The sovereign landing zone is a specialized implementation of the Azure landing zone reference architecture designed specifically for organizations that have stringent regulatory, compliance, and data residency requirements that focus on sovereignty. It includes tailored configurations and policies to help meet these needs while still adhering to the core design principles and design areas of Azure landing zones.

Partner implementations

Partner programs like Azure Accelerate can help you design and implement a platform landing zone that meets your organization's needs. Those implementations start with the Azure landing zone reference architecture and design configurations that are specific to your cloud adoption strategy, organizational topology, and goals.

Enterprise policy as code for policy management

Enterprise policy as code (EPAC) is an alternative method to deploy, manage, and operate Azure Policy across your organization's Azure estate. You can use EPAC instead of the standard platform options to manage the policies in an Azure landing zone environment. For more information about the integration approach, see Integrate EPAC with Azure landing zones.

EPAC is best suited for more advanced development operations (DevOps) and IaC customers, but organizations of any scale can use EPAC after they assess it. For more information, see Who should use EPAC?

Note

Compare the life cycle and flexibility of the two approaches before you decide on what approach to use long term. Begin by evaluating the native policy management in the default implementation. If that implementation doesn't meet your governance needs, then do a minimum viable product (MVP) or proof of concept by using EPAC. Compare options, validate your findings, and confirm your choice before you implement an approach because you can't easily change policy governance methods after you establish them.

Operate Azure landing zones

After you deploy the platform landing zone, you need to operate and maintain it. For more information, see Keep your Azure landing zone up to date.

Azure governance visualizer

Azure governance visualizer can help you get a holistic overview of your technical Azure governance implementation by contextualizing data and providing sophisticated reports.

Subscription vending

After you create your platform landing zone and governance strategy, establish a consistent approach to how you create and operationalize subscriptions for workload owners. Subscription democratization is an Azure landing zone design principle that uses subscriptions as units of management and scale. This approach accelerates application migrations and new application development.

Subscription vending standardizes the process that platform teams use for workload teams to request subscriptions and platform teams to deploy and govern those subscriptions. It lets application teams use Azure in a consistent and governed way, which helps ensure that teams meet all requirements.

Organizations often have different styles of subscriptions that can be vended into their tenant, commonly called product lines. For more information, see Establish common subscription vending product lines.

To get started, follow the subscription vending implementation guidance. Then review the following IaC modules, which provide flexibility to fit your implementation needs.

Deployment option Description
Bicep subscription vending The subscription vending Bicep modules orchestrate the deployment of an individual application landing zone.
Terraform subscription vending This approach uses Terraform to orchestrate the deployment of an individual application landing zone.

You can use all deployment options to manually deploy an application landing zone, but they're most effective as part of an automated process.

Application landing zone architectures

Application landing zones are designated areas within one or more subscriptions, specifically set up as approved destinations for resources that application teams manage for a specific workload. A workload can take advantage of services in the platform landing zone or remain isolated from those centralized resources. Use application landing zones for centrally managed applications, decentralized workloads that application teams own, and centrally managed hosting platforms like Azure Kubernetes Service (AKS) that can host applications for multiple business units. Unless unusual circumstances constrain application landing zone subscriptions, they typically include resources from only a single workload or logical application boundary, like its life cycle or criticality classification.

Workload teams communicate their workload's requirements through a formal process that the platform team establishes. The platform team generally deploys an empty subscription that's enrolled with all required governance. Then a workload architect designs a solution that works within the constraints of that application landing zone and takes advantage of shared platform features, like firewalls and cross-premises routing, when practical.

An architect can adapt a reference architecture that isn't designed specifically for an application landing zone. But Microsoft Learn also has application and data platform guidance for workload teams that specifically addresses application landing zone contexts. Make the platform teams aware of this guidance so that they can anticipate the workload types and characteristics in the organization.

Application landing zone architecture Description
App Service Environment Proven recommendations and considerations across both multitenant and App Service Environment use cases with a reference implementation.
Azure API Management Proven recommendations and considerations for how to deploy an internal API Management instance as part of a reference implementation. The scenario uses Azure Application Gateway to help provide secure ingress control and uses Azure Functions as the back end.
Azure Arc for hybrid and multicloud scenarios Guidance for servers, Kubernetes, and Azure SQL Managed Instance enabled by Azure Arc.
Azure Container Apps Guidance that outlines the strategic design path and defines the target technical state for deploying Container Apps. A dedicated workload team owns and operates this platform.
Azure Data Factory Guidance about how to host a medallion lakehouse within an application landing zone.
Microsoft Foundry chat workload Guidance about how to integrate a typical Foundry chat architecture within an application landing zone while using centralized platform landing zone resources for shared services, governance, and cost efficiency. It provides guidance for workload teams about infrastructure and agent deployment and management.
AKS Guidance and related IaC templates that represent the strategic design path and target technical state for an AKS deployment that runs within an application landing zone.
Azure Red Hat OpenShift An open-source collection of Terraform templates that represent an optimal Azure Red Hat OpenShift deployment that includes Azure and Red Hat resources.
Azure Virtual Desktop Azure Resource Manager, Bicep, and Terraform templates to reference when you design Azure Virtual Desktop deployments. These templates include the creation of host pools, networking, storage, and monitoring.
Azure Virtual Machines An architecture that extends the guidance from the Virtual Machines baseline architecture to an application landing zone. It provides guidance about subscription setup, patch compliance, and other organizational governance concerns.
Azure VMware Solution ARM templates, Bicep templates, and Terraform templates that you can use to help design Azure VMware Solution deployments. These deployments include Azure VMware Solution private cloud, jump box, networking, and monitoring.
Citrix on Azure Design guidelines for the Cloud Adoption Framework for Citrix Cloud in an Azure enterprise-scale landing zone that includes many design areas.
Red Hat Enterprise Linux (RHEL) on Azure An open-source collection of architectural guidance and reference implementation recommendations that you can use to design RHEL-based workloads on Azure.
High performance compute (HPC) workloads An end-to-end HPC cluster solution in Azure that uses tools like Terraform, Ansible, and Packer. It addresses Azure landing zone best practices, which include identity implementation, jump box access, and autoscaling.
Mission-critical workloads Addresses how to design a mission-critical workload to run within an application landing zone.
SAP workloads Provides guidance and recommendations for SAP workloads that align with Azure landing zone best practices. Provides recommendations for how to create infrastructure components like compute, networking, storage, monitoring, and SAP system builds.

Workloads often consist of different technologies and classifications. Review related reference materials for all technologies in your workload. For example, the guidance from Azure OpenAI chat and API Management helps you check whether your generative AI scenario benefits from an API gateway.

  • Last updated on