Enterprise-scale landing zone diagrams intimidate mid-market teams into either doing nothing or clicking VMs into a single unstructured subscription. Both fail. This post is the minimum landing zone we implement when the customer is serious about Azure but does not need a 40-page CAF novella on day one.
Minimum viable structure
- Management group hierarchy light: Platform / Landing zones / Sandbox
- Subscriptions split: identity/connectivity, production, non-prod
- Identity: Azure AD, hybrid connect health, privileged roles limited
- Network: hub with firewall or secure hub pattern appropriate to size; spokes for apps
- Policy: allowed locations, no public IP on sensitive subnets, required tags
- Diagnostics: activity logs and activity to Log Analytics
- Cost: budgets and tag policy for owner/cost center
What we skip initially
- Every archetype in the reference implementation
- Multi-region active-active everything
- Custom policy as code factories before basic Bicep modules exist
Add complexity when a second product team arrives — not before.
Platform team of few
Mid-market platform is often two people. Design for that: automation over ceremony, documented break-glass, weekly cost review. If the design requires a twelve-person cloud center of excellence, it will not run.
Application landing
App teams get a spoke subscription or RG with a checklist: private endpoints where needed, managed identities, no secrets in code, diagnostics on. Platform provides rails; apps provide workloads.
Hub network patterns that fit smaller teams
A single hub with firewall (or secure hub) and spokes for prod/non-prod is enough for many mid-market estates. Avoid designing global transit for a company with two regions and one product. Complexity must match blast radius.
Policy as guardrails
Start with: allowed regions, require tags (owner, env, cost center), deny public IP on private subnets, enforce HTTPS on storage where applicable. Expand policy only when an incident proves the need. Policy sprawl recreates GPO hell in cloud form.
Identity for Azure RBAC
Use groups for role assignments, not named users. Separate platform engineers from app contributors. Review Owner assignments monthly. Owner on the subscription is not a convenience; it is a risk acceptance.
Sandbox rules
Sandboxes exist so innovation does not hit production. Budget caps, auto-shutdown for dev VMs, and a quarterly wipe policy keep sandboxes from becoming shadow production.
Platform backlog example
| Quarter focus | Deliverable |
|---|---|
| Q1 | MG + subscription structure, basic policy, logging |
| Q2 | Hub-spoke network, private endpoints pattern |
| Q3 | Bicep modules for common app landing |
| Q4 | Cost chargeback report and ownership attestation |
Scenario walkthrough
Consider a mid-size organization with hybrid identity, mixed desktop delivery, and a mandate to reduce risk without stopping the business. Week one is inventory and sponsor alignment. Week two is a written target state with two options and explicit out-of-scope items. Weeks three and four are pilot build and measurement. Only then does broad change begin. Compressing that sequence into a single weekend is how outages are born.
Along the way, three conversations dominate: who owns identity decisions, who pays for platform capacity, and what residual risk leadership accepts in writing. When those conversations are avoided, engineers improvise under pressure and the organization inherits accidental architecture.
We keep a living risk register with severity, mitigation, residual risk, and owner. The register is reviewed in the same meeting as the delivery burn-down. Risks that never move owners are the ones that become incidents.
If you're facing this
If Azure growth is ad hoc VMs and surprise bills, implement a thin landing zone before the next product lands. We build pragmatic Azure foundations for mid-market and enterprise — bring subscription chaos screenshots and who currently has Owner.