Building a Governed Azure Landing Zone for Enterprise Cloud Adoption

Executive Summary

Business context — Contoso: Contoso is expanding Azure use across application and data teams. Inconsistent subscription ownership, identity boundaries, and network paths create a need for a secure, standardized cloud foundation that teams can adopt without bespoke infrastructure decisions.

As organizations expand their use of Microsoft Azure, cloud environments often grow faster than the governance model around them. Subscriptions are created independently, networking patterns diverge, access controls become inconsistent, and platform teams spend increasing amounts of time reviewing one-off infrastructure decisions.

This Contoso case narrative describes a production-oriented architecture and implementation approach for an enterprise Azure Landing Zone: a standardized cloud foundation that provides clear subscription structure, secure connectivity, identity controls, policy enforcement, observability, and Infrastructure as Code from the start.

The objective is not to create a rigid platform that blocks application teams. The objective is to establish a controlled baseline that allows teams to deploy faster without repeatedly solving identity, networking, security, monitoring, and governance problems.

Organization reference: Contoso is the organization name used throughout this technical case narrative. Architecture parameters and resource names are documented as reference values; exact tenant identifiers, IP allocations, commercial terms, and environment-specific settings are excluded. The design is not evidence of a completed client engagement or measured result.

The Challenge

Contoso’s Azure foundation is designed to address common enterprise-scale challenges:

• Subscriptions are created without a consistent hierarchy or ownership model.
• Networking varies between environments and applications.
• Public endpoints are used where private connectivity would be more appropriate.
• RBAC assignments accumulate without clear role boundaries.
• Security and compliance controls rely on manual review.
• Diagnostic settings and monitoring coverage differ between services.
• Infrastructure is deployed manually or through project-specific scripts.
• Development teams depend heavily on central cloud administrators.
• Cost ownership is unclear.
• New workloads take too long to onboard because each team starts from a different baseline.

Contoso needs a cloud foundation that can support both current workloads and future growth without forcing every project to design its own platform.

Objectives

The target Azure Landing Zone is designed to achieve the following:

1. Establish a scalable Azure tenant and subscription structure.
2. Standardize identity, security, networking, monitoring, and governance controls.
3. Separate platform responsibilities from application responsibilities.
4. Reduce manual configuration through Infrastructure as Code.
5. Make new subscriptions and workload environments repeatable.
6. Provide centralized visibility without preventing workload teams from operating independently.
7. Support private application architectures and enterprise connectivity.
8. Create a foundation suitable for Kubernetes, data platforms, AI workloads, and traditional applications.

Architecture Approach

Management Group and Subscription Structure

The Azure hierarchy is designed around clear policy and ownership boundaries.

The proposed structure includes:

Tenant Root Group
├── Platform
│   ├── Connectivity
│   ├── Identity
│   └── Management
├── Landing Zones
│   ├── Corp
│   └── Online
├── Sandbox
└── Decommissioned

Workload subscriptions inherit controls from the appropriate management group instead of receiving manually configured governance settings one subscription at a time.

Platform subscriptions isolate shared capabilities such as connectivity, centralized monitoring, shared security services, DNS, automation, and management tooling.

Network Foundation

The connectivity model is selected according to scale and requirements. Common patterns include hub-and-spoke networking or Azure Virtual WAN.

The shared network foundation is designed around:

• centralized ingress and egress
• Azure Firewall
• VPN or ExpressRoute connectivity
• private DNS
• Private Link and Private Endpoints
• network security groups
• route tables
• DNS forwarding
• controlled connectivity between workloads

The design avoids unnecessary public exposure and creates a predictable method for connecting applications to Azure PaaS services.

Private DNS is treated as part of the architecture rather than an afterthought, especially for services accessed through Private Endpoints.

Identity and Access

Microsoft Entra ID and Azure RBAC establish least-privilege access.

The access model defines:

• platform administrator roles
• workload team roles
• reader and operational roles
• privileged access processes
• managed identities for workloads
• workload identity federation for CI/CD
• role assignments managed through code where practical

Long-lived deployment secrets are avoided when native identity federation can be used.

Governance with Azure Policy

Azure Policy provides preventive and detective controls at management-group and subscription level.

