Back to guides

Azure Architecture Guide

Azure Landing Zone Drift: Warning Signs and What to Review

How Azure landing zones drift across identity, networking, policy, logging, cost, and ownership, and what teams should review before adding more workloads.

Azure Landing ZoneGovernanceIdentityAzure

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.

Microsoft Alignment

Use Azure Landing Zone guidance to review structure, identity, management, connectivity, and governance. Use 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 blocks production work, use Azure Architecture Assessment to confirm the scope. If the target structure is clear and the backlog needs approval, move into Blueprint or Governance.

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

Related guides