Azure Landing Zone for SAP in 2026: How We Structure It

We spend more time reading Microsoft Learn pages than we’d like to admit. This spring our lab finally got approval to move a real SAP landscape to Azure, and before touching a single VM we spent three weeks arguing about landing zones: which management group, which subscription, who can deploy what. This post is the structure we settled on, plus everything that surprised us. If you are about to plan RISE with SAP on Azure or hand-build SAP HANA on Azure VMs, the subscription and governance decisions below come first — the compute decisions come second.

Why SAP Earns Its Own Landing Zone Conversation

Microsoft’s Cloud Adoption Framework treats the Azure landing zone as the “fabric controller environment” for an organization: management groups, subscriptions, policies, identity, connectivity, and operations laid down before any workload lands. The Azure landing zone overview describes it as a consistently governed platform that individual workload teams then consume rather than rebuild.

SAP is not an afterthought in that design. The subscription design area of the same framework explicitly names SAP alongside high-performance computing and IoT as a “large specialized workload” that should use separate subscriptions to avoid running up against platform limits. That same page gives three reasons we now repeat in every review meeting: subscriptions are a scale unit, a management boundary for governance and isolation, and a policy boundary — because “development environments have more relaxed policy requirements than production environments.” A 2 TB-in-memory database box with a very different risk profile than your chatbot demo does not want to share a quota namespace or a policy scope with the demo.

There is also a supportability angle. Before anything else, we confirmed our product/OS/database combinations against the Microsoft page on what SAP software is supported for Azure deployments, which points to SAP support note 1928533 as the starting point for supportability questions, and to the running list of SAP certifications and configurations on Azure. Governance decisions that contradict what SAP and Microsoft actually certify are wasted work, so we gate the architecture on those two pages first.

Platform Landing Zone, Workload Landing Zones, and the Management Group Tree

The framework splits the world into two kinds of landing zones. The platform landing zone is built once per Microsoft Entra tenant: a management group hierarchy plus centralized resources (identity, connectivity, management, security) and a subscription-vending mechanism that produces new subscriptions with policy and access already applied. Workload landing zones — where SAP lives — are organized by environment (think dev, test, prod), each composed of one or more subscriptions placed under the platform hierarchy, typically under an Online, Corp, or Local management group so they inherit the right Azure Policy assignments. Details on that placement model are in the landing zone overview’s architecture section and the management groups design area.

Management groups themselves are straightforward once you internalize the inheritance rule: policies, RBAC, and locks assigned at a parent management group flow down to every child group and subscription. Our lab tree, after two failed drafts, looks like this: tenant root → Online (platform: identity, connectivity, management, security subscriptions) → under a workload management group named SAP, we keep SAP-DEV, SAP-TEST, and SAP-PRD as separate children, each holding the relevant SAP subscriptions. Keeping production under its own management group child is what makes “deny by default in prod, relaxed in dev” a two-click policy assignment instead of an exception spreadsheet.

The SAP Construction Set: Six Design Areas

Here is where we had to do archaeology. The Cloud Adoption Framework once shipped a dedicated SAP scenario page describing an “SAP on Azure construction set” of six design areas for an enterprise-scale landing zone: identity and access, network topology and connectivity, management and monitoring, business continuity and disaster recovery, security/governance/compliance, and platform automation and DevOps. Those pages are now retired from the live English site — requesting them today redirects to the generic landing zone overview — so we read the last archived revision from the docs repository on GitHub, e.g. the enterprise-scale landing zone page. The six-area framing matches what the generic framework’s governance design area recommends for any regulated workload, which is why we still organize our design docs around those six headings. Two of the archived SAP-specific recommendations we adopted verbatim: run at least two SAP management groups so production and non-production get distinct controls, and keep the core SAP platform in dedicated subscriptions.

How We Slice Subscriptions

Combining the archived SAP guidance with the current subscription design area, our subscription map is:

