Subscription Models and Quotas

Module: Migrate SAP Workloads to Azure

Section: Target Infrastructure Requirements

Lesson: Subscription Models and Quotas

Introduction: The Foundation of SAP on Azure

Migrating SAP workloads to the cloud is a significant undertaking that requires more than just moving data from an on-premises data center to a virtual machine. At the heart of a successful migration lies the Azure subscription structure and the management of resource quotas. Many SAP projects experience delays or performance bottlenecks not because of technical errors in the OS or database layer, but because the underlying administrative environment—the subscription—was not correctly architected from the beginning.

An Azure subscription serves as the logical container for your SAP resources, including virtual machines, storage accounts, and virtual networks. It is the primary boundary for billing, access control, and service limits. When you run enterprise-grade SAP systems like SAP S/4HANA or BW/4HANA, you are dealing with high-memory, high-IOPS demands that can easily hit default platform limits. Understanding how subscriptions function and how to proactively manage quotas is essential for maintaining the uptime and scalability required by SAP environments.

This lesson explores the architectural considerations for subscription design, the technical nuances of Azure resource quotas, and the operational workflows you must implement to ensure your SAP landscape remains stable. By mastering these concepts, you transition from being a reactive administrator to a proactive cloud architect who understands exactly how to provision the necessary headroom for critical business processes.

Understanding Azure Subscription Models

In an Azure environment, a subscription is a subscription to a service, but it also acts as an organizational and financial unit. For SAP workloads, the subscription model determines how you manage your production, quality, and development environments. You have several ways to structure these, depending on your company's size and the complexity of your SAP landscape.

The Single Subscription Approach

For smaller organizations or early-stage migrations, a single subscription might suffice. In this model, you use Resource Groups to isolate the different stages of the SAP lifecycle (e.g., Sandbox, Dev, Quality, Prod). While this is simple to manage, it often leads to a "noisy neighbor" effect where development activity might inadvertently hit resource quotas meant for production. It also complicates the application of granular billing policies if different departments own different SAP modules.

The Multi-Subscription Approach

Most enterprise SAP customers adopt a multi-subscription model. This involves creating separate subscriptions for specific environments or business units. For example, you might have one subscription for "SAP Production" and another for "SAP Non-Production." This separation provides several strategic advantages:

• Billing Clarity: You can easily track the cost of your production environment separately from sandbox or testing environments.
• Quota Isolation: Resource limits are applied at the subscription level. If your development team accidentally triggers a limit, your production environment remains untouched.
• Administrative Control: You can assign different levels of access. Your production subscription might be restricted to a small team of senior admins, while the development subscription is open to a wider group of technical consultants.

Callout: The Management Group Hierarchy Azure Management Groups provide a layer of governance above subscriptions. You should organize your subscriptions under a Management Group hierarchy to apply policies (such as Azure Policy) consistently. For SAP, this is critical to ensure that all virtual machines follow naming conventions and security standards, regardless of which subscription they reside in.

Navigating Azure Quotas and Limits

Azure imposes quotas to protect the platform from unpredictable resource consumption and to ensure fair access for all customers. For SAP workloads, these quotas are not just theoretical; they are hard boundaries that can halt a project if not addressed.

Types of Quotas

1. vCPU Quotas: This is the most common constraint for SAP. Every Azure region has a limit on the number of vCPUs you can deploy. If you are deploying M-series or E-series virtual machines—which are common for SAP—you will likely hit these limits quickly.
2. Network Bandwidth and IOPS: While less common as a hard "quota," storage throughput and network limits are effectively quotas on your system's performance. Exceeding these results in latency spikes in your SAP GUI or batch processing delays.
3. Public IP Addresses: If your SAP landscape requires external connectivity or specific VPN setups, you may run out of available public IP addresses within a subscription.
4. Resource Group Limits: While high, there is a maximum number of resources allowed per resource group. A large SAP implementation with hundreds of disks and network interfaces should be architected to span multiple resource groups.

Identifying Current Usage

Before you start your migration, you must audit your current limits. You can do this through the Azure Portal or via the Azure CLI.

Example: Checking vCPU usage via Azure CLI

# List the current usage for a specific region
az vm list-usage --location "eastus" --output table

This command returns a table showing your current consumption versus the limit for various VM families. If you see that your "Standard M-series" usage is close to the limit, you must request an increase before you start deploying your production SAP HANA database nodes.

Note: Always request quota increases at least 2-3 weeks before your planned deployment. While many increases are automated, some requests require manual review by Microsoft support, which can take time.

Step-by-Step: Requesting a Quota Increase

