Design Principles for Azure Landing Zones

The purpose of this article is to provide a very broad overview over the essential elements required for architecting, designing and deploying a Microsoft Azure landing zone, covering fundamental architecture patterns and design principles.  It is intended for Azure architects, engineers, developers, and systems administrators that will be designing, building and supporting Azure environments.

As a design principle, when it comes to subscriptions and network architecture, we approach things with a “less is more” mantra. This means trying to keep the number of subscriptions and virtual networks as low as possible without compromising on requirements related to administration, cost management or different policies and security standards.  The diagram below is an example of such a minimalist approach that can be used as a starting point to discuss and develop an Azure resource governance structure. 
 
One important thing to consider is that Management Groups and Subscriptions and Resource Groups are a mechanism for enforcing governance and managing resources. Therefore, the structure and the complexity of the design should be driven by the future structure of the operational teams that will manage the landing zones.  The design should take into consideration the various needs related to resources cost management and other requirements for administrative and management policies or compliance with standards. 

When it comes to design patterns for a landing zone, the hub and spoke model is the starting point for Azure networking architecture and is by far the widest adopted model across our clients. While the actual separation of infrastructure workloads between the hub and virtual networks spokes varies from client to client, in general the hub virtual network would contain the majority of common and shared infrastructure services. And the spokes would contain specialized workloads based on one or several criteria, usually a combination of the following:  internal versus external facing applications, production versus non production environments, geographical mapping of on-premises datacenters to Azure regions.  The hub and spoke model offers an easy transition from legacy on-premises architectures because it is still based on the classic networking separation approach. Workloads are segregated based on subnets and routing domains but at the same time allows for modern implementation of zero-trust architectures and easy, progressive integration with cloud native Azure PaaS services. 

The definition of the network layout of the landing zones is an iterative process, starting by understanding the:
• Resource governance model (the structure of management groups and subscriptions, policy requirements for the various groups of applications and infrastructure), 
• Definition of the hub-and-spoke virtual networks skeleton, 
• Selection of the Azure regions considering proximity to on-premises datacenters and data residency requirements, 
• Functional aspects and requirements of workload separation, 
• Network communication requirements between the various spokes and the hub,
• Allocation of IP ranges and integration points between the on-prem networks and Azure landing zones, 
• East-west and north-south security filtering requirements and defining a consistent naming and tagging convention. 

All of these are critical steps for a sound design and require significant thought and effort. However, once all the details have been agreed upon and validated, the deployment of the landing zone and all its composing elements (virtual networks, peering, subnets, UDRs, VPN gateways and express routes) is very straightforward as all of the above elements can be defined and deployed through code. When it comes to the flavor of infrastructure as code (IaC), the tools of choice greatly depend on the existing capabilities and preferences of the client, which can range from basic CLI scripting or ARM JSONs or Bicep to full CI/CD pipelines configured on Azure DevOps, Terraform or Ansible. 

One of the areas of top interest and concern is the security of resources and workloads deployed in the landing zone. From a security standpoint, the Azure cloud allows for an extremely granular, resource level network segmentation and security filtering. This moves the focus from the traditional approach of protecting network zones to the individual protection of each resource. This removes the constraint of having to isolate workloads in multiple virtual networks, allowing for a much cleaner, flatter network structure with fewer virtual networks, and less inter-vnet egress traffic. At the same time, it allows the implementation of a true zero-trust security model. Although from a purely theoretical perspective one could deploy the entirety of its resources and workloads in a single virtual network and still achieve a fully, zero-trust environment, we find a lean hub-and-spoke model as being the more pragmatic choice. 

Learn more about building a sound Azure landing zone foundation here.