An enterprise Azure landing zone needs an owned foundation for identity, resource organization, networking, policy, monitoring and workload operations. It should give application teams a repeatable path to deploy within agreed guardrails. The right architecture follows workload boundaries and operating responsibilities rather than copying every component of a reference diagram.

Key takeaways

• Separate shared platform responsibilities from workload-team responsibilities.
• Use subscriptions and management groups for intentional governance boundaries.
• Test identity, routing, DNS, logging and recovery before onboarding production.
• A budget notification is not an automatic spending cap.

Platform and workload landing zones

Microsoft’s landing-zone guidance distinguishes a platform landing zone providing shared foundations from workload landing zones operated within those guardrails. Its reference patterns are starting points for decisions, not evidence that a deployed environment meets every organizational requirement.

The original simplified system diagram below shows responsibility boundaries. It is conceptual: subscriptions, management groups and connectivity must be adapted to the actual estate. A line represents an intended relationship, not an automatically permitted network path.

Microsoft Entra tenant: people + workload identities
                         ↓ scoped authorization
Management-group hierarchy: policy + governance scope
                         ↓ subscriptions
  PLATFORM TEAM                         WORKLOAD TEAMS
  Connectivity subscription             Workload A production
  - hub / Virtual WAN candidate          - application + data
  - hybrid routing + DNS                 - workload monitoring
  Management/security services          Workload A nonproduction
  - approved logs + incident routing     Workload B environments
             ↕ intended network paths and shared services ↕
      Versioned infrastructure + approved deployment workflow
      Ownership | access review | cost allocation | recovery tests

Write the operating model beside the diagram. For example, the platform team may own shared connectivity and baseline policies, while the workload team owns application configuration, data permissions and recovery procedures. Record how a cross-team incident is escalated.

Design management groups and subscriptions deliberately

Group resources around the controls and ownership they require. A subscription boundary can support separation of administration, billing analysis, quotas and lifecycle. It does not replace the need to design identity and data access inside the workload.

The Cloud Adoption Framework design areas cover identity, resource organization, networking, security, management, governance and automation. Use them as a review agenda, then write down your own decisions and exceptions.

A deep hierarchy can become difficult to reason about. Prefer an understandable structure whose inherited controls can be tested. Do not mirror every organizational reporting line if those lines change more often than the cloud governance model.

Identity and access checklist

Define human access, workload access and emergency administration separately. Assign permissions at a justified scope, keep production administration accountable and avoid embedding long-lived secrets in deployment templates.

• Map platform, security and application duties to approved roles.
• Identify who can grant access or change policies.
• Use supported workload identity mechanisms where suitable.
• Define access review, expiry and emergency procedures.
• Test both permitted and denied actions with representative identities.

An identity that can deploy infrastructure may also be able to change data exposure or attach a powerful managed identity. Review those indirect escalation paths. Do not judge least privilege only from a list of familiar role names.

Include service-to-service authorization. A private network route does not authorize an application to read a database, and a valid token does not prove the application should access every tenant’s data.

Networking, routing and DNS

Microsoft’s networking design guidance ties topology to traffic patterns and hybrid or multicloud dependencies. Compare hub-and-spoke and Virtual WAN options against actual scale, routing and operations needs.

Build a traffic matrix: user ingress, workload-to-workload calls, outbound dependencies, management traffic and on-premises connections. For each path, identify authentication, encryption, inspection, DNS resolution and failure behavior.

Test private endpoint name resolution from every relevant execution environment, including build agents and integration runtimes. A successful connection from an administrator’s laptop does not establish connectivity from an application subnet.

Check address-space overlap and route propagation before onboarding more networks. Record who approves firewall and DNS changes, how they are deployed and how a failed change is reversed. Avoid broad access rules as a permanent substitute for diagnosing a routing problem.

Policy, logging and operational ownership

Translate requirements into controls with a known scope and effect. Test policy assignments against representative resources before broad rollout. An audit signal and an enforced deployment restriction are different controls and need different response plans.

For exceptions, record the owner, reason, compensating measure and review date. An undocumented exemption can outlive the workload that originally needed it. Version policy and infrastructure changes so reviewers can understand their impact.

Define which logs are collected, their destination, retention, access and incident use. Confirm that a real test event reaches an actionable alert. Collecting large volumes of diagnostics without an investigation path adds cost and can create unnecessary sensitive-data exposure.

Workload teams still need health checks, deployment validation, backups where required and recovery tests. A shared platform foundation does not prove that an individual application’s restore or failover process works.

Proposed platform change
  → versioned review
  → nonproduction validation
  → representative workload checks
  → approved deployment
  → observed effect + rollback evidence

Cost allocation and guardrails

Microsoft Cost Management budget documentation states that threshold notifications do not stop consumption. Use budgets for accountability and investigation; do not describe them as an automatic hard spending limit.

Define cost owners and required allocation metadata. Review shared platform costs separately from workload costs and agree how they are attributed. Include logs, network processing, data transfer, standby resources and recovery environments in forecasts.

If an automated response is appropriate, specify exactly what it may do and test its operational consequences. Automatically stopping a production resource can cause an outage or data loss. Cost alerts should lead to an approved decision, not an unexamined destructive action.

An enterprise landing-zone decision checklist

Start with a thin, representative workload and validate the platform contract end to end. Expand through repeatable onboarding rather than manual exceptions. Review the design when new data classes, regions or external connectivity materially change the assumptions.

For database workloads, use the Azure SQL migration checklist. For data operations, align platform telemetry with the pipeline observability runbook.

Common questions

Build a foundation your workload teams can use

Bring your subscription estate, connectivity requirements and ownership model to a review. Discuss a cloud architecture and cost review to define a landing-zone design and acceptance checklist for your environment.