Microsoft's official Azure Landing Zone reference is excellent — and overkill for almost every SMB. The right-size landing zone gives you 80% of the benefits at 20% of the complexity. Here's how to build one that scales without painting you into a corner.
What "landing zone" actually means
A landing zone is the opinionated, secure, governed foundation every workload lands in:
- Identity and access (Entra ID, RBAC, PIM).
- Network topology (hub-and-spoke or vWAN).
- Security baseline (Defender for Cloud, Key Vault, monitoring).
- Governance (Azure Policy, tagging, naming, cost).
- Operations (logging, backup, DR, patch).
Without it, every workload reinvents these — badly, inconsistently, and expensively.
SMB-tuned management group structure
Skip the deep enterprise hierarchy. For most SMBs:
Tenant Root
├── Platform
│ ├── Connectivity (networking subscription)
│ ├── Identity (Entra ID supporting infra)
│ └── Management (logs, monitoring, automation)
├── Landing Zones
│ ├── Production
│ ├── Non-production
│ └── Sandbox
└── Decommissioned
Five management groups, three subscription tiers. You can split further later; you almost never want to merge.
Networking — hub-and-spoke is still the default
Even for small estates:
- One hub VNet in the Connectivity subscription with shared services (firewall, DNS, ExpressRoute / VPN).
- One spoke VNet per workload, peered to hub.
- Azure Firewall or third-party NVA for east-west and outbound inspection.
- Private DNS zones in the hub.
- Private endpoints for PaaS — no public endpoints unless explicitly required.
For very small estates with no on-prem connectivity, a single hub VNet with subnets per workload is acceptable. Keep the option to split later.
Identity baseline
- Entra ID with Conditional Access on every admin role.
- Privileged Identity Management (PIM) for just-in-time elevation.
- Break-glass accounts (2 minimum) excluded from Conditional Access, monitored for use.
- Service principals via managed identity wherever possible — avoid long-lived secrets.
- Quarterly access review for privileged groups.
Security baseline
- Defender for Cloud at standard tier on critical subscriptions.
- Microsoft Sentinel if you have a SOC; otherwise Defender for Cloud + alert rules to your service desk.
- Key Vault per environment, with private endpoint and managed identity access.
- Azure Bastion for any RDP/SSH access — never expose 3389 / 22 directly.
- Encryption: storage with customer-managed keys for sensitive workloads, default Microsoft-managed otherwise.
Governance via Azure Policy
Start with the Azure Security Benchmark initiative built-in. Add:
- Allowed locations — restrict to your data residency requirements.
- Required tags —
costCenter,environment,owner,application. - Allowed resource types — block expensive or unsupported services in non-prod.
- Diagnostic settings — auto-enable logging on every new resource.
Deploy policies as code with Bicep / Terraform, not manually through the portal.
FinOps from day one
- Budgets per subscription with email alerts at 50% / 80% / 100%.
- Tagging policy that enables chargeback / showback.
- Cost Management exports to Storage; Power BI dashboard on top.
- Right-sizing review monthly for first 6 months, then quarterly.
- Reservations and savings plans once you have 3 months of stable usage data.
SMBs commonly over-pay 20–40% in the first year of Azure. A proper FinOps practice pays for itself.
Infrastructure as Code
Don't build a landing zone clicking in the portal. Use:
- Bicep if you're Microsoft-aligned (recommended for most).
- Terraform if you're multi-cloud or already invested.
- One repo per management scope; CI/CD via Azure DevOps or GitHub Actions.
- Separate state files per environment.
- Code review on infra changes like any other code.
Logging and monitoring
- Single Log Analytics workspace per region (in the Management subscription).
- All resource diagnostics into it via policy.
- Workbooks for the operational views you actually use.
- Alerts on the small number of things that genuinely matter — alert fatigue is real.
Backup and DR
- Recovery Services Vault per region, replicated.
- Backup policies by workload tier (RPO 1h / 4h / 24h based on business need).
- Annual DR test of at least one tier-1 workload — if it's not tested, it doesn't work.
What to skip (for now)
- Multi-region active-active until you have a real tier-0 workload that requires it.
- Custom firewall NVA unless your security team specifically requires it.
- Dedicated hosts unless licensing demands it.
- Private connectivity to every PaaS service — start with the data-bearing ones.
FAQs
How long does it take to deploy this landing zone? 4–8 weeks for an SMB landing zone done properly. Most of that time is decisions and stakeholder alignment, not technical work.
Can we adopt Azure without a landing zone first? You can. You'll regret it. Retrofitting governance and networking onto live workloads is 3–5x harder than building the foundation first.
Should we use Azure Lighthouse with our partner? Useful if your MSP needs scoped, auditable access across multiple subscriptions. Less useful for a single-tenant SMB.
What about multi-cloud? If you genuinely run AWS / GCP at scale, design with multi-cloud abstractions (Terraform, common identity, central logging). For most SMBs, optimize for one cloud first.
We deliver Azure landing zones for SMB in 6–8 weeks, including IaC, runbooks and team enablement. Request a sample architecture — we share it before any commitment.