Author: Shahzad Khan

Over the past few weeks, I went through the full process of designing and implementing a lean but enterprise-grade Azure Landing Zone for a small organization. The goal wasn’t to build a complex cloud platform — it was to create something secure, governed, and scalable, while remaining simple enough to operate with a small team.

This experience helped me balance cloud architecture discipline with practical constraints, and it clarified what really matters at this scale.

Here’s what I built, why I built it that way, and what I learned along the way.

🧭 Starting with the Foundation: Management Groups & Environment Separation

The first step was establishing a clear environment structure. Instead of allowing resources to sprawl across subscriptions, I organized everything under a Landing Zones management group:

Tenant Root
 └─ Landing Zones
     ├─ Development
     │   └─ Dev Subscription
     └─ Production
         └─ Prod Subscription

This created clear separation of environments, enforced consistent policies, and gave the platform team a single place to manage governance.

For a small org, this structure is lightweight — but future-proof.

🔐 Designing RBAC the Right Way — Without Over-Permissioning

Next came access control — usually the most fragile part of small Azure environments.

I replaced ad-hoc permissions with a clean RBAC model:

• tanolis-platform-admins → Owner at Landing Zones MG (inherited)
• Break-glass account → Direct Owner for emergencies only
• Dev users → Contributor or RG-scoped access only in Dev
• Prod users → Reader by default, scoped contributor only when justified

No direct Owner permissions on subscriptions.
No developers in Prod by default.
Everything through security groups, not user assignments.

This drastically reduced risk, while keeping administration simple.

🧯 Implementing a Real Break-Glass Model

Many organizations skip this — until they get locked out.

I created a dedicated break-glass account with:

• Direct Owner at the Landing Zones scope
• Strong MFA + secure offline credential storage
• Sign-in alerts for monitoring
• A documented recovery runbook

We tested recovery scenarios to ensure it could restore access safely and quickly.

It wasn’t about giving more power — it was about preventing operational dead-ends.

🛡️ Applying Policy Guardrails — Just Enough Governance

Instead of trying to deploy every policy possible, I applied a starter baseline:

• Required resource tags (env, owner, costCenter)
• Logging and Defender for Cloud enabled
• Key Vault protection features
• Guardrails against unsafe exposure where reasonable

The focus was risk-reduction without friction — especially important in small teams where over-governance leads to shadow IT.

🧱 Defining a Simple, Scalable Access Model for Workloads

For Dev workloads, I adopted Contributor at subscription or RG level, depending on the need.
For Prod, I enforced least privilege and scoped access.

To support this, I created a naming convention for access groups:

<org>-<env>-<workload>-rg-<role>

Examples:

• tanolis-dev-webapi-rg-contributors
• tanolis-prod-data-rg-readers

This makes group intent self-documenting and audit-friendly — which matters more as environments grow.

📘 Documenting the Platform — Turning Architecture into an Operating Model

Technology wasn’t the final deliverable — operability was.

I created lightweight but meaningful platform artifacts:

• Platform Operations Runbook
• Subscription & Environment Register
• RBAC and access governance model
• Break-glass SOP and validation checklist

The goal was simple:

The platform should be understandable, supportable, and repeatable — not just functional.

🎯 What This Experience Reinforced

This project highlighted several key lessons:

• 🟢 Small orgs don’t need complex cloud — they need clear boundaries and discipline
• 🟢 RBAC and identity design matter more than tools or services
• 🟢 A working break-glass model is not optional
• 🟢 Policies should guide, not obstruct
• 🟢 Documentation doesn’t have to be heavy — just intentional
• 🟢 Good foundations reduce future migration and security pain

A Landing Zone is not just a technical construct — it’s an operating model for the cloud.

🚀 What’s Next

With governance and identity foundations in place, the next evolution will focus on:

• Network & connectivity design (simple hub-lite or workload-isolated)
• Logging & monitoring baselines
• Cost governance and budgets
• Gradual shift toward Infrastructure-as-Code
• Backup, DR, and operational resilience

Each step can now be layered safely — because the core platform is stable.

🧩 Final Thought

This experience reinforced that even in small environments, doing cloud “the right way” is absolutely achievable.

You don’t need a massive platform team — you just need:

• good structure
• intentional governance
• and a mindset of sustainability over quick wins.

That’s what turns an Azure subscription into a true Landing Zone.