Most Azure estates I review have several workloads sharing one subscription and one large virtual network. It is the single most common finding I have, and it produces most of the others. Here is what that decision costs, before I explain any of it:
- Your security controls are present and doing nothing.
- Nobody owns governance, so exceptions become permanent and broken things stay broken.
- Granting one team access to one application is a manual archaeology exercise.
- Cost attribution depends on tag quality, and tag quality is always worse than you think.
- You have no boundary to show an auditor.
- Every workload you add makes life worse for every workload already there.
If three or more of those sound familiar, read on. There is one fix for all six and it is at the end, so skip ahead if you already know what is wrong with your estate and want to know what to do about it.
How It Happens
Nobody sets out to build this. You get a subscription, you build a virtual network, you deploy the first workload. The second one goes in beside it because there is already a network there and it works. Eighteen months later you have forty resource groups in production and nobody can say which resources belong to which application.
Each of the six problems below sounds manageable on its own. That is why they never get dealt with. Seen together, they are the same problem six times over.
1. Your Security Controls Stop Working
I regularly find a single Network Security Group shared across every subnet in a spoke, containing nothing but the default rules. One of those defaults is AllowVNetInBound, which permits the VirtualNetwork service tag. That tag covers your on-premises address spaces, every peered network, everything reachable through a gateway, and the prefixes in your user-defined routes. In a hub and spoke with a site-to-site connection, that single rule permits traffic from effectively everywhere. The NSG exists, it is in the diagram, and it is doing nothing.
It is configured that way because it has to be. One NSG resource is shared across subnets belonging to different workloads, so the moment you write a precise rule for one, you break another. The only configuration that keeps everything running is one that permits everything.
The same pressure produces the wildcards I find in firewall policies. Shared networks force traffic inside a single application through the hub firewall, so the firewall is carrying volumes nobody has time to model precisely, and any source, any port is the only way to keep the applications up. That is not laziness. It is the design choosing for you.
2. Governance Is Not Owned
Two versions of this, roughly equally common. In the first, governance exists on paper. A consultant built it during a project, it was correct on handover, and then the project ended. Two years on there are deprecated policies still assigned, initiatives referencing agents Microsoft has retired, and compliance rates nobody reads. I have opened environments where an initiative covering backup and virtual machine configuration sat at two percent compliance in production and zero in non-production. That is not a non-compliant estate. That is a policy that stopped matching reality years ago.
The exceptions do the real damage. A policy blocks something an application needs. The team does not raise it, because there is nobody to raise it to, so they engineer around it. A workaround goes in, or a resource lands somewhere it should not, or a feature is dropped. Six months later somebody calls the workaround technical debt and never connects it to the policy that caused it.
In the second version there is no governance at all: a tagging standard in a document that nobody applies because tagging is manual, no budgets or budgets whose alerts are ignored within a month, roles granted directly to user accounts and never reviewed, and no supervision from the business. That last one used to be an internal matter. NIS2 has made it a board matter, and the accountability is personal.
3. Access Control Becomes A Guessing Game
A developer needs access to one application, or a supplier needs to operate one system. In a shared subscription that application is spread across some number of resource groups, and you have to find them all. Miss one and the person cannot do their job, so somebody grants a broader role to make the ticket go away. Grant at subscription scope to save time and you have handed one team access to everything belonging to every other team in there.
This happens because there is no object in Azure that represents the workload, so there is nothing to delegate. The same gap explains the service principal with Owner at the top of the tenant. A consultant needs to deploy a large environment quickly, that is the fastest way, and the intention is always to tighten it afterwards. It never gets tightened, and the blast radius of one stolen credential is now everything.
4. Cost Attribution Depends On Something That Never Works
Ask what an application costs in a shared subscription and the answer comes from tagging. Then look at the tags. I have seen subscriptions where more than half the resources carried none at all. Even where they exist, Azure Policy can enforce that a tag is present. It cannot enforce that the value is correct. Full tag compliance and unusable cost data is a perfectly normal combination.
The cause is that tagging is the only mechanism available once workloads share a billing boundary, and it depends on the discipline of whoever deployed the resource at four o’clock on a Friday. That is not a discipline problem you can solve with policy.
5. There Is No Boundary To Show A Regulator
An auditor asks a reasonable question: what is this system, and what protects it? In a shared subscription the honest answer takes several minutes. The system is a subset of the resources in here. The policies apply to all of it, including things that are not in scope. Access is spread across resource groups you would need to go and enumerate. The network is shared with workloads that have nothing to do with this one.
The answer is difficult not because the controls are absent but because the scope is undefined. Everything you want to point at is entangled with something else, so every question requires days of assembly work. And you get asked more of those questions now than you used to, because NIS2 moved the standard from having controls to demonstrating and evidencing them.
6. Complexity Compounds, And Change Slows To A Crawl
In a shared virtual network, routing cannot stay simple. Every subnet needs routes to every other subnet, to every hub subnet, and to every other spoke. Add a workload and you add routes, in that table and in the others. Eventually nobody can tell you with confidence what path traffic takes from A to B.
The knock-on effect is the expensive one. On-demand self-service is the defining characteristic of cloud computing and it is what you are paying for, but a team cannot provision anything here without a ticket, a route and a firewall exception, because everything they do affects everybody else.
So they stop asking. Shadow IT is not a discipline problem, it is a design symptom. In one review I found more than forty virtual networks in the tenant, three of them connected to the hub, and over a hundred subscriptions sitting at the tenant root outside the scope of any policy. Those appeared because the governed path was slow and the ungoverned path was not.
The Fix Is One Decision, Not Six
All six of those problems have the same cause, so they have the same answer. The Cloud Adoption Framework calls it an application landing zone. One subscription per workload. If the workload needs a network, it gets a small virtual network of its own, peered to the hub. Subscriptions are free, so you are not buying anything. You are just drawing a boundary where there wasn’t one.
Here is what each of the six becomes once that boundary exists.
Security. One NSG per subnet, in a network belonging to one workload, with a deny-all rule at low priority and precise rules above it. Traffic inside the workload stays inside and is filtered at the NIC. The firewall only inspects what crosses a workload boundary, so the rules can be precise and the wildcards go.
Governance. Workloads are categorised once and placed in a management group that matches their requirements. Three tiers is usually enough. Compliance figures then mean something specific, which is what makes ownership possible: somebody can review them on a schedule and treat exception requests as decisions rather than tickets.
Access. The subscription is the workload, so delegation is one assignment at one scope, to a group rather than a user. One service principal per workload keeps the blast radius to a single application.
Cost. A subscription is a billing boundary by default. Every cost is attributed correctly the moment it is incurred, with no dependency on tag quality, and the Cost Centre tag becomes close to redundant.
Compliance. That subscription is the system. These are its policies, this is who has access at this scope, here is its network and firewall rules, its budget, its backups and its flow logs. Same evidence as before, assembled in an afternoon instead of a fortnight.
Complexity. The route table has one entry: 0.0.0.0/0 via the hub firewall. Adding the next workload does not touch it, because the next workload gets its own.
The last one is worth dwelling on, because it is what makes the rest sustainable. A subscription vending process can hand a team a fully networked, policy-compliant landing zone in minutes, with access, routing and security applied automatically. Central IT keeps oversight without becoming the bottleneck. Make the governed path the fast path and the incentive to go around it disappears.
Where To Start
This is not a two-year transformation programme, and you do not have to migrate anything to begin. A new governance structure can be built alongside the existing one, particularly when there are no policies at the tenant root to conflict with. New workloads go into landing zones from day one. Existing workloads move when there is a reason to move them, at whatever pace suits.
What you should not do is add the next twelve workloads to the shared virtual network while you think about it. That decision is being made again every time somebody deploys.
Where Do You Stand
If you have recognised your own estate here, the useful next step is finding out how bad it actually is rather than guessing.
Cloud Mechanix runs a fixed-price Azure Environment Review. Five business days, read-only access, no changes to anything. You get a written report of the findings against the Well-Architected Framework, a remediation plan prioritised by risk and effort, and a session where we walk your team through it. You own the report whether or not you ever work with us again.
If you would rather talk it through first, book thirty minutes. Bring your architecture diagram. There is no pitch deck.