Field notes from the team · Updated weekly
Cloud / Azure

A landing zone you would actually inherit.

Five Azure landing zone patterns that look great in a slide deck and fall apart on day 31. What we use instead, and why the answer is boring on purpose.

The shape of a survivable landing zone

Microsoft publishes a reference architecture for Azure landing zones that is, technically, complete. We have inherited five of them. Three were unusable on the day we walked in, and two had been quietly abandoned in favor of a single flat subscription that the development team actually understood.

The reference is not wrong. It is just designed for an organization with a Cloud Center of Excellence and a dedicated platform team. Most of our clients have neither. What they have is a senior engineer who is also responsible for the help desk.

A landing zone is not a Visio diagram. It is a contract about who is allowed to do what, and who pays when something runs all weekend by accident. If those two questions do not have one-sentence answers, the architecture is theater.

Subscriptions are not free

The default advice is to split workloads across many subscriptions for blast-radius isolation. This is correct in principle and exhausting in practice. Each new subscription is a new place to apply policy, a new RBAC graph to maintain, and a new line item on the invoice your CFO will ask about.

For mid-market clients we start with three subscriptions and only split further when we have evidence we need to:

platform     // connectivity, identity, monitoring — the shared spine
production   // everything that touches a customer or a regulator
non-prod     // dev, test, sandbox — with hard cost caps

If you can tell us, with a straight face, why a fourth subscription earns its keep, we will add it. Otherwise three is the answer.

Policy as a guardrail, not a jail

Azure Policy is the most under-used governance tool in the Microsoft cloud and the most over-applied one, at the same time. Teams either ignore it entirely or assign every built-in initiative they can find and then spend six months exempting themselves from their own policies.

Our default initiative is small on purpose. Eleven policies, all Deny or DeployIfNotExists, no Audit-only entries. If we cannot justify a policy strongly enough to enforce it, we are not adding it as decoration.

An audit-only policy is a sticky note. It is not a control.

Cost governance from day zero

Every non-production subscription gets a budget alert at fifty percent, eighty percent, and one hundred percent of the agreed monthly figure. The one-hundred-percent alert routes to a Logic App that disables the most expensive resource group in that subscription and posts to a Teams channel.

Yes, this has triggered. Yes, it has been controversial. It has also, in three years, prevented exactly one cloud bill that would have ended a CTO's career.

Day 31 is the only date that matters

Cutover day looks great. The diagrams render, the migration scripts complete, the smoke tests pass. We do not measure success on day one. We measure it on day thirty-one, when the engagement team is gone and the client's senior engineer needs to add a new workload at 5pm before a long weekend.

If the answer to "where do I put this?" takes more than ninety seconds, the landing zone has failed. That is the bar. Everything else is decoration.

RC
Renata Carvalho
Cloud Architect · Xzidian

Renata leads cloud infrastructure engagements at Xzidian, with a focus on Azure landing zones and Terraform-based platform delivery. She has migrated more workloads than she has fingers and remembers each one with the specificity of a grudge.