• Platform subscriptions, not combined. The design area is blunt: establish dedicated management, security, connectivity, and identity subscriptions and “do not combine platform responsibilities into a single subscription,” because each one gets different policies, role assignments, and billing.
• A control-plane subscription for SAP automation. The SAP Deployment Automation Framework planning doc tells you to deploy the control plane in a hub subscription of its own, hosting the deployer VMs, the Key Vault holding deployer service principals, an outbound Azure Firewall, Azure Bastion, and a config web app.
• One subscription per SAP environment, sometimes more. The same doc recommends hosting dev and prod systems in dedicated spoke subscriptions with their own virtual networks — that isolation is “both a security boundary and clear separation of duties,” letting Basis teams deploy workload zones while platform engineers own the control plane. When one environment needs multiple networks, the naming pattern splits on the logical VNet name: DEV-WEEU-SAP01-INFRASTRUCTURE and DEV-WEEU-SAP02-INFRASTRUCTURE are two dev spokes, not a typo.
• Fewer subscriptions than you think for regions and DR. Subscriptions are global logical containers, so the design area says you do not need one per region, and for a primary-plus-secondary BCDR pair that isn’t independently managed, the same subscription across regions is the documented recommendation. Active-active landscapes with different lifecycles get their own subscriptions.

One warning from hard experience: every dedicated spoke subscription eats into your account’s subscription count, and the defaults are not generous — subscription limits per tenant and per account are a real gating item on the EA/agreement level, so we requested a quota increase before creating the sixth spoke.

Governance That Actually Sticks

Governance in a landing zone is four mechanisms, and we assign each to the right scope:

• Azure Policy at management-group scope. Assignments inherit downward, so allowed-regions, tagging-for-enforcement, and SKU restrictions for dev hang off the management groups, not individual subscriptions — the inheritance model is documented in the management groups overview and the Azure Policy overview. The archived SAP security, governance, and compliance page additionally recommended excluding SAP database servers from automatic endpoint-protection policy installs, a detail we nearly learned the painful way during a HANA storage-layer test.
• RBAC at subscription and resource-group scope. Azure RBAC is how we separate the Basis team (deploy SAP VMs in workload-zone resource groups) from the network team (own the hub, cannot deploy SAP) from the finance folks (read-only + cost export). The archived SAP page described exactly this custom-role split on spokes; today the same spirit is built into Azure Center for SAP solutions’ three built-in roles — administrator, reader, and the service role used by its managed identity.
• Resource locks on production. The archived guidance put a CanNotDelete lock on production SAP resource groups, removable only by break-glass admins. Cheap, boring, effective.
• Cost as a guardrail, not a report. The subscription design area recommends shutdown schedules for non-production workloads, and the SAP-specific version of that is scheduling dev sandboxes (our lab’s runs 08:00–18:00 via SAP Solution Manager jobs against the Azure connector). Budget alerts live at the management-group level per environment.

What Tripped Us Up

• The retired SAP CAF pages. Half our search results pointed to SAP-specific enterprise-scale landing zone docs that now 302 to the generic page. Nothing officially documented replaces their SAP-specific checklists one-for-one; the live SAP on Azure overview and the choose-services-by-scenario guide cover services, not landing zones. We cite the GitHub archive above rather than pretend the retired pages exist.
• The User Access Administrator gotcha. A service principal with only Contributor cannot grant permissions to what it deploys. The DAF planning doc is explicit that automation identities also need User Access Administrator, and our first control-plane deployment failed for two days before we found that line.
• A stale Key Vault claim. The 2021 archived SAP page states flatly that SAP HANA was not supported with Azure Key Vault integration. We could not verify whether that restriction still holds — the governing SAP note lives behind a login at launchpad.support.sap.com, and the public SAP help area on virtualization questions for Azure is a JavaScript app that resists scraping. So: not officially documented, in our search. We treat OS/key-vault integration questions as a support-ticket topic, not a blog-fact topic.
• Naming is governance. The DAF default naming ([ENVIRONMENT]-[REGIONCODE]-[NETWORK]-INFRASTRUCTURE) is documented in the plan-deployment page, and fighting the framework’s convention after you have deployed anything is miserable. Decide it in the review meeting, not in the Terraform state.

Here are the two commands from that planning doc, verbatim, that finally let the framework’s own deployments succeed for us:

az ad sp create-for-rbac --role="Contributor" \
  --scopes="/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e" \
  --name="DEV-Deployment-Account"