If you find that your planned SAP architecture exceeds the default Azure quotas, you must request an increase. Follow these steps to ensure the request is handled accurately.

Step 1: Gather Requirements

Before opening a support ticket, calculate the total number of vCPUs required for your entire SAP landscape. Include the production, QA, and development environments, and add a 20% buffer for future growth or disaster recovery testing.

Step 2: Use the Azure Portal

Navigate to the "Quotas" blade in the Azure Portal. You can find this by searching for "Quotas" in the global search bar.

Step 3: Filter by Region and Family

Select the region where your SAP infrastructure will reside (e.g., East US) and filter by the specific VM family you intend to use (e.g., M-series).

Step 4: Submit the Request

Select the specific quota you need to increase, click "Request Increase," and fill in the required fields. Provide a business justification. A strong justification looks like this: "We are migrating a mission-critical SAP S/4HANA workload. We require 128 additional vCPUs in the M-series family to support the production database server and application server cluster."

Step 5: Track the Ticket

Monitor the status of your request in the "Help + Support" section. Do not consider the quota increased until you receive a confirmation email or see the updated number in the Quotas blade.

Designing for Resilience: Best Practices

To avoid common pitfalls in subscription and quota management, you should adopt a design-first mentality. Here are the industry-standard practices for SAP on Azure.

1. The Hub-and-Spoke Network Model

While this is a networking concept, it impacts your subscription design. By using a Hub-and-Spoke model, you can centralize your network services (Firewalls, ExpressRoute gateways) in a "Hub" subscription and isolate your SAP workloads in "Spoke" subscriptions. This keeps the resource count in your SAP subscriptions lower and makes it easier to manage quotas.

2. Infrastructure as Code (IaC)

Do not deploy your SAP infrastructure manually. Use Terraform or Bicep to define your environment. IaC allows you to test your deployment in a sandbox and identify quota constraints early. If your Terraform script fails during deployment, it will give you a clear error message regarding which quota was hit, allowing you to troubleshoot immediately.

3. Proactive Monitoring

Use Azure Monitor and Azure Advisor to track your resource utilization. Set up alerts for when you reach 80% of a quota limit. This gives you ample time to request an increase before your developers or automated processes are blocked.

Warning: Never assume that "default" quotas are sufficient. SAP HANA systems often require specific high-memory VM sizes that have very low default quotas in new subscriptions. Always verify these before starting your migration.

4. Tagging and Cost Management

Since subscriptions are billing boundaries, you must implement a robust tagging strategy. Every resource associated with an SAP workload should have tags like Environment: Production, SAPSystemID: PRD, and CostCenter: 1234. This allows you to slice your billing data effectively, even if you are sharing a subscription across multiple projects.

Common Pitfalls and How to Avoid Them

Even experienced architects can fall into traps when managing Azure environments. Here are the most frequent mistakes made during SAP migrations.

Miscalculating IOPS Requirements

A common mistake is focusing only on vCPU and RAM quotas while ignoring storage IOPS. SAP HANA is extremely sensitive to storage latency and throughput. Azure provides different storage tiers (Standard HDD, Premium SSD, Ultra Disk). Each disk type has its own limits. If you provision a large number of Premium SSDs, you might hit the "Subscription-level storage throughput" limit, which is not always obvious in the portal.

Forgetting Disaster Recovery (DR)

Many teams plan their production environment but forget that their DR site also needs sufficient quota. If you are planning to replicate your SAP data to a secondary region, ensure that the DR subscription has the same quota headroom as your primary subscription. If a failover occurs and you hit a quota limit in the secondary region, your entire SAP landscape will be offline, leading to a major business continuity incident.

The "Sandbox" Trap

Developers often start in a sandbox subscription without considering the eventual migration to production. When the time comes to move, they realize they have built an architecture that isn't compatible with the security or subscription limits of the production environment. Always design your sandbox using the same enterprise standards—including networking and naming conventions—that you plan to use for production.

Advanced Quota Management: The Role of Azure Service Limits

It is vital to distinguish between "quotas" and "service limits." Quotas are adjustable limits that you can request to increase. Service limits, however, are hard constraints set by the Azure platform architecture. For example, the number of virtual networks you can have in a region or the maximum size of a specific disk type is a service limit.

When planning your SAP migration, you must consult the official Azure documentation for the specific VM series you are using (e.g., Mv2-series). These documents list the maximum number of data disks, network interfaces, and IOPS per VM. These are not limits you can "request" to increase; they are physical constraints of the hardware. If your SAP system requires more disks than the VM supports, you must reconsider your architecture, perhaps by moving to a larger VM size or utilizing Azure NetApp Files for higher storage throughput.

