A cost-aware Azure landing zone for a team of three

Microsoft's landing-zone guidance is good, thorough, and written for an organisation with a platform team. If you are small team of engineers with a production deadline, following all of it is a quarter you do not have, and ignoring all of it costs you more later. This is where we draw the line.

The guidance gap

The enterprise-scale reference architecture assumes management groups, a dedicated identity subscription, hub-and-spoke networking, a policy library and someone to own it. Every piece is justified at the scale it was written for. At small scale the failure is predictable: teams attempt the whole thing, stall, and end up with resources created by hand in a single subscription: the exact outcome the guidance exists to prevent.

The useful question is which decisions are expensive to reverse. Those you make on day one. The rest can wait until there is someone to maintain them.

What to keep on day one

• Subscription separation for production. Production alone, non-production together if you must. Merging later is easy; extracting production from a shared subscription after a year is not.
• A naming and tagging convention, enforced. Owner, environment and cost-centre tags, applied by policy. Retro-tagging four hundred resources is nobody's good week.
• Infrastructure as code from the first resource. Bicep is the lower-friction choice on Azure; Terraform if you are multi-cloud or already fluent. The point is that a rebuild is a command.
• Entra ID groups, never individual assignments. Access granted to a person is access nobody removes when they leave.
• Key Vault and managed identities before the first secret. A credential in a repository stays in the history after you delete it, which turns a five-minute fix into a rotation exercise.
• A budget with an alert. Ten minutes of work. It is how you find out about the accidentally over-provisioned service on day three rather than in the monthly invoice.

What to defer

• A deep management-group hierarchy. One layer under the tenant root is enough for a small estate. Restructuring later is a metadata exercise, not a migration.
• Hub-and-spoke networking. Genuinely necessary with multiple business units or on-premises connectivity. With one product and no data centre it is a firewall bill and a diagram to maintain.
• A large custom policy set. Start with the handful that prevent the mistakes you actually make: public storage, untagged resources, expensive regions. Adopt more when someone owns them.
• Private endpoints everywhere. Correct for regulated data. For a public web application with a managed database, service firewall rules plus managed identity gets most of the benefit for a fraction of the complexity.
• Kubernetes. Unless you already run it well. App Service and Container Apps carry an enormous amount of small-team workload without an operational tax you have not budgeted for.

The cost controls that matter

In the small estates we have reviewed, most overspend came from four places, in this order: environments left running outside working hours, databases provisioned for a load that never arrived, log retention set generously and never revisited, and orphaned disks and public IPs from deleted resources.

None of that needs a FinOps practice. It needs tags that identify an owner, a budget alert, and a recurring half-hour in someone's calendar. We usually automate the first sweep and leave the schedule behind as a scheduled job.

A workable order

1. Subscriptions and one management-group layer; tags and naming agreed in writing.
2. An infrastructure-as-code repository with a pipeline that plans on pull request and applies on merge.
3. Entra ID groups and role assignments; Key Vault with managed identities.
4. The first workload, deployed only through the pipeline: no portal exceptions, including for you.
5. Monitoring on the one path that matters, plus a budget alert.
6. Then, and only when a person owns each: policy expansion, network segmentation, private endpoints.

A week of work for most small estates, and it holds up for years. If you want a second opinion on a landing zone you are part-way through, that is a conversation we are happy to have: get in touch.

---

Questions or disagreement are welcome: info@rdrightnow.com. We would rather be corrected than quoted.