Workload Landing Zone Onboarding

The moment a workload team needs a subscription is the moment a platform’s design is tested. Without a defined path, you get ticket queues, inconsistent configuration, and subscriptions handed over before any governance is active. Onboarding is where the platform contract becomes real.

Purpose

This page explains how a new application team receives a workload landing zone through a controlled onboarding process. The goal is to hand over a subscription that already has correct management group placement, inherited policies, RBAC, a logging baseline, security controls, cost visibility, and a network pattern.

Design Reasoning

Without standardized onboarding, platforms develop ticket queues, inconsistent configuration, unclear ownership, and security drift. Subscription vending is the repeatable path that connects the platform lifecycle to the application lifecycle: the platform team defines product lines and automation; application teams request the landing zone they need.

Product lines should reflect real workload patterns. The common starting set, aligned with Microsoft’s guidance:

• corp-connected — workloads that need routed connectivity to other applications and on-premises through the connectivity subscription’s hub.
• online — internet-facing workloads that connect through modern services (Private Link, exposed APIs/endpoints) and may not need a virtual network.
• sandbox — experimentation, proofs of concept, and MVPs, with deliberately fewer controls.

Architecture Decision Record

Tradeoff: A vending pipeline is more up-front engineering than creating a subscription by hand. It pays back the second time a team needs a subscription, and every time after that.

Recommended Configuration

The split of responsibilities between the platform team and the application team:

Example Implementation

Onboarding checklist

• Subscription is placed in the correct management group
• Required tags are defined
• Budget and cost alerts are enabled
• Defender for Cloud baseline is active
• Diagnostic settings are configured
• Activity Log forwarding is active
• Network pattern is documented
• DNS and private endpoint requirements are known
• Workload RBAC groups are created
• Emergency access is not misused for workload operations
• Ownership is recorded in documentation, CMDB, or repository

New workload request template

1
# New Workload Request
2

3
Workload name:
4
Business owner:
5
Technical owner:
6
Environment:
7
Requested product line: corp-connected / online / sandbox
8
Data classification:
9
Criticality:
10
Connectivity requirement:
11
Expected regions:
12
Needs private endpoints:
13
Logging destination:
14
Budget owner:
15
Go-live target:

Validation Steps

1
# Confirm the subscription context
2
az account show
3

4
# Inherited RBAC at the new subscription
5
az role assignment list --scope /subscriptions/<new-subscription-id> --output table
6

7
# Inherited policy assignments at the new subscription
8
az policy assignment list --scope /subscriptions/<new-subscription-id> --output table
9

10
# Subscription-level diagnostic settings
11
az monitor diagnostic-settings subscription list --subscription <new-subscription-id>

Common Mistakes

• Handing over a subscription before inherited governance is active.
• Using one product line for every workload, or making corp-connected the default when online is more cloud-native.
• Forgetting budget ownership, so cost has no owner.
• Not defining workload RBAC groups, which pushes teams back toward direct user assignments.
• Not documenting DNS and private endpoint requirements.
• Onboarding production workloads before monitoring is in place.

References

• Subscription vending
• Establish common subscription vending product lines
• Subscription vending implementation guidance
• Azure landing zone design areas