Managing Limits with Azure NetApp Files

For very large SAP HANA databases, the standard managed disk limits might not be enough. Azure NetApp Files (ANF) is a popular solution for SAP workloads. It provides high-performance file shares that bypass many of the standard disk-per-VM limitations. When using ANF, you don't worry about disk quotas; instead, you manage the "Capacity Pool" and "Volume" quotas within the NetApp service.

Automating Quota Monitoring

If you manage a large SAP landscape, manual monitoring is not enough. You can use Azure Resource Graph to query your entire tenant and identify resources that are nearing their limits.

Example: Querying Resource Usage

// Kusto query to find VMs nearing their disk limits
Resources
| where type == "microsoft.compute/virtualmachines"
| extend diskCount = array_length(properties.storageProfile.dataDisks)
| project name, diskCount, resourceGroup
| where diskCount > 10

By running such queries regularly, you can visualize your resource consumption. Integrating this with a dashboard (like Azure Workbooks) allows your operations team to see potential bottlenecks before they affect the SAP users.

Integrating Subscription Management into the Migration Lifecycle

The migration of an SAP workload is generally divided into phases: Assessment, Mobilization, Migration, and Optimization. Subscription and quota management must be integrated into every phase.

Assessment Phase

During the assessment, you are not just looking at the size of your current SAP databases. You are looking at the "Azure footprint." Ask yourself:

• How many subscriptions do we need?
• Do we have an Enterprise Agreement (EA) that allows us to create these subscriptions easily?
• What are the region-specific quotas in our target Azure data center?

Mobilization Phase

This is where you set up your landing zone. A "Landing Zone" is the environment where your SAP workloads will live. It includes the subscription structure, the network topology, and the identity management (Active Directory/Entra ID). If your Landing Zone lacks the correct quota configuration, your migration will be stalled at the first step.

Migration Phase

As you perform the "Lift and Shift" or "Re-platforming," you will be deploying resources in bulk. This is the time when you are most likely to hit quota limits. Ensure that you have a "Cloud Center of Excellence" (CCoE) team available to approve quota increase requests in real-time.

Optimization Phase

After the migration, you might realize that you over-provisioned. You can now lower your quotas to reduce costs or consolidate resources. This is also the time to refine your tagging and ensure that the cost of each SAP system is accurately reported to the business owners.

The Human Element: Communication and Process

Technology is only half the battle. Many SAP migration projects fail due to poor communication between the SAP Basis team and the Azure Infrastructure team.

The SAP Basis team understands the memory and CPU requirements of the HANA database, but they may not understand how Azure subscriptions work. Conversely, the Azure team understands the cloud platform but may not understand that a 30-minute outage during a quota increase could disrupt a critical month-end financial closing in SAP.

Establishing a Shared Workflow

1. Define Roles: Clearly state who has the permission to request quota increases.
2. Regular Syncs: Hold weekly meetings between SAP Basis and Azure Infrastructure leads to discuss upcoming deployments.
3. Documentation: Keep a central document that lists all current quotas and the "buffer" remaining for each VM family.
4. Escalation Path: If a quota request is denied or delayed by Microsoft, know exactly who to contact (e.g., your Microsoft Customer Success Manager or Technical Account Manager).

Summary of Key Takeaways

To ensure your SAP on Azure migration is successful, keep these foundational principles in mind:

• Subscriptions as Boundaries: Use subscriptions as a way to isolate your SAP environments (Prod, QA, Dev) to ensure billing clarity and resource safety.
• Proactive Quota Management: Always check your default vCPU and storage quotas in your target region before starting any deployment. Treat quota increases as a critical path item in your project schedule.
• Architecture Over Limits: Understand that some limits are physical (service limits) and cannot be changed. Design your SAP architecture to fit within these constraints by choosing the right VM series and storage solutions.
• IaC and Automation: Leverage Infrastructure as Code to make deployments repeatable and to identify quota issues early in the testing cycle.
• Governance is Essential: Use Management Groups, Tags, and Azure Policy to maintain control over your subscription landscape, ensuring that your SAP systems remain compliant and cost-effective.
• Communication is Key: Bridge the gap between your SAP Basis experts and your Azure infrastructure team to ensure that technical requirements are met without impacting business operations.
• Continuous Monitoring: Use Kusto queries and Azure Workbooks to maintain visibility into your resource usage, preventing outages before they happen.

By following these practices, you establish a solid foundation for your SAP environment in Azure. The subscription model acts as your organizational map, while your quota management strategy ensures you always have the necessary "room to breathe" to keep your business-critical SAP applications running smoothly. Remember, the goal isn't just to move to the cloud—it's to thrive there.