Software Licensing Requirements

Lesson: Software Licensing Requirements for SAP on Azure

Introduction: Why Licensing Matters in the Cloud

When organizations decide to migrate their SAP workloads to Microsoft Azure, the conversation often begins with technical specifications like virtual machine (VM) families, storage throughput, and network latency. However, a significant portion of the total cost of ownership and the operational feasibility of the project depends on software licensing. Licensing is not merely a bureaucratic checkbox; it is a fundamental architectural constraint that dictates how you can deploy your SAP landscape, how you must report your usage, and how you manage your long-term cloud costs.

In the on-premises world, licensing was often tied to physical hardware—the number of CPU sockets or cores on a specific server rack. When you move to the cloud, the paradigm shifts to virtualized environments where hardware is abstracted. Misunderstanding these shifts can lead to significant compliance gaps, unexpected financial penalties during an audit, or the inability to run your SAP applications at the performance levels you require. This lesson will guide you through the complexities of SAP licensing in the Azure environment, ensuring you can build a compliant and cost-effective infrastructure.

1. The Core Licensing Models for SAP on Azure

To understand how to license SAP on Azure, you must first recognize that you are dealing with two distinct but overlapping layers of licensing: the SAP application layer and the underlying operating system (OS) and database layer.

SAP Application Licensing

SAP licenses are typically governed by the contract you have with SAP. Most SAP customers operate under a "Bring Your Own License" (BYOL) model. This means that your existing SAP licenses—whether they are based on user counts, revenue, or throughput—are generally portable to the cloud. However, you must verify your specific contract to ensure that "cloud usage" or "hosting" is permitted. SAP provides a specific document called the "Product Use Rights" (PUR) which outlines the conditions under which their software can be deployed in a third-party cloud environment.

Operating System and Database Licensing

The OS and database layer often present more complexity. For example, if you are running SAP on Windows Server or SQL Server, you need to determine if you are using your existing on-premises licenses or purchasing them through the Azure marketplace.

• Azure Hybrid Benefit (AHB): This is a critical program that allows you to use your existing on-premises Windows Server and SQL Server licenses with Software Assurance on Azure. By applying these licenses to your Azure VMs, you can significantly reduce the cost of your SAP deployment.
• Pay-As-You-Go (PAYG): In this model, the licensing cost is bundled into the hourly rate of the Azure VM. This is often the simplest approach for new deployments or temporary environments like sandboxes where you do not want to manage long-term license inventory.

Callout: Licensing Portability vs. Cloud-Native Pricing The fundamental distinction here is between 'Portability' and 'Cloud-Native.' Portability refers to taking your existing investment (on-premises licenses) and applying it to the cloud to save money. Cloud-Native pricing (PAYG) treats the software as a utility, where you pay only for what you consume, providing flexibility but potentially higher long-term costs.

2. Navigating SAP-Specific Licensing Constraints

SAP has specific requirements regarding the infrastructure upon which their software runs. They certify specific Azure VM SKUs for SAP workloads. This certification is not just about performance; it is a licensing requirement. If you run SAP HANA on a non-certified VM, you may find yourself in a position where SAP support will refuse to assist you because the environment is not supported.

SAP HANA Licensing Models

SAP HANA is unique because it is both a database and an application platform. You can license HANA in two main ways:

1. Subscription-based: You pay a recurring fee to SAP for the right to use HANA.
2. Perpetual-based: You have purchased the license outright and pay an annual maintenance fee (SAP Support).

When moving to Azure, you must ensure that your HANA license entitlement is sufficient for the amount of RAM you plan to deploy. Since HANA is an in-memory database, the primary metric for licensing is often the total amount of RAM allocated to the HANA instances across your landscape.

Operating System Support

SAP requires specific OS versions for different versions of the SAP NetWeaver stack or SAP HANA. When you migrate, you might be tempted to upgrade your OS to the latest version. However, you must cross-reference the SAP Product Availability Matrix (PAM) with the Azure VM support documentation. If you choose an OS version that is not supported by SAP on a specific Azure VM type, you are effectively operating outside of your licensing and support agreement.

3. Practical Implementation: Applying Azure Hybrid Benefit

The Azure Hybrid Benefit (AHB) is the most common way to optimize costs for SAP on Azure. Below is a step-by-step guide to applying this benefit to an existing virtual machine running Windows Server.