The governance baseline covers:

• allowed regions
• required resource tags
• diagnostic settings
• approved resource configurations
• restrictions on public network access
• encryption requirements
• secure transport requirements
• network controls
• resource naming conventions where justified

Policies are organized into initiatives so the governance model remains understandable and versionable.

Monitoring and Management

The Landing Zone includes a common observability baseline.

The observability baseline covers:

• Azure Monitor
• Log Analytics
• activity logs
• resource diagnostics
• alert rules
• Service Health alerts
• platform dashboards
• Microsoft Defender for Cloud
• centralized security findings
• operational runbooks

Diagnostic configuration is standardized so new subscriptions and workloads do not depend on manual monitoring setup.

Infrastructure as Code

The platform design uses reusable Infrastructure as Code, with Terraform or Bicep selected according to delivery requirements.

The proposed repository organization is:

platform/
  management-groups/
  policy/
  connectivity/
  identity/
  monitoring/
  subscription-vending/

landing-zones/
  corp/
  online/

modules/
  network/
  private-endpoint/
  diagnostics/
  role-assignment/
  key-vault/

Reusable modules provide a consistent implementation pattern without hiding critical platform decisions behind excessive abstraction.

CI/CD Integration

Platform changes are deployed through controlled pipelines.

Deployment identities use federated authentication where supported.

Implementation Sequence

1. Discovery and Current-State Assessment

Review:

• Azure tenant structure
• existing subscriptions
• identity model
• network topology
• connectivity dependencies
• security requirements
• monitoring
• deployment practices
• existing IaC
• regulatory or internal controls

2. Target Architecture

Define:

• management-group hierarchy
• subscription model
• network topology
• DNS strategy
• identity boundaries
• policy baseline
• monitoring model
• operational ownership
• IaC repository structure
• CI/CD process

3. Platform Foundation

Deploy core platform capabilities such as management groups, policies, platform subscriptions, connectivity, monitoring, and identity integrations.

4. Landing Zone Patterns

Create reusable workload patterns for common application types, such as private PaaS applications, AKS platforms, traditional VM workloads, data platforms, and AI workloads.

5. Subscription and Workload Onboarding

New subscriptions are onboarded using the standardized process rather than manually recreating controls.

6. Operational Handover

Provide architecture documentation, IaC repositories, deployment pipelines, operating procedures, troubleshooting guidance, ownership model, and platform backlog.

Production Architecture and Low-Level Implementation

The following sections describe the target design at the level required for a platform engineering team to implement, secure, validate, and operate it. Resource names, address ranges, and subscription labels are reference configuration values, not extracts from a customer's tenant. Final values are allocated through the customer's IP address management (IPAM), security approval, and change-control processes.

Scope, assumptions, and service boundaries

The landing zone covers tenant-level resource organization, shared connectivity, security guardrails, platform observability, subscription provisioning, and workload onboarding. It does not automatically make each application highly available or compliant: application teams retain responsibility for application topology, data classification, recovery objectives, backup validation, and workload-specific security.

The architecture assumes one Microsoft Entra tenant, existing corporate identity governance, private connectivity to corporate systems where justified, a primary Azure region with an optional disaster-recovery region, and dedicated platform ownership. Region selection is conditional on data residency, service availability, latency, and disaster recovery requirements. A second region is not treated as a substitute for tested failover.

1. Organization and subscription design

A dedicated intermediate root management group (contoso) provides the policy inheritance boundary beneath the tenant root. The hierarchy distinguishes shared platform services from application landing zones; it is not organized by individual application or Azure region.

The corp and online categories represent different connectivity and policy requirements, not levels of trust. Production and nonproduction workloads can use distinct subscriptions within the appropriate management group. Subscription naming is standardized; the globally unique subscription ID, rather than the display name, remains the stable automation key.

Platform subscription partition: The connectivity subscription hosts regional hubs, Azure Firewall, gateways, DNS resolver and private DNS zones. The management subscription hosts centralized telemetry and operational automation. The identity subscription is reserved for Azure resources with an identity-platform function; Microsoft Entra ID itself remains a tenant-level service and is not deployed inside this subscription.