az role assignment create \
  --assignee <your-application-ID> \
  --role "User Access Administrator" \
  --scope /subscriptions/<your-subscription-ID>/resourceGroups/<your-resource-group-name>

Automating the Boring Parts with the Deployment Automation Framework

Once subscriptions and policy scopes are agreed, the SAP Deployment Automation Framework is Microsoft’s open-source, Terraform-and-Ansible answer to building the SAP part of the landing zone repeatably — the scenario guide recommends it precisely when you need to “provision multiple SAP environments repeatedly.” The deploy sequence is always the same three phases: control plane, then workload zone, then SAP system(s). Each region hosts the deployment infrastructure, a SAP library resource group (installation media, BoM files, Terraform state storage, optional private DNS), and one or more workload zones. A trimmed version of the control-plane config we actually used, from the planning doc:

environment = "MGMT"
location = "westeurope"
management_network_logical_name = "DEP01"
management_network_address_space = "10.170.20.0/24"
management_subnet_address_prefix = "10.170.20.64/28"
firewall_deployment = true
management_firewall_subnet_address_prefix = "10.170.20.0/26"
bastion_deployment = true
management_bastion_subnet_address_prefix = "10.170.20.128/26"
use_webapp = true
webapp_subnet_address_prefix = "10.170.20.192/27"
deployer_assign_subscription_permissions = true
deployer_count = 2

Two repo notes from the same doc: treat Azure/sap-automation as read-only library code, and clone Azure/sap-automation-bootstrap to become your main repo, because your customized tfvars and pipeline definitions live there. If you would rather skip DIY orchestration entirely, our colleagues building SAP BTP with Azure OpenAI went straight to portal-driven deployment, and below is the middle path.

One System Instead of a Landscape: Azure Center for SAP Solutions

If you are deploying a single supported SAP system rather than an estate, Azure Center for SAP solutions gives you guided infrastructure deployment plus a Virtual Instance for SAP solutions (VIS) resource that represents the whole SAP system as one Azure object — health, start/stop, and SAP-aware operations included. From a governance point of view it is attractive precisely because it bakes in the separation of duties: the RBAC model above is Microsoft-managed built-in roles at the resource scope, and existing VM-built systems can be registered into ACSS afterward. Pair it with Azure Monitor for SAP solutions for the telemetry layer. The scenario chooser page spells out the decision cleanly: ACSS for an Azure-native single-system experience, the automation framework for repeating environments, and a typical production landscape uses several services side by side.

What This Guide Does Not Cover

Being honest about the shape of our knowledge feels important for a flagship page like this. We do not cover: the full network topology design (hub-and-spoke vs. virtual WAN, ExpressRoute circuits, and private endpoints are the framework’s own network design area, and the specifics change with every SAP transport size); VM sizing and storage SKU selection for HANA (that is the deployment tutorial in Next steps); security hardening baselines and Sentinel integration depth; RISE with SAP tenant boundaries, where Microsoft’s responsibility split differs from the self-managed model described here; and anything about running SAP Joule alongside Microsoft 365 Copilot. We also did not test every policy combination in this post — the tagging and SKU policies are ours, the role splits mirror the docs, and anything dated 2021 comes from an archive, labeled as such above.

FAQ

Does every SAP environment really need its own subscription?

Not every environment — every environment boundary you govern differently. The framework’s subscription design area recommends separate subscriptions for scale, isolation, and distinct policy scopes, and the DAF docs put dev and prod in dedicated spokes with their own VNets. Test and dev can share a subscription if they share policy requirements; production should not share with anything.

Where do SAP subscriptions sit in the management group tree?

Under the workload landing zones area of the platform hierarchy, typically beneath the Online (or Corp/Local) management group so they inherit platform policy. We keep a dedicated SAP branch with dev/test/prod children so SAP-scoped policies do not leak into non-SAP workloads, following the archived SAP CAF recommendation to run at least two SAP management groups for production versus non-production controls.

Can we move an existing SAP subscription into the landing zone later?