Step-by-Step: Enabling AHB via Azure CLI

If you have existing Windows Server licenses with Software Assurance, you can apply them to your Azure VMs to stop paying the "Windows Server" premium in the hourly VM rate.

Prerequisites:

• You must have an active Azure subscription.
• You must possess the necessary Windows Server licenses with active Software Assurance.

Execution:

1. Open your Azure CLI or use the Cloud Shell in the Azure Portal.
2. Identify the VM you wish to update.
3. Execute the following command to update the license type:

# Update an existing VM to use the Azure Hybrid Benefit for Windows Server
az vm update \
    --resource-group MySAPResourceGroup \
    --name MySAPAppServer \
    --license-type Windows_Server

Explanation of the command:

• az vm update: This is the base command for modifying VM properties.
• --resource-group: Specifies the location of your resources.
• --name: The specific VM instance.
• --license-type: Setting this to Windows_Server informs Azure that you are providing the license, and it will automatically adjust the billing to remove the OS cost from the hourly rate.

Warning: Audit Readiness When you switch to the Azure Hybrid Benefit, you are making a declaration that you own the necessary licenses. You must keep a record of your license entitlement (e.g., your Microsoft Volume Licensing portal export) in case of an audit. Failure to provide proof of license during an audit can result in back-billing and potential fines.

4. Database Licensing: SQL Server and SAP

SAP on SQL Server is a common deployment pattern. Licensing SQL Server for SAP on Azure requires careful attention to the "core-based" licensing model. Microsoft licenses SQL Server based on the number of virtual cores (vCPUs) assigned to the VM.

Calculating Core Requirements

If you are using the Azure Hybrid Benefit for SQL Server, you must license the number of vCPUs assigned to your VM.

• Minimums: You must license at least 4 cores per VM.
• Hyper-Threading: Azure vCPUs are generally considered equivalent to physical cores for the purposes of SQL Server licensing.

Best Practices for SQL Server Licensing

• Consolidation: If you have multiple smaller SAP instances, consider running them on a single large VM if your architecture allows, as this can sometimes simplify license management.
• High Availability (HA): For passive SQL Server nodes in an Always On Availability Group, you may be eligible for free passive instances if you have Software Assurance. Always review the "SQL Server Licensing Guide" specific to Azure to confirm current rules, as these can change.

5. Common Pitfalls and How to Avoid Them

Even experienced architects encounter issues when managing SAP licenses in the cloud. Below are the most frequent mistakes observed in large-scale migrations.

Pitfall 1: Ignoring the "Non-Production" vs. "Production" Distinction

Many organizations mistakenly assume that licensing for development and quality assurance (QA) environments is the same as production. Often, you can use lower-cost licensing or developer editions for non-production environments. However, you must ensure that these environments are logically separated. Using a developer license in a production environment is a major compliance violation.

Pitfall 2: Over-provisioning vCPUs

Because SQL Server is licensed by the core, every vCPU you add to a VM increases your license requirement. If you provision an 8-vCPU VM for an SAP server that only requires 4 vCPUs to handle its workload, you are essentially paying for 4 extra licenses you don't need.

• Solution: Use Azure Advisor to monitor CPU utilization and right-size your VMs before committing to your license count.

Pitfall 3: Failing to account for Disaster Recovery (DR)

DR environments are often ignored until the first internal audit. If you have a DR site in a different Azure region, you need to ensure that your licenses cover those instances as well. Some license agreements allow for "failover rights," which permit you to run instances in a secondary location for a limited time during an emergency without additional cost. Ensure your contract includes these rights.

Callout: The Role of Azure Resource Tags Use Azure resource tags to label your VMs with their environment type (e.g., Env: Production, Env: Dev). This helps immensely during license audits, as you can generate a report of all resources and their associated license types in seconds rather than hours.

6. Detailed Comparison: Marketplace vs. BYOL

To make an informed decision, it helps to see the trade-offs between the two primary acquisition methods clearly.

7. Compliance and Audit Management

An SAP on Azure environment is subject to audits from both SAP and Microsoft. Being prepared is not just about having the right licenses; it is about having the right documentation.

Maintaining an Inventory

You should maintain a "Source of Truth" document that maps every Azure VM to its specific license entitlement. This document should include:

