Azure Landing Zone Consulting

The eight design areas

Microsoft's Cloud Adoption Framework breaks a landing zone into eight design areas. Each has decisions that are cheap to make early and expensive to change later:

• Azure billing and Microsoft Entra tenant
• Identity and access management
• Resource organization
• Network topology and connectivity
• Security
• Management
• Governance
• Platform automation and DevOps

We work through each area with your team and record the decisions and the reasons behind them, so the design survives staff changes and future audits.

Greenfield or brownfield

A greenfield landing zone starts clean, which makes it the easiest case. Most organizations aren't there. They have subscriptions created project by project, networks that grew organically and permissions nobody wants to touch.

For brownfield environments we don't start over. We deploy the target management group structure and policies alongside what exists, use policy in audit mode to measure the gap, then move subscriptions and fix findings in order of risk, without taking running workloads offline.

Landing zones for BC public sector and regulated organizations

Regulated organizations need the landing zone to prove compliance, not just support it. We restrict resource locations to Canada Central and Canada East with Azure Policy, set log retention to match your records obligations, and use Microsoft Defender for Cloud's regulatory compliance dashboard to track controls against standards such as CIS and NIST.

Azure also includes a built-in policy initiative for the Canadian federal Protected B profile, which many BC and Canadian public sector organizations use as a reference baseline. We document how the landing zone supports your privacy impact assessment under FIPPA, so the design and the paperwork stay in step.

Keeping it maintainable

A landing zone is a product, not a project. We deliver it as infrastructure as code in your repository, using Microsoft's landing zone accelerators and Azure Verified Modules, with pipelines that validate and deploy changes through pull requests.

That lets your team add subscriptions, change policies and adopt Microsoft's updates to the reference architecture safely, long after our engagement ends.

Common landing zone problems we fix

Most of the landing zones we review weren't designed badly. They were never designed at all, and grew one project at a time. The same problems come up again and again:

• Everything in one or two subscriptions, so costs and access can't be separated
• Owner or Contributor granted broadly and permanently
• Azure Policy missing, or left in audit mode indefinitely
• Flat networks with public IP addresses on workloads that don't need them
• Logs not centralized, or not retained long enough for an investigation
• Inconsistent naming and tagging, which makes cost allocation impossible

Each of these has a known fix, and none of them requires starting over. The order matters, though. We fix identity and access first, because it limits the damage anything else can do.