Subscription vending contract: Each request carries a workload identifier, business owner, technical owner, cost center, environment, data classification, approved region, connectivity class, and requested address capacity. The pipeline checks uniqueness and approvals, records the subscription ID, assigns it to the correct management group, applies RBAC and mandatory policies, configures budgets and diagnostics, and optionally creates a spoke VNet and peering. If commercial enrollment does not permit programmatic subscription creation, subscription creation is an approved manual step and remaining configuration remains automated.

A request is not complete when the subscription exists; it is complete when policy compliance, diagnostic forwarding, access assignments, networking, and budget notifications have been validated and documented.

2. Regional hub-and-spoke network

Reference address plan (illustrative configuration, subject to IPAM approval):

These prefixes must not overlap with on-premises networks, acquisition networks, VPN partners, other VNets, or reserved future allocations. Route summarization is considered when allocating prefixes; exact CIDRs are managed in IPAM, not manually selected from this article.

A primary hub VNet can reserve AzureFirewallSubnet (/26 or larger), GatewaySubnet (sized for gateway requirements), and dedicated Azure DNS Private Resolver inbound/outbound subnets meeting the service's delegation and sizing requirements. Other subnets are reserved only when a corresponding service has been approved. Azure Firewall is deployed with the policy and SKU selected to match inspection, threat intelligence, TLS inspection and availability requirements; TLS inspection is not enabled by default without certificate and data-handling review.

Traffic flows and enforcement:

1. Spoke to internet: For workloads requiring centralized egress inspection, a route table sends 0.0.0.0/0 toward Azure Firewall's private IP. Firewall Policy governs application/network rules and outbound destinations. Required platform exceptions and asymmetric routes are reviewed explicitly.
2. Spoke to on-premises: Approved prefixes transit through a VPN/ExpressRoute gateway and designated hub path. Effective routes and return paths are validated; routing choices are adjusted for gateway transit and any forced tunneling requirements.
3. Spoke to spoke: VNet peering alone does not provide transitive routing. Connectivity is either explicitly authorized, inspected via the hub, or denied. The design must include matching route tables and firewall policies, not merely peering links.
4. On-premises to private application: The route must reach the intended private IP, DNS must resolve the correct private address, and NSG/firewall/application controls must all permit the flow. A Private Endpoint does not by itself authorize users or encrypt an application-layer session.
5. PaaS private access: Private Endpoints are created in approved workload subnets, with corresponding service-specific private DNS zone groups. Public network access is disabled only after private access and break-glass operational procedures have been tested.

Peering settings such as allowForwardedTraffic, gateway transit, and remote gateway use are configured intentionally and checked for compatibility. Spoke peering is not treated as an implicit security boundary; network security groups, routes, firewall policy and service-level access controls remain necessary.

Private Endpoint routing nuance: If inspection of traffic to a private endpoint is required, the design must account for private endpoint network policies and the effective route behavior for the subnet and prefix. A blanket /0 user-defined route does not, by itself, guarantee that all private endpoint traffic passes through a firewall. Effective routes, DNS answers and observed traffic must be tested per workload.

3. DNS and Private Link implementation

Contoso uses private DNS zones owned by the platform team so different workload teams do not create conflicting zones for the same Azure service. Common zones include:

privatelink.blob.core.windows.net
privatelink.file.core.windows.net
privatelink.database.windows.net
privatelink.vaultcore.azure.net
privatelink.azurecr.io

For a hub-based hybrid architecture, Azure DNS Private Resolver supplies an inbound endpoint for queries forwarded from on-premises DNS and an outbound endpoint for approved forwarding to on-premises DNS. DNS forwarding rulesets are linked to appropriate spoke VNets. Private DNS zone links or a resolver-based forwarding strategy are selected deliberately; the same private namespace must not be resolved by inconsistent, competing designs.

Example: access to an Azure SQL Database private endpoint

The actual SQL hostname, private IP, DNS records, and service endpoints are provisioned and validated through IaC. Private DNS record and zone-group ownership are explicitly assigned; manual A-record patches are not an acceptable permanent fix.

DNS test cases: Query from a production spoke, nonproduction spoke, connected on-premises DNS client and deployment runner (if it uses private services). Compare the resolved private IP with the endpoint NIC, then test transport connectivity and application authentication. Also check what happens when resolver forwarding or the hybrid link is unavailable; failures should be visible in alerting and runbooks.

