Azure Landing Zone Drift: Warning Signs and What to Review

Quick Answer

Azure landing zone drift happens when subscriptions, identity, policy, networking, logging, cost controls, and ownership move away from the agreed platform standard.

Drift is normal after teams ship real work. The issue is not that exceptions exist. The issue is that no one knows which exceptions are approved, temporary, risky, or expensive.

When This Matters

Review landing zone drift when Azure has moved beyond one workload or one team.

Common signs:

1. Subscriptions no longer follow the intended management group structure.
2. Policy assignments exist, but exceptions are not reviewed.
3. Public endpoints or private networking decisions differ by workload.
4. Log retention, budgets, and alerts vary without a clear reason.
5. Teams cannot explain who owns platform decisions after launch.

What To Decide

The team should decide:

1. Which landing zone standard applies now?
2. Which subscriptions and workloads are in scope?
3. Which exceptions are approved and which need cleanup?
4. Which controls should become policy, documentation, or a backlog item?
5. Which owner approves future exceptions?

Azure Components

Landing zone drift usually touches:

1. Management groups and subscriptions.
2. Azure Policy and initiatives.
3. RBAC, PIM, managed identities, and break glass access.
4. Hub and spoke networking, private endpoints, DNS, firewall, and routing.
5. Defender for Cloud, Azure Monitor, Log Analytics, and alerts.
6. Tags, budgets, reservations, and cost allocation.

Management Groups

Structure and subscriptions

Azure Policy

Guardrails and exceptions

Identity & Access

RBAC, PIM, managed identities

Networking

Hub-spoke, private endpoints, DNS

Monitoring

Defender, Monitor, Log Analytics

Cost

Tags, budgets, reservations

Diagram examples use sanitized Azure components and architecture notes.

Microsoft Alignment

Use Azure Landing Zone guidance to review structure, identity, management, connectivity, and governance. Use Cloud Adoption Framework (CAF) govern and manage guidance to decide who owns exceptions and recurring review.

The goal is not to copy a reference architecture. The goal is to choose the standard your current Azure estate can follow.

Common Mistakes

1. Calling every deviation a problem.
2. Fixing network drift without reviewing identity and policy.
3. Cleaning up cost without changing ownership.
4. Treating landing zone work as a one-time project.
5. Adding more workloads before the exception process is clear.

RedDogSME Recommendation

Start with the highest risk drift: identity, public exposure, logging, cost ownership, and policy exceptions. Do not redesign everything at once.

If the drift is blocking production work, start with an Azure Architecture Assessment to confirm the scope, the owners, and the highest-risk exceptions. The assessment names what to fix now and what routes into a Blueprint Sprint or governance — so the team books one call, not three.

See a composite example: Turning Landing Zone Drift Into an Approved Standard.

Related Topics

1. Azure Architecture Assessment
2. Azure cost governance
3. Architecture board operating model
4. Microsoft-aligned Azure environment method