Management Hierarchy Design

Module: Migrate SAP Workloads to Azure

Section: Azure Environment Design

Lesson Title: Management Hierarchy Design

Introduction: Why Management Hierarchy Matters for SAP on Azure

When you decide to migrate mission-critical SAP workloads to Microsoft Azure, the technical migration of the database and application servers is only half the battle. The most significant challenge often lies in the foundational structure of your cloud environment. A well-thought-out management hierarchy acts as the skeleton of your entire Azure footprint. It dictates how your organization manages costs, enforces security policies, organizes resources, and maintains compliance across the lifecycle of your SAP systems.

Without a structured hierarchy, you risk creating a "Wild West" environment where SAP production systems, sandbox environments, and development clusters are mixed in ways that make cost tracking, access control, and auditing nearly impossible. For large-scale SAP deployments, which often involve complex landscapes like ECC, S/4HANA, BW/4HANA, and various integration layers, the management hierarchy must be designed to reflect your organizational structure, operational models, and geographical requirements.

This lesson explores the core components of the Azure management hierarchy—Management Groups, Subscriptions, Resource Groups, and Tags—and shows you how to design them specifically for the unique demands of SAP landscapes. By the end of this guide, you will understand how to build a scalable, secure, and manageable environment that supports your SAP workloads today and scales as your business grows tomorrow.

The Components of the Azure Management Hierarchy

Azure provides a multi-level structure that allows for the logical grouping of resources. Understanding the relationship between these levels is essential for effective governance.

1. Management Groups

Management Groups are the highest level of organization in Azure. They provide a scope above Subscriptions, allowing you to apply governance policies and access controls across multiple subscriptions simultaneously. If you have multiple SAP landscapes (e.g., one for North America and one for Europe), you can use Management Groups to ensure that security policies are applied consistently to both.

2. Subscriptions

A subscription is the unit of billing and the boundary for service limits. In the context of SAP, subscriptions are often used to isolate production environments from non-production environments. This separation is critical for financial reporting, as it allows leadership to clearly see the infrastructure costs associated with maintaining the "live" production SAP environment versus development and testing phases.

3. Resource Groups

Resource Groups are containers that hold related resources for an Azure solution. For an SAP system, a Resource Group typically contains the Virtual Machines, Managed Disks, Virtual Network Interfaces, and Load Balancers associated with a single SAP instance (such as a Production SAP S/4HANA server). They serve as the functional boundary for lifecycle management.

4. Tags

Tags are metadata key-value pairs that you apply to resources. While not a "container" in the same sense as the others, tags are the glue that holds your reporting together. You might tag a resource with Environment: Production, SAP-System-ID: PRD, or Cost-Center: 12345. Without a strict tagging policy, your management hierarchy will fail at the reporting level.

Callout: Hierarchy vs. Topology It is important to distinguish between the Management Hierarchy and the Network Topology. The Management Hierarchy (Management Groups/Subscriptions) governs who can do what and how much it costs. The Network Topology (VNets/Subnets) governs how the servers talk to each other. While they should align, they serve different masters: governance versus connectivity.

Designing the Hierarchy for SAP Workloads

When designing the structure for SAP, you must balance simplicity with the need for strict isolation. A common mistake is creating too many subscriptions, which leads to "subscription sprawl" and administrative overhead. Conversely, stuffing all SAP landscapes into a single subscription makes it impossible to apply granular access controls or limit the blast radius of a potential configuration error.

The Recommended Structure

For most mid-to-large enterprises, a tiered approach is the industry standard:

• Root Management Group: The parent of all Azure activity.
• SAP Platform Management Group: A dedicated child group for all SAP-related subscriptions.
• Subscription Tier:
  • Prod Subscription: Contains all live, customer-facing SAP systems.
  • Non-Prod Subscription: Contains development, quality assurance, and sandboxes.
  • Shared Services Subscription: Contains supporting infrastructure like SAP Router, Jumpboxes, or centralized monitoring tools.

Why Separate Non-Prod from Prod?

Separating these environments at the subscription level is not just about billing. It is about security and operational safety. You can apply a policy to the "Prod" subscription that restricts the ability to delete resources or perform automated shutdowns, whereas the "Non-Prod" subscription can have more permissive policies to allow developers to experiment and rebuild environments as needed.

Implementing Resource Groups: The SAP Instance Model

Within your subscriptions, you need a consistent strategy for Resource Groups. For SAP, the most effective approach is to group resources by the SAP System ID (SID).

