Design Principles
A small set of principles is worth more than a large catalogue of rules. These principles are the thing every later decision in the series is measured against, so the platform stays coherent as it grows and as more people deploy into it.
Purpose
This page translates Microsoft’s Azure Landing Zone design principles into practical architecture rules for a small-to-medium organization. They guide the later decisions on resource organization, subscriptions, identity, networking, governance, monitoring, and automation.
Design Reasoning
Microsoft describes the Azure Landing Zone design principles as aspirational. They are not meant to force every organization into an identical architecture; they provide direction for a platform that stays scalable and manageable as it grows. The practical principles used throughout this series:
- Policy-driven governance. Encode standards as Azure Policy so they are enforced continuously, not checked manually at review time.
- Subscription democratization through controlled vending. Teams get subscriptions quickly, but through a repeatable, governed process — not ad-hoc portal clicks.
- Centralized platform operations. Identity, connectivity, logging, and governance are operated once, centrally, and inherited by every workload.
- Workload autonomy within guardrails. Application teams move fast inside their landing zone; the guardrails keep them from stepping outside the intended design.
- Security by default. The secure path is the default path — public exposure, broad access, and unmanaged secrets require a deliberate decision.
- Automation by default. The platform is deployed and changed through code, so changes are reviewable, repeatable, and auditable.
- Design for scale. Choices are made so that the tenth and hundredth subscription look like the first, without re-architecting.
- Clear separation of platform and workload responsibilities. Everyone knows which decisions belong to the platform team and which belong to the workload team.
The payoff is fewer manual exceptions, fewer snowflake environments, better auditability, and a cleaner operating model.
Principle in one sentence
Make the secure, governed, observable path the easy path — then most teams will take it without being told to.
Architecture Decision Record
| Decision | Choice | Rationale |
|---|---|---|
| Governance model | Policy-first, not ticket-first | Azure Policy enforces standards continuously and at scale; ticket-based review does not. |
| Deviation handling | Deviations allowed, but documented | The reference architecture is opinionated; deviating is valid when the tradeoff is understood and recorded as a decision. |
Tradeoff: Policy-driven governance requires up-front investment in policy authoring and a lifecycle to operate it. The alternative — manual review — is cheaper to start and far more expensive to run as the estate grows.
Recommended Configuration
The clearest way to apply these principles is to recognize the poor choices they steer you away from, and the better choices they steer you toward.
| Area | Poor choice | Better choice |
|---|---|---|
| Governance | Manual portal configuration | Initiatives with an assignment, exemption, and remediation process |
| Access | Assign Contributor or Owner directly to users | Assign least-privilege roles to security groups, elevate through PIM |
| Environments | Dev, test, and prod in one subscription | Split by ownership, environment, or isolation requirement |
| Networking | Deploy private endpoints without a DNS plan | Design private DNS zones and resolver behavior first |
| Operations | Each team builds its own unrelated logging | Start with one central workspace; split only for clear reasons |
| Change | Manual portal changes for platform config | Deploy and change the platform through Infrastructure as Code |
| Exceptions | Undocumented, permanent exceptions | Track exceptions with an owner and an expiry date |
Example Implementation
Principles are only useful if they survive contact with a real decision. Run each significant decision through this test:
- Can this decision be automated?
- Does it create a guardrail instead of a manual exception?
- Does it increase workload autonomy without losing platform visibility?
- Can it be expressed through Azure Policy, Azure RBAC, or Infrastructure as Code?
- Does it reduce operational ambiguity about who owns what?
If the answer to most of these is no, the decision is probably too manual or too ad hoc, and it will become technical debt.
Validation Steps
- Pick three recent platform decisions and run each through the five questions above. If they fail, redesign them before they harden.
- Confirm that at least one principle is enforced (an Azure Policy assignment, an RBAC group model, or an IaC pipeline) rather than only written down.
- Confirm that every documented deviation from the reference architecture has a recorded reason.
Common Mistakes
- Over-focusing on the management group tree while ignoring the actual platform capabilities (identity, networking, logging, governance). The tree is a means, not the goal.
- Reading “policy-driven governance” as “deny everything on day one.” A mature policy lifecycle starts with visibility, then tightens to enforcement once the impact is understood.
- Treating the principles as aspirational only. If nothing is enforced, they are decoration.