Welcome to Part 2 of our Azure Landing Zones Anti-Patterns series.

In Part 1, we explored the design mistakes - the architectural decisions that determine whether your ESLZ stands strong or starts cracking from day one.

Part 2 looks at what happens next.

Because even with robust architecture, the real challenges arise later - costs without ownership, uncontrolled subscription growth, governance implemented too late, naming and tagging slipping into disorder, and monitoring enabled only after something breaks.

These operational anti-patterns don’t show up with loud, dramatic failures.
They accumulate quietly - month after month - until one day you realise the platform isn’t enabling teams anymore. It’s slowing them down.

Your ESLZ might still be technically sound, but operationally?
It’s struggling.

Let’s continue with anti-patterns 6 through 10 - the operational pitfalls that can turn a well-designed landing zone into a long-term source of friction.

Azure makes it incredibly easy to create new subscriptions - and that’s exactly the problem.
A new environment? Spin up a subscription.
A new project? Subscription.
Someons asks nicely? Sure, another subscription.

Fast forward a year and you’re staring at 200+ subscriptions. Nobody remembers who created half of them. Some haven’t been touched in months but still generate costs. Others host critical production workloads with zero documentation or clear ownership.

Without a proper lifecycle process, subscriptions become the wild west:

In short: subscriptions keep getting created, but they never retire.

Mature organisations solve this with a subscription vending model - a simple intake and approval workflow.
Before a subscription is created, the requester must specify:

Once approved, the subscription is automatically:

Sounds bureaucratic?
Maybe.
But it’s far easier than explaining to the CFO why a sizeable monthly bill is coming from orphaned subscriptions nobody even remembers creating.

This one is surprisingly common. Finance sees Azure spending as a single IT budget line. IT “owns” the bill, manages overruns, explains variances, and absorbs the pressure.
Meanwhile, application teams have little visibility into what they consume, what it costs, or why the bill is rising. With no direct accountability, cost becomes somebody else’s problem.

When teams don’t own their cloud spend, predictable behaviours follow:

The result? Azure costs creeping up month after month - often 40 - 60% year-on-year - without any meaningful increase in business value. By the time finance raises a red flag, thousands of resources need auditing and optimisation, and everyone is scrambling.

Mature organisations move away from the “IT pays the bill” mindset and adopt FinOps - shared financial responsibility for cloud.

That means putting the right structures in place:

FinOps isn’t about penny-pinching.
It’s about transparency, accountability, and empowering teams to make thoughtful decisions. When everyone sees the cost of their choices, optimisation becomes a shared habit - not a last-minute firefight.

The platform is ready. Networking is configured. Subscriptions are provisioned.
And then someone says the most dangerous words in cloud architecture:

“Let’s start deploying workloads. We can add governance later.”

That “later” is where the real trouble begins.

When workloads start landing before governance is in place, your environment begins drifting on day one. The symptoms show up quickly:

Fast forward six months: 5,000+ non-compliant resources, each needing remediation, testing, and stakeholder coordination.
Fixing the mess becomes a full-scale project - expensive, risky, and intensely time-consuming.

The simplest solution?
Put governance in place before the first workload lands.

Your baseline should include:

Use Azure Policy initiatives instead of scattered individual policies.
Apply them at the management group level so every subscription inherits the guardrails automatically.

Will developers hit deployment failures early on?
Absolutely - and that’s exactly what you want.
It’s far better to catch issues at deployment time than during a security incident or compliance audit.

The famous last words of many cloud teams:

“We’ll document naming standards and people will follow them.”

No, they won’t.

Without enforced naming and tagging, your Azure estate slowly turns into an archaeological dig site:

Fast forward three years and someone asks:
“What does rg-misc-stuff-2 contain, and can we delete it?”
Silence. Nobody knows. Nobody wants to find out the hard way.

There’s only one real fix: enforce standards with Azure Policy, not wishful thinking.

Harsh? Maybe.
But not as harsh as spending a few lakhs (or more) on consultants to audit, classify, and rename 10,000 unruly resources because your estate became an unmanageable maze.

The platform is live. Applications are deployed. Everything seems fine.
And then someone casually says:

“We should probably set up monitoring.”

At that point, it’s already late.

When monitoring isn’t built in from day one, you’re essentially flying blind:

By the time problems show up, you’re reacting - not managing.

Monitoring isn’t a bolt-on - it’s core platform architecture. A proper ESLZ includes:

These are not optional extras - they’re the observability backbone of your cloud estate.

That wraps up our two-part series on Azure Landing Zones Anti-Patterns.
Across these ten missteps - design and operational - we’ve seen a consistent theme: ESLZ failures rarely come from one big mistake. They come from dozens of small decisions made without alignment, ownership, or guardrails.

The good news? Every one of these anti-patterns is preventable with the right intent, the right governance, and the right habits.
A well-designed, well-operated landing zone doesn’t just support workloads - it becomes the backbone of how your organisation builds, governs, and scales in Azure.

Here’s to building ESLZs that stand the test of time.

If you found this useful, tap Subscribe at the bottom of the page to get future updates straight to your inbox.