Consider an SAP S/4HANA system with the SID P01. All components of this system—the database server, the application server, the disk storage, and the network interfaces—should reside in a single Resource Group named RG-SAP-P01-PROD.

Benefits of the SID-based Resource Group strategy:

• Lifecycle Management: If you need to decommission an old SAP instance, you can delete the entire Resource Group, and you can be confident that you are not leaving "orphaned" disks or network interfaces behind.
• Access Control (RBAC): You can grant the SAP Basis team "Contributor" access to the RG-SAP-P01-PROD group while restricting their access to the underlying virtual network or the subscription-level settings.
• Cost Transparency: When you look at the Azure Cost Management portal, you can filter by the Resource Group name to see exactly how much that specific SAP system is costing the business on a monthly basis.

Tip: Managing Resource Limits Azure has limits on the number of resources per Resource Group. While these limits are quite high (800 resources per group), a massive SAP landscape with many disks might approach this. Always plan for the number of managed disks, as each SAP server usually requires several data and log disks.

Tagging Strategies: The Foundation of Visibility

A hierarchy is only as good as the metadata attached to its resources. In a large enterprise, you might have hundreds of virtual machines. Without a robust tagging policy, you will struggle to identify which VMs belong to which project, department, or business unit.

Recommended Tagging Schema for SAP

Implement a mandatory tagging policy using Azure Policy. Every resource associated with an SAP deployment should have at least the following tags:

• Owner: The person or team responsible for the system.
• CostCenter: The financial code for chargebacks.
• Environment: (e.g., PROD, QA, DEV, SANDBOX).
• SAP-SID: The three-character SAP System ID.
• SAP-Component: (e.g., AppServer, DBServer, CentralServices).
• Patch-Schedule: (e.g., Weekend-Morning, Weekday-Evening).

Enforcing Tags with Azure Policy

You can use Azure Policy to prevent the creation of any resource that does not have these tags. This is a common industry practice to ensure that your reporting is never broken by human error.

Example: Azure Policy Definition (JSON)

The following snippet shows an Azure Policy rule that denies the creation of a resource if it lacks the SAP-SID tag.

