The foundation is built. Every article until now has been about pouring something: the tree, the network, identity, the record, the guardrails. This one is about the two things a foundation does after it is poured, which are almost never designed and are almost always the reason a good foundation slowly rots or a mediocre one quietly works. You operate it, day after day, and you grow it, workload after workload. If you built it in the order this series argued for, both of those turn out to be acts of placement rather than reconstruction. Nothing you add from here should require you to move what is already there, and that, more than any single component, is what makes this a foundation rather than a pile of resources.
Operating is a small number of habits, not a full-time job
Day-two operations on an estate this size is not heroics, and anyone selling it as a full-time discipline is selling you something you do not need yet. It is a short list of recurring looks, most of which fit in an hour a month. You watch cost, by tag, and ask whether anything moved that should not have. You watch the Secure Score and the policy compliance dashboard for their trend rather than for a perfect number, because the trend is the signal and perfection is a fantasy. You run the break-glass test on its schedule, you review the exemptions that were supposed to be temporary, and you make a decision on anything still sitting in report-only. The foundation already produces every one of these signals, because the record and the guardrails were built to produce them. Operating is simply the discipline of actually looking, on a cadence, so that the estate does not drift in the gap between when something changes and when someone notices.
Cost is where the tags finally pay you back
The six mandatory tags you enforced were never about tidiness. They were about being able to answer one question without an investigation: what does this workload cost, and who owns it. Microsoft Cost Management groups and filters spend by tag, and a budget scoped to a tag with a threshold alert turns the CostCenter tag into a monthly number per team and a warning before that number becomes a surprise. There is one design detail that trips almost everyone, so I will state it plainly: tags do not automatically flow into the billing and usage data. You turn on tag inheritance in Cost Management so that subscription and resource-group tags are applied to the child usage records, and even then a few resource types do not emit tags into usage at all, so the picture is strong and useful rather than perfect. Enable it deliberately, and the tagging discipline from the policy article becomes a cost model instead of just metadata.
Attribution is the payoff of the tags, but it is not the whole of day-two cost work. Azure Advisor will tell you which virtual machines are oversized and which resources are idle, and acting on that is usually the fastest money you will ever save. For the workloads that run steadily, the commitment discounts, reservations and the savings plan, trade flexibility for a lower rate. One dated caution that belongs in any 2026 version of this advice: Microsoft has stopped selling and renewing the older virtual-machine reservation series, so for compute the savings plan or a current-generation SKU is the path now, not a legacy reserved instance you can no longer buy. The principle is unchanged, only the instrument moved.
Where does the new thing go?
This is the question a foundation exists to answer quickly, and the reason to have built the structure before you needed it is that the answer is almost always already decided. A new workload is a resource group in the subscription you already have. It becomes a new spoke network only when it needs isolation the resource group cannot give it. It becomes a second subscription only for a real reason, genuine blast-radius separation from production, a developer or vendor who must not be able to touch prod, a compliance boundary that demands it, and when that day comes the Non-Production management group you deliberately left empty is already there to receive it. It becomes a new management group only rarely, when a workload archetype needs materially different policy than anything the tree already carries. And it becomes a platform subscription when a shared function grows up enough to warrant its own, at which point the Platform children you created as empty placeholders finally hold something real.
The discipline in that map is the refusal to add a subscription or a management group for the wrong reasons. Not because the org chart changed, not because it feels cleaner, not because the resource count grew, and not because enterprises use a lot of subscriptions. You add a subscription for isolation, compliance, or a genuine platform function, and you add a management group only when a workload needs policy the tree cannot already give it. Everything else is a resource group, which is exactly what you want, because a resource group is the cheapest possible unit of growth and it inherits everything the tree already enforces.
Growing the network, and the region you reserved
Two growth moves deserve a specific note because earlier articles pre-paid for them, and the payment is exactly what makes them cheap now. Adding a workload spoke is peering a new virtual network to the hub inside the address space you already carved out, and that spoke inherits the hub’s name resolution, the diagnostic settings that send its logs to the central workspace, and the tag and location policies, all without a single new decision, because inheritance was the point of building the tree and the hub the way you did. Adding a region is dropping a second footprint into the disaster-recovery address block you reserved, the one that has been sitting unused precisely so that this day would be a deployment and not a re-addressing project.
On regions specifically, the modern guidance has shifted and it is worth getting right. The old reflex was to replicate to your region’s fixed pair, and that instinct is now dated. Azure leans on availability zones for resilience inside a region, and many newer regions have no fixed pair at all, so the honest approach is to use zones where they exist and to choose a second region deliberately, by proximity to users or by what a specific service’s replication actually requires, rather than assuming a pair exists and is the right answer. What made the second region hard to retrofit was never the region choice, which you make when you need it; it was the address space, which you reserved at the beginning. That reservation is the expensive decision, and you already made it.
When to reach for the accelerator, and when not to
You built this foundation by hand on purpose, so that you would understand every piece of it rather than inherit a hundred decisions you never made. There comes a point where hand-assembly stops scaling, more subscriptions than you want to configure one at a time, a platform team that needs repeatability, an estate whose growth outpaces a person clicking through it, and that is when you adopt the landing-zone accelerator built on Azure Verified Modules, in Bicep or Terraform, together with the subscription-vending module that issues new subscriptions already governed and already inside the tree. The reason to wait for that moment rather than starting there is not that the accelerator is wrong; it is genuinely the right tool at scale. It is that adopting it before you understand what it deploys means accepting every decision it encodes without having made any of them yourself. Build small and by hand first, adopt the accelerator when scale actually demands it, and you will adopt it knowing exactly what it does, which is the only safe way to hand a platform to a tool.
The accelerator is not a shortcut past understanding your foundation. It is what you graduate to once you understand it, so that scale becomes repeatable instead of becoming a second job.
The argument the whole series was making
Look back at everything this series deferred, and notice that none of it was left undecided. The second subscription always had the Non-Production management group waiting to receive it. The disaster-recovery region always had its address block reserved. Corp and Online always had their place in the hierarchy the moment the estate needed the distinction. Sentinel always had a workspace designed to switch it on. The accelerator always had a structure to adopt into rather than impose. At no point does growing this estate require moving what already exists, and that is the entire definition of a foundation as opposed to an accumulation of resources. Not that it is finished, but that it grows by placement rather than by rebuild.
That is why the order mattered, and why the concrete went down before the house. You poured the tree, the network, the identity, the record, and the guardrails first, in that sequence, so that the house could get larger for years without anyone repouring the concrete. What you have now is an estate you can operate in an hour a month and grow for as long as the business does, without ever going back to the beginning. The build sheet that follows makes the operating loop concrete, the budgets and the vending checklist and the add-a-spoke runbook and the drift checks, and with it the foundation is not just built but running. That is the end of the series, and the beginning of the part where the foundation simply does its job.
Azure Landing Zones
‹ Previous: [LZ 7.1] Standing Up the Policy Guardrails
Next: [LZ 8.1] Standing Up the Operating Loop ›