1. VM Name and Resource ID: To uniquely identify the asset.
2. OS/DB License Type: (e.g., PAYG or AHB).
3. Proof of Entitlement: A link or reference to the purchase order or volume license agreement.
4. Date of Deployment: To track the lifecycle of the license.

Automating Compliance Checks

You can use Azure Policy to prevent the deployment of unauthorized VM sizes or to ensure that specific tags are applied to all VMs. For example, you can create a policy that requires every VM to have a LicenseType tag. If a team tries to deploy a VM without this tag, the deployment will be blocked.

// Example Azure Policy snippet to enforce a tag
{
  "if": {
    "field": "tags['LicenseType']",
    "exists": "false"
  },
  "then": {
    "effect": "deny"
  }
}

This policy ensures that every administrator is forced to categorize the license type at the moment of creation, preventing "shadow IT" and unmanaged licensing costs.

8. Strategic Considerations for Large Enterprises

For large enterprises, licensing is often managed through an Enterprise Agreement (EA) or a Microsoft Customer Agreement (MCA). These agreements can provide additional benefits, such as price protection or simplified reporting.

Centralized License Management

Large organizations often have multiple departments deploying SAP workloads. This leads to fragmented licensing. The best practice is to centralize the management of licenses in a single Azure subscription or a dedicated management group. This allows the procurement and IT finance teams to have visibility into the total license consumption across the entire organization.

The "SAP on Azure" Center of Excellence

Establish a Center of Excellence (CoE) that includes members from the Basis team, the Finance team, and the Cloud Architecture team. This group should meet quarterly to review:

• License Utilization: Are we paying for licenses we aren't using?
• Deployment Trends: Are we seeing a shift towards more production or non-production instances?
• Upcoming Renewals: Are there SAP or Microsoft contracts expiring in the next 6–12 months?

Note: Always consult your SAP Account Executive and your Microsoft Cloud Solution Provider (CSP) or Account Manager before making major architecture changes. They can provide guidance on specific contract clauses that may apply to your organization and help you navigate the nuances of your specific agreement.

9. Handling Licensing During Migration (The "Lift and Shift" Phase)

When you are in the middle of a migration, you might have a "hybrid" period where you are running both on-premises and in Azure. During this transition, you are often entitled to "dual-use" rights. These rights allow you to run the software in both locations for a short period (usually 90 days) to facilitate the migration.

Migration Checklist for Licensing:

1. Inventory: Perform a full audit of your on-premises license counts before starting the migration.
2. Verify Entitlements: Check if your current licenses are "Cloud Ready."
3. Plan the Cutover: Schedule the decommissioning of the on-premises servers to coincide with the activation of the Azure instances.
4. Document the Transition: Keep a clear log of the transition dates for audit purposes.

10. Summary and Best Practices

Managing software licensing for SAP on Azure is a continuous process. It is not a task you complete once and forget. As your SAP landscape evolves, your licensing requirements will change.

Key Takeaways:

• Understand Your Contract: Your existing SAP and Microsoft contracts are the foundation of your cloud deployment. Always review the Product Use Rights and your specific Volume Licensing Agreement.
• Leverage Azure Hybrid Benefit: This is the most effective way to reduce costs. Ensure you have the necessary Software Assurance and keep accurate records of your entitlement.
• Right-Size Your VMs: Every vCPU has a cost, especially regarding SQL Server licensing. Over-provisioning is the fastest way to inflate your licensing budget.
• Automate and Tag: Use Azure Policy and resource tagging to maintain a clear inventory of your licenses. This reduces the stress and risk associated with audits.
• Stay Within Support Matrices: Only use OS and DB versions that are certified by SAP for the specific Azure VM SKUs you are deploying.
• Plan for Non-Production: Clearly distinguish between production and non-production environments to ensure you are not over-paying for licenses or using unauthorized developer editions.
• Centralize Governance: Establish a cross-functional team to oversee licensing. Licensing is a business decision, not just a technical one, and it requires input from finance, procurement, and IT.

By following these guidelines, you can build a resilient, compliant, and cost-efficient SAP environment on Azure. Remember that the goal is to create an infrastructure that supports your business objectives without being hindered by unnecessary complexity or unforeseen financial liabilities. If you take the time to map your licenses correctly at the start, you will save your organization significant time and resources in the long run.