{
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "tags['SAP-SID']",
          "exists": "false"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Explanation of the code: This policy evaluates every request to create a resource. If the resource does not contain a tag named SAP-SID, the effect is set to deny, meaning the resource creation will fail. This forces administrators to provide the required metadata before they can deploy any infrastructure.

Step-by-Step: Setting Up Your Hierarchy

If you are starting from scratch, follow these steps to build your Azure environment for SAP.

Step 1: Establish the Management Group Structure

1. Navigate to the Azure Portal and search for "Management Groups."
2. Create a new Management Group named "SAP-Workloads."
3. Move your intended SAP subscriptions into this group. This allows you to apply policies (like the tagging policy mentioned above) to all SAP subscriptions at once.

Step 2: Define the Subscriptions

1. Create at least three subscriptions: SAP-Production, SAP-NonProduction, and SAP-SharedServices.
2. Assign the appropriate budgets to these subscriptions. This ensures that you receive alerts if the "Non-Production" environment exceeds its monthly budget.

Step 3: Standardize Resource Group Naming

1. Adopt a naming convention, such as RG-[Project]-[Environment]-[Region].
2. For example, RG-S4HANA-PROD-EastUS is descriptive and easy to identify.
3. Ensure that all team members follow this convention; inconsistent naming is the primary cause of confusion during incident response.

Step 4: Apply RBAC (Role-Based Access Control)

1. Assign the "SAP Basis Administrator" role at the Resource Group level rather than the Subscription level.
2. This limits the scope of what an administrator can impact, reducing the chance of an accidental outage to multiple systems.

Avoiding Common Pitfalls

Even with a plan, teams often fall into traps that cause long-term pain. Here are the most frequent mistakes:

1. The "Single Subscription" Trap

Many organizations start by putting everything in one subscription to "keep it simple." As the project grows, they realize they cannot distinguish costs between production and sandbox, and they cannot apply different security policies. Avoid this. Start with at least two subscriptions (Prod/Non-Prod) from day one.

2. Manual Resource Deployment

Deploying SAP servers via the Azure Portal GUI is a recipe for disaster. It leads to configuration drift, where the production server is set up slightly differently than the quality assurance server. Use Infrastructure as Code (IaC). Use Terraform or Bicep templates to deploy your SAP infrastructure. This ensures that your hierarchy and resource settings are consistent across every single environment.

3. Ignoring Resource Limits

Azure has subscription-level limits on the number of vCPUs and the number of public IP addresses. In a large SAP migration, you may hit these limits quickly. Proactively request limit increases from Microsoft Support before you start your migration, rather than waiting for a deployment to fail during a critical project phase.

Callout: Infrastructure as Code (IaC) for SAP When using Terraform or Bicep, you can define your Resource Group hierarchy and tagging policies within the same template that deploys your Virtual Machines. This ensures that every resource is born with the correct tags and placed in the correct group, eliminating manual errors entirely.

Comparison: Traditional vs. Cloud-Native SAP Hierarchy

Best Practices for SAP on Azure

1. Implement Azure Blueprints

Azure Blueprints allow you to define a repeatable set of Azure resources that implement and adhere to your organization's standards, patterns, and requirements. For SAP, you can create a "blueprint" that automatically deploys the correct Resource Groups, tags, and RBAC roles whenever a new SAP environment is required.

2. Use Managed Identities

Avoid storing database passwords or service account credentials in your scripts. Use Azure Managed Identities for your virtual machines. This allows your SAP application servers to authenticate to other Azure services (like Key Vault or Storage Accounts) without ever needing to manage a password.

3. Centralized Logging and Monitoring

While your hierarchy separates resources, your monitoring should be centralized. Use an Azure Log Analytics Workspace to collect logs from all your SAP systems, regardless of which subscription they reside in. This provides a "single pane of glass" for troubleshooting performance issues across your entire landscape.

4. Network Isolation

Just as you isolate your production environment in a subscription, isolate your networking. Use a Hub-and-Spoke topology. The "Hub" contains your VPN/ExpressRoute gateway and firewall, while the "Spoke" contains your SAP application and database servers. This keeps the network management separate from the SAP application management.

Advanced: Designing for Multi-Region SAP Deployments

If your company operates globally, you might have SAP systems in the US, Europe, and Asia. Your management hierarchy should reflect this geographical distribution.

A common design for global organizations is:

• Management Group: Global-SAP
  • Management Group: US-SAP
    • Subscription: US-Prod
    • Subscription: US-NonProd
  • Management Group: EU-SAP
    • Subscription: EU-Prod
    • Subscription: EU-NonProd

This design allows you to apply regional policies—such as data residency requirements (GDPR in Europe)—to the EU-SAP management group without affecting your US operations.

Common Questions (FAQ)

Q: Can I change my hierarchy after I have deployed resources? A: Yes, you can move Resource Groups between subscriptions, and subscriptions between Management Groups. However, this can be complex if you have resources that rely on specific network IDs or hardcoded references. Plan your hierarchy early to avoid the need for large-scale migrations later.

Q: How many Resource Groups should I have? A: A good rule of thumb is one Resource Group per SAP system (SID). If an SAP system has a very complex architecture, you might consider one for the database tier and one for the application tier, but keep it as simple as possible to reduce management overhead.

Q: Do I need a separate subscription for my SAP Router? A: It is often best to keep shared infrastructure like SAP Routers, Jumpboxes, and backup vaults in a dedicated "Shared Services" subscription. This keeps your production subscriptions clean and focused purely on application and database workloads.

Key Takeaways

1. Hierarchy is Governance: The management hierarchy is the foundation for security, billing, and compliance. Design it before you migrate a single byte of data.
2. Separate Environments: Always isolate Production from Non-Production at the subscription level. This is the single most effective way to prevent accidental outages and manage costs.
3. Use SID-based Resource Groups: Grouping resources by the SAP System ID (SID) makes lifecycle management, auditing, and decommissioning much simpler.
4. Enforce Tagging: A resource without a tag is an invisible resource. Use Azure Policy to mandate tags like SAP-SID and Environment to ensure your cost and security reporting remains accurate.
5. Infrastructure as Code (IaC): Use tools like Terraform or Bicep to deploy your environment. Automation removes human error and ensures that your production and non-production environments are identical in configuration.
6. Plan for Growth: Azure has limits on resources per subscription. Design your hierarchy with scalability in mind, and request quota increases well in advance of your migration milestones.
7. Centralize Monitoring: While your hierarchy provides logical separation, your monitoring (Log Analytics) should be centralized to provide a holistic view of your SAP landscape's health.

By following these principles, you will create an Azure environment that is not only ready for your SAP migration but also easy to manage, secure, and cost-effective throughout the entire lifecycle of your systems. Designing the hierarchy is an investment in the long-term stability and success of your SAP-on-Azure journey.