Yes — moving subscriptions between management groups is a documented, non-destructive operation in the management groups overview, and policy and RBAC inheritance start applying immediately at the new scope. What isn’t officially documented as painless is remediation: existing non-compliant resources need policy remediation tasks or exceptions, so plan a compliance report before and after the move.

Should we use the automation framework or Azure Center for SAP solutions?

Use the deployment automation framework when you are building landing-zone-grade repeatable infrastructure for multiple systems (it also creates the control plane, workload zones, and library RGs); use Azure Center for SAP solutions for SAP-aware management of individual supported systems, including registering systems someone else built. They are complementary, per the scenario guide.

References

1. Azure landing zone overview — Cloud Adoption Framework: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/
2. Subscription considerations and recommendations — CAF landing zone design area: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-subscriptions
3. Management group design area — CAF: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/resource-org-management-groups
4. Governance and enterprise management design area — CAF: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/governance
5. Network topology and connectivity design area — CAF: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/design-area/network-topology-and-connectivity
6. What are Azure management groups?: https://learn.microsoft.com/en-us/azure/governance/management-groups/overview
7. What is Azure Policy?: https://learn.microsoft.com/en-us/azure/governance/policy/overview
8. What is Azure RBAC?: https://learn.microsoft.com/en-us/azure/role-based-access-control/overview
9. Azure subscription and service limits, quotas, and constraints: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits
10. Plan your deployment — SAP Deployment Automation Framework: https://learn.microsoft.com/en-us/azure/sap/automation/plan-deployment
11. SAP Deployment Automation Framework overview: https://learn.microsoft.com/en-us/azure/sap/automation/deployment-framework
12. Choose Azure services for SAP scenarios: https://learn.microsoft.com/en-us/azure/sap/choose-sap-services-by-scenario
13. Azure Center for SAP solutions overview: https://learn.microsoft.com/en-us/azure/sap/center-sap-solutions/overview
14. Azure RBAC for Azure Center for SAP solutions: https://learn.microsoft.com/en-us/azure/sap/center-sap-solutions/manage-with-azure-rbac
15. What SAP software is supported for Azure deployments: https://learn.microsoft.com/en-us/azure/sap/workloads/supported-product-on-azure
16. SAP certifications and configurations on Microsoft Azure: https://learn.microsoft.com/en-us/azure/sap/workloads/certifications
17. SAP support note 1928533 (login required): https://launchpad.support.sap.com/#/notes/1928533
18. SAP Help — Frequently Asked Questions: Microsoft Azure: https://help.sap.com/docs/SUPPORT_CONTENT/virtualization/3362185765.html?locale=en-US
19. Archived CAF SAP enterprise-scale landing zone (commit-pinned): https://raw.githubusercontent.com/MicrosoftDocs/cloud-adoption-framework/f5d35f2ea32806ea1e34418a65f034d0a23cec0b/docs/scenarios/sap/enterprise-scale-landing-zone.md
20. Archived CAF SAP security, governance, and compliance (commit-pinned): https://raw.githubusercontent.com/MicrosoftDocs/cloud-adoption-framework/f5d35f2ea32806ea1e34418a65f034d0a23cec0b/docs/scenarios/sap/eslz-security-governance-and-compliance.md
21. Archived CAF SAP ready considerations (commit-pinned): https://raw.githubusercontent.com/MicrosoftDocs/cloud-adoption-framework/f5d35f2ea32806ea1e34418a65f034d0a23cec0b/docs/scenarios/sap/ready.md
22. Azure/sap-automation on GitHub: https://github.com/Azure/sap-automation
23. Azure/sap-automation-bootstrap on GitHub: https://github.com/Azure/sap-automation-bootstrap

Next steps

With subscriptions and policy scopes agreed, the compute decisions come next — the deployment notes linked earlier land you inside the workload zones this post carves out. Once the platform is governed, the AI-integration experiments get safe sandboxes: see how we wired SAP Joule to Microsoft 365 Copilot on top of exactly this kind of setup. More field notes from our Azure+SAP lab live in the cloud category.

All statements above cite Microsoft Learn or SAP Help pages we fetched on 2026-11-08; archived GitHub references are commit-pinned. Quota numbers and retired-page behavior can change, so re-verify before your design review.