4. Identity, access control and privileged operations

Azure RBAC assignments are made to Entra security groups rather than individual user accounts, with distinct groups for platform operations, connectivity, security readers, workload operators and billing visibility. Azure RBAC access is scoped to the narrowest practical management group, subscription or resource group. Built-in roles are preferred; custom roles are introduced only when approved operations cannot be covered safely by built-in roles.

Privileged Identity Management (PIM), if available under Contoso's licenses, provides eligible just-in-time role activation for sensitive human roles. Conditional Access, multifactor authentication and identity governance remain tenant-wide security dependencies. Managed identities are preferred for Azure-hosted workloads; federated workload identity is preferred for supported external CI/CD. Long-lived service-principal client secrets are not used as the default deployment mechanism.

Bootstrap separation: Creating management groups, baseline role assignments, federated identities and Terraform backend infrastructure requires a documented bootstrap identity and approvals. The bootstrap process is separated from normal pipeline operations; it does not leave unrestricted tenant permissions embedded in ordinary CI/CD jobs.

5. Policy-as-code baseline and exception control

Azure Policy is applied as version-controlled initiatives at the lowest reusable management-group scope. Deny, Audit, Modify, and DeployIfNotExists are assigned according to resource support, operational impact, and remediation requirements; audit findings are not described as preventive controls.

A production rollout first evaluates the compliance impact on existing resources, then uses a defined remediation window, and finally enables preventive effects where approved. Policy exemptions require a ticket, owner, exact scope, justification, compensating control, and expiration. Permanent broad exemptions at tenant scope are prohibited by process. Policy definition/initiative versions are pinned and promoted through review; built-in definition updates are tested for changed behavior.

Policy release procedure: Export pre-change compliance results; deploy to a controlled scope; inspect deny/remediation outcomes and access failures; apply to production at an approved change window; capture deployment IDs and new compliance state. Rollback consists of restoring the prior assignment/initiative version or effect and remediating impacted resources—not simply reverting a Git commit and assuming Azure resources have reverted.

6. Terraform implementation and state management

The source structure separates high-privilege platform concerns from workload subscription onboarding and application modules. A module is independently versioned; environment roots hold the state boundary and approved input values.

infra/
  bootstrap/                  # state storage, federation, minimal deployment identities
  platform/
    management-groups/
    policy/
    connectivity/
      primary/
      secondary/
    dns/
    management/
  subscription-vending/
    requests/
    deployment/
  landing-zones/
    corp/
    online/
  modules/
    network-hub/
    spoke-network/
    private-endpoint/
    diagnostic-settings/
    role-assignment/
    subscription-baseline/
  policies/
    definitions/
    initiatives/
    assignments/
  pipelines/
  docs/
    adr/
    operations/
    validation/

State architecture: Each root uses a separate remotely stored Terraform state key in a secured Azure Storage account, with backend access authenticated via Entra ID and RBAC. Blob versioning/soft delete, state locking, storage firewall/private connectivity, encryption, access auditing and recovery procedures are configured according to security requirements. Terraform state may include sensitive data despite sensitive = true on outputs; state storage is treated as privileged material. A backup strategy is tested with a nonproduction restore, and state migrations use reviewed moved blocks/import plans where appropriate.

Sample backend configuration (placeholders, not actual tenant values):

terraform {
  required_version = ">= 1.8.0"
  backend "azurerm" {
    resource_group_name  = "rg-contoso-tfstate-prod"
    storage_account_name = "<approved-unique-state-account>"
    container_name       = "tfstate"
    key                  = "platform/connectivity/primary.tfstate"
    use_azuread_auth     = true
  }
}

Provider and Terraform versions are constrained and the generated lockfile is checked into source control. Workspaces are not used as the sole isolation mechanism between production and nonproduction where distinct access controls, lifecycle ownership and state recovery are needed.

Practical deployment sequence:

1. Provision the state backend and federated pipeline identities through an approved bootstrap run.
2. Create the intermediate management-group hierarchy and baseline roles.
3. Deploy shared observability and policy assignments in audit mode where required.
4. Allocate hub/spoke CIDRs in IPAM and deploy regional connectivity, gateways and firewall policy.
5. Configure Private DNS zones, resolver endpoints, forwarding rules and hybrid DNS validation.
6. Promote selected policies to deny/remediation after compatibility and connectivity tests.
7. Enable subscription vending and onboard an initial production workload under change control.
8. Transfer platform ownership with runbooks, dashboards, source repositories and break-glass procedures.

7. CI/CD security and release control

Pull requests run formatting, terraform validate, static security analysis, custom policy checks and a read-only plan. A trusted deployment identity is used only in authorized environments. Production apply requires protected branch rules, reviewed plan output, separation of duties where required, and environment approval. Plan files are access-controlled artifacts because they can contain sensitive values.

GitHub Actions or Azure DevOps uses an OIDC federated credential bound to the approved repository, branch/environment and identity configuration. CI/CD permissions are separated for plan and apply when feasible. Terraform plan output is reviewed for replacements and deletions, especially firewall, gateway, DNS and policy changes. An unsuccessful apply triggers investigation and a new reconciled plan; a blanket automatic retry or destructive rollback is not appropriate for shared infrastructure.

8. Monitoring, security telemetry and incident operations

Azure Activity Logs are forwarded for subscription-level control-plane visibility. Diagnostic settings on supported platform services forward selected categories to Log Analytics and, where specified, an Event Hub or storage archive for SOC integration/retention. Azure Monitor alerts include actionable thresholds, owner routing, severity, and a documented suppression/escalation procedure. Monitoring design distinguishes platform availability from application service-level objectives.

Log ingestion and retention are costed explicitly. Data collection rules, workspace access, diagnostic categories, retention periods, regional restrictions, and any cross-region aggregation are selected by regulatory and operational requirements rather than assumed uniform across all services.

Operational procedures: The handover package includes firewall change workflow, DNS zone change workflow, policy exemption approval, failed subscription onboarding recovery, Terraform state lock investigation, privileged access review, certificate/secret rotation, and disaster recovery decisions. Each procedure states an owner, prerequisites, escalation path, rollback conditions, and validation evidence.

9. Subscription vending and onboarding workflow

A workload onboarding request includes a schema-validated record such as the following. The values are examples of a request interface, not production records.

workload_id: orders-api
business_owner: business-unit-a
technical_owner: application-platform-team
environment: prod
management_group: corp
region: canadacentral
connectivity: hub-spoke
network_cidr: 10.64.32.0/21
cost_center: CC-0000
data_classification: confidential
public_ingress: false

After approval, the onboarding pipeline checks the CIDR against IPAM and live peering inventory, creates or configures the subscription, assigns it to the approved management group, installs group-based RBAC and policies, registers needed resource providers, applies diagnostic/budget settings, creates the spoke VNet if requested, provisions two-way peering and corresponding route tables, and runs network/DNS tests. Re-running the pipeline should converge on the desired configuration instead of producing duplicates.

The handover includes subscription ID, management-group path, access-group identifiers, resource inventory, assigned CIDR, route tables, DNS resolution results, applied policy set, diagnostics status, budget owner, and support contacts. Application teams should not receive broad permissions to change centrally owned firewall policy, shared DNS zones or management-group assignments.

10. Availability, disaster recovery and change safety

Production design begins with documented recovery time objective (RTO) and recovery point objective (RPO) per workload and shared service. Availability Zones are used only for services and regions that support them; zone resilience is not the same as geographic recovery. Secondary-region network components are deployed when justified by recovery architecture, service dependencies and budget.

For the shared foundation, recovery planning covers Azure Firewall/gateway service resiliency, DNS resolution, configuration recovery from source control, state backend recovery, management workspace availability, and hybrid circuit failure. The platform team tests infrastructure redeployment or recovery procedures; application data restoration and transactional consistency remain application-specific responsibilities.

Change-risk controls: No uncontrolled deletion or replacement of a production hub, gateway, shared DNS resolver, firewall policy or root policy assignment. Changes with potential connectivity impact require a documented maintenance plan, dependency mapping, communication window, post-change test and rollback path. For Terraform resources whose replacement is particularly destructive, prevent_destroy may be applied selectively, while recognizing that it is not a substitute for approvals or backups.

11. Production verification and acceptance criteria

A completed infrastructure deployment is not sufficient evidence of operational readiness. The following tests should be captured in the commissioning record with command output, timestamps, environment IDs, accountable approvers and any open exceptions.

The final sign-off should enumerate known deviations, business acceptance of residual risks, the managed-service boundary, and an agreed backlog. No deployment duration, cost savings, compliance percentage or reliability improvement should be published without actual measurements and customer authorization.

12. Implementation risks and design trade-offs

• Central hub vs. Virtual WAN: Hub-and-spoke offers direct configuration ownership and fits many regional designs; Virtual WAN may be preferable for large-scale branch, region or connectivity requirements. The choice depends on connectivity counts, operational capabilities, feature requirements and cost modeling.
• Centralized firewall vs. workload-level controls: Egress inspection adds cost, routing complexity and operational dependencies. Not every service flow is meaningfully secured by hairpinning it through a hub.
• Mandatory private endpoints: Strong private-access patterns increase DNS and operational complexity; implementation must validate management/deployment access before disabling public endpoints.
• Strict deny policies: Premature Deny effects can block existing deployment pipelines and managed-service operations. Policy lifecycle needs staged adoption and controlled exceptions.
• Shared Log Analytics workspace: Central visibility simplifies operations but requires attention to permissions, regional log residency, ingestion costs and retention requirements.
• Subscription-per-workload: Strong boundaries aid cost and ownership, but too many subscriptions without vending, naming and lifecycle automation increase administrative overhead.

Delivery Evidence and Documentation Standard

For publication as a verified client delivery, the case record should be supported by redacted architecture decision records, approved diagrams, implementation change records, deployment logs, policy compliance exports, commissioning test results, and client-approved outcome statements. Contoso is the organization name used for this reference narrative; the name alone does not establish that the described implementation occurred. This technical description should therefore be used as a production architecture case narrative unless project evidence is available to substantiate completion and results.

Project Deliverables

The proposed delivery scope includes:

• Azure Landing Zone architecture
• management-group hierarchy
• subscription design
• hub-and-spoke or Virtual WAN network design
• private connectivity and DNS patterns
• identity and RBAC model
• Azure Policy baseline
• centralized monitoring architecture
• Infrastructure as Code
• CI/CD deployment pipelines
• architecture decision records
• operational documentation
• workload onboarding patterns

Expected Architectural Outcomes

The proposed design integrates governance and engineering standards into the cloud foundation instead of applying controls manually after deployment.

For Contoso, this establishes a consistent deployment model for application teams while retaining centralized management of identity, networking, security, policy, monitoring, and cost controls.

The architecture also supports future initiatives such as application modernization, AKS adoption, platform engineering, data platforms, secure Azure AI deployments, and multi-environment application delivery. These are intended architectural capabilities, not reported performance measurements.

Before and After Implementation: Operational Improvement Comparison

The comparison below maps Contoso's baseline challenges to the intended operating state after implementing the specified Azure Landing Zone. The “after” column describes target capabilities and expected improvements, not independently verified results or measured customer KPIs.

How to substantiate the improvements: For a customer-approved case study, capture before/after metrics such as median subscription provisioning lead time, percentage of subscriptions covered by required policies, percentage of critical resources with diagnostics enabled, number of standing privileged assignments, and change failure rate. Report numeric improvements only when the baseline, observation period and post-deployment evidence are available; otherwise retain the qualitative comparisons above.

Why the Design Is Operationally Sustainable

The platform team owns the guardrails.

Workload teams own their applications.

Infrastructure as Code makes the model repeatable.

Policy and identity make the controls enforceable.

Centralized monitoring makes the environment operable.

The design provides more than an Azure environment: it establishes an operating model for enterprise cloud adoption.

Technologies

Microsoft Azure · Azure Landing Zones · Terraform · Azure Policy · Microsoft Entra ID · Azure RBAC · Azure Firewall · Private Link · Private DNS · Azure Monitor · Log Analytics · Microsoft Defender for Cloud · GitHub Actions / Azure DevOps

Related Patterns

• Azure landing zone product design
• What comes after a landing zone