Designing Azure Landing Zones for Mid-Sized Organisations: A Practical Blueprint

Meta description: A practical guide to Azure landing zone design for mid-sized organisations, covering governance, security, cost control, and real-world implementation trade-offs.

Suggested URL slug: azure-landing-zone-design-mid-sized-organisations

Introduction

Azure landing zone design is where cloud ambition meets operational reality. For most mid-sized organisations, the problem isn’t spinning up resources – it’s doing it in a way that doesn’t implode under scale, cost, or compliance pressure.

From a London IT Director’s perspective, Azure landing zones are less about Microsoft’s reference diagrams and more about answering a harder question: how do we give the business agility without losing control? This article walks through a practical landing zone approach, based on real implementations across 200–2,000 user environments, focusing on governance, security, and cost you can actually manage.

Main Section

Let’s define terms in operational language. An Azure landing zone is the opinionated structure you put in place before workloads arrive: subscriptions, management groups, policies, role-based access control (RBAC), networks, and core platform services. Done well, it becomes your cloud operating model. Done badly, it becomes a very expensive lab environment with production data in it.

I typically split landing zone design for mid-sized organisations into four core pillars:

• Tenant and subscription topology
• Identity and access guardrails
• Network and connectivity baseline
• Governance and security enforcement

1. Tenant and Subscription Topology

For most mid-sized organisations, a single Azure AD tenant is a given. The more nuanced decision is subscription structure. The common failure mode is a single subscription for everything “because we’re not that big” – which works until audits, cross-charging, or M&A arrives.

A pragmatic pattern that works repeatedly:

• Platform subscription – Core shared services: monitoring, backup vaults, Log Analytics, key management, and sometimes hub networking.
• Production subscription(s) – Line-of-business workloads. If you have very distinct business units with different P&L ownership, split by business unit.
• Non-production subscription – Dev/test/staging workloads, with looser guardrails but strict cost controls.

This structure fits neatly under a management group hierarchy such as:

• Root – Global policies (e.g. allowed regions, baseline security).
• Platform – Policies for shared services, logging, and SOC integration.
• Corp-Prod – Stricter security policies and change control.
• Corp-NonProd – More flexibility, but mandatory cost guardrails.

The key is consistency: if you create ad-hoc subscriptions every time a vendor asks for one, you lose the ability to manage Azure coherently.

2. Identity and Access Guardrails

Your Azure landing zone is only as strong as your identity and access architecture. I’ve seen environments with beautiful network diagrams completely undermined by global admin sprawl and direct subscription owner permissions.

A practical approach:

• Use Entra ID (Azure AD) as the single identity provider for Azure and Microsoft 365.
• Separate platform operations roles (e.g. cloud platform team) from workload owner roles (e.g. app teams, vendors).
• Use Azure AD Privileged Identity Management (PIM) for just-in-time elevation to Owner/Contributor, with approvals and time limits.
• Avoid assigning Owner at the subscription level for day-to-day work; prefer Contributor on well-scoped resource groups.

RBAC should align with how you operate, not just how Microsoft’s documentation is structured. If your organisation is small, three tiered roles may be enough: Platform Admins, Security/Compliance, and App Owners – but the important part is that this is designed, not emergent.

3. Network and Connectivity Baseline

Networking is where landing zones often get over-engineered. Many mid-sized organisations don’t need full hub-and-spoke with every Azure feature enabled from day one. But you do need a clear direction of travel.

A sensible starting pattern:

• Single hub virtual network in the Platform subscription.
• Spoke virtual networks per major workload domain or subscription.
• Centralised firewall or network virtual appliance if you have strict east-west inspection requirements.
• VPN/ExpressRoute connectivity to on-premises, with a defined decommission plan if you’re going cloud-first.

If most of your workloads are PaaS and SaaS, focus more on private endpoints, service tags, and clear egress patterns than on complex VNet topologies. Over-building the network has real cost and complexity impact without equivalent benefit.

4. Governance and Security Enforcement

Azure Policy is where landing zones become enforceable rather than just aspirational. For a mid-sized organisation, I usually start with three tiers of policies:

• Non-negotiable controls – e.g. restrict regions, enforce diagnostic logging to Log Analytics, require resource tagging, enforce encryption.
• Strong recommendations – e.g. deny public IPs on specific resource types in production, enforce specific SKUs for security tools.
• Advisory only (effect = audit) – used initially to measure impact before moving to deny.

Combine this with Azure Blueprints (or its successor capabilities) or deployment templates (Bicep/Terraform) so that landing zone configuration is repeatable and version-controlled, not something someone builds once in the portal and forgets.

Implementation Considerations

To ground this, consider a realistic scenario: a 600-user professional services firm with mixed on-prem and SaaS, starting to modernise a key line-of-business app into Azure. They want speed, but they’re also under ISO 27001 pressure from clients.

The implementation path I’ve used in similar cases:

• Design and create the management group hierarchy and baseline policies first, even if it slows initial deployment by a week.
• Stand up the Platform subscription with logging, key management, and a minimal hub network.
• Create separate Prod and NonProd subscriptions, both inheriting the baseline but with different policy strictness.
• Onboard identity with PIM and move existing admins out of permanent global roles.
• Deploy the first application into NonProd only after guardrails are in place.

Key pitfall: The most common failure I see is political, not technical. The business pressures you to “just get the app running” and promises you’ll “tidy up later”. Later never comes. Every subsequent project copies the messy model, and two years in you’re running a clean-up programme instead of building value.

From a governance perspective, ensure your landing zone design is signed off not only by IT but by Information Security and whoever owns regulatory compliance. This is the foundation for DLP, data residency commitments, and audit defensibility.

From a cost standpoint, don’t underestimate the ongoing spend of the shared platform components. Log Analytics, Sentinel, backup vaults, and firewalls add up. However, centralising these in a Platform subscription usually saves money versus duplicating tooling per workload, and gives you better economies of scale for security operations.

Operational Strategy

Landing zones fail when they’re treated as a one-off project. You need an operational strategy that accepts that your Azure environment in 18 months will look very different from today.

I typically recommend a three-stage approach:

• Stage 1 – Baseline
  Minimum viable landing zone: management groups, 2–3 subscriptions, core policies, PIM, logging, and basic networking. Your priority is to stop sprawl before it starts.
• Stage 2 – Standardisation
  Introduce standardised patterns for common workloads: a “web app pattern”, a “data platform pattern”, a “third-party SaaS integration pattern”, all expressed as code (Bicep/Terraform) and linked to the landing zone.
• Stage 3 – Optimisation
  Tighten policies based on observed usage, introduce more advanced controls (e.g. Defender for Cloud integration, just-in-time VM access), and refine cost management – budgets, alerts, and showback/chargeback if relevant.

Decision-wise, be clear on this: your landing zone is an operating model, not a diagram. Assign ownership. In mid-sized environments that usually means:

• A named Cloud Platform Owner (often the most senior Azure engineer or architect).
• A Security Lead who co-owns policies and logging requirements.
• A cross-functional Cloud Governance Forum that meets monthly to review exceptions, changes, and roadmap.

On rollout, resist the temptation to rebuild everything in place. Instead, treat new workloads as “landing zone native” and gradually migrate or refactor legacy workloads into the new structure. High-risk or high-value systems should move first, not last.

Final Recommendation

If you’re responsible for IT direction, the most important decision isn’t which specific Azure landing zone reference you copy – it’s to decide that your organisation will not deploy workloads into Azure without a designed landing zone.

Start small but intentional: a clear subscription model, management group hierarchy, identity guardrails, and a handful of enforced policies. Make it code, make it owned, and make every new project align to it. The next two years of your cloud journey will be shaped far more by these early structural choices than by any single technology decision.