Azure Landing Zones: Enterprise-Scale Implementation Guide

Azure Landing Zones are the foundation of any enterprise Azure deployment. They provide a standardised, scalable, and secure environment for hosting workloads. But getting started can be overwhelming given the breadth of decisions involved. This guide cuts through the complexity to help you understand what really matters.

What is an Azure Landing Zone?

An Azure Landing Zone is the output of a multi-subscription Azure environment that addresses the core pillars of enterprise cloud adoption. It encompasses identity and access management, governance (including policies, compliance, and cost management), networking (connectivity, segmentation, and security), baseline security controls and monitoring, and operational management including business continuity.

Think of it as the "platform" that your application teams build on top of, providing guardrails and shared services while enabling developer productivity.

Why Landing Zones Matter

We've seen organisations struggle with Azure adoption when they skip the landing zone phase. Without proper foundations, teams make inconsistent security decisions, leading to an uneven security posture across the organisation. Network architectures become chaotic, overlapping IP ranges, multiple hub networks, and persistent connectivity issues become the norm. Without governance, resource sprawl leads to unexpected costs, and when audit time comes, organisations find themselves unable to demonstrate the controls they need for compliance.

Azure Landing Zone Accelerator

Microsoft provides the Azure Landing Zone Accelerator (formerly Enterprise-Scale) as a reference implementation. It's a great starting point, but you'll need to customise it for your organisation.

What You Get Out of the Box

The accelerator provides a management group hierarchy, Azure Policy assignments for governance, hub-spoke network topology, centralised logging with Log Analytics, options for Azure Firewall or third-party NVA deployment, and identity integration with Entra ID. These components form a solid foundation that you can extend based on your specific requirements.

Deployment Options

You can deploy via the portal experience for quick evaluation, but we strongly recommend the infrastructure-as-code approach using Bicep or Terraform modules for any production deployment. IaC provides version control, testing capability, and repeatability that manual deployments simply cannot match.

Key Design Decisions

1. Management Group Structure

Your management group hierarchy determines how policies are applied. A typical structure places your organisation under the tenant root, with Platform (containing Identity, Management, and Connectivity), Landing Zones (split into Production and Non-Production), Sandbox, and Decommissioned as the main branches.

Our recommendation: Keep it simple. More management groups mean more complexity. Start with the standard structure and only add branches if you have genuine policy differentiation needs.

2. Networking Topology

The two main options are hub-spoke (a traditional model with a central hub VNet and spoke VNets peered to it) and Virtual WAN (a Microsoft-managed hub for simpler connectivity at scale). For most organisations, we recommend hub-spoke. Virtual WAN excels for very large deployments or complex global routing scenarios, but it adds cost and complexity that many organisations don't need.

3. Identity

Identity decisions shape your entire security model. You'll need to decide between an Entra ID-only approach or a hybrid model with on-premises Active Directory. Consider how you'll configure Privileged Identity Management (PIM), establish emergency access accounts, and whether to use service principals or managed identities for automation. Managed identities are generally preferred where possible, as they eliminate the need to manage credentials.

4. Governance Policies

Start with Microsoft's recommended policies, then customise based on your requirements. Common policies include restrictions on allowed locations, approved VM SKUs, required tagging standards, automatic deployment of diagnostic settings, and security baseline enforcement. The key is to start with sensible defaults and refine based on feedback from your application teams.

Common Pitfalls

Over-Engineering

The landing zone accelerator includes options for every scenario. You don't need all of them. Start with what you need today and evolve. We've seen organisations spend months designing the perfect landing zone, only to find their requirements change once they start deploying real workloads.

Forgetting the Application Teams

A landing zone is only successful if application teams can use it effectively. Include them in design decisions and focus on developer experience. If your platform is too restrictive or difficult to use, teams will find workarounds that undermine your security goals.

One-Size-Fits-All Policies

Production workloads need different policies than development environments. Don't apply the same restrictions everywhere. A sandbox subscription should allow experimentation, while production should enforce strict controls.

Ignoring Day 2 Operations

Design for operations from day one. Consider how you'll onboard new subscriptions, handle policy exceptions, update landing zone components, and monitor and alert on issues. The initial deployment is just the beginning, you'll spend far more time operating the platform than building it.

Implementation Approach

We recommend a phased approach that delivers value incrementally while managing risk.

Phase 1 (Foundation, 2-4 weeks) focuses on establishing the management group structure, core governance policies, basic hub network, and centralised logging. This gives you the skeleton on which everything else builds.

Phase 2 (Connectivity, 2-3 weeks) adds on-premises connectivity if needed, DNS configuration, firewall rules, and private DNS zones. This enables your workloads to communicate securely.

Phase 3 (Workload Landing Zones, 1-2 weeks per zone) creates your production and non-production subscriptions with workload-specific policies. This is where application teams can start deploying.

Phase 4 (Enablement, Ongoing) focuses on developer documentation, self-service subscription vending, and training and support. This is what transforms your landing zone from infrastructure into a true platform.

Next Steps

Ready to build your Azure Landing Zone? We can help you design a landing zone architecture tailored to your requirements, implement it using Terraform or Bicep, establish governance and security baselines, and train your teams on operating the platform. Get in touch to discuss your cloud platform strategy.