Playbook

Select a VM for a production SAP HANA database.

→Use Mv2-series or M-series VMs for large databases (>4TB). Use SAP-certified Edsv5-series VMs for smaller production HANA databases (<4TB).

Why: M-series/Mv2-series are SAP-certified for large memory workloads. Edsv5-series offers a cost-effective certified option for smaller HANA instances. Other series (D, F, L) are not certified for production HANA databases.

Reference↗

Select a VM for an SAP NetWeaver application server.

→Use Edsv5-series or Ddsv5-series VMs. Size based on SAPS requirements from SAP EarlyWatch Alert reports or SAP Quick Sizer.

Why: E-series and D-series VMs provide a balanced CPU-to-memory ratio suitable for SAP application server workloads and are SAP-certified for NetWeaver.

Ensure minimal network latency between SAP application servers and the database server.

→Deploy all related VMs (app servers, ASCS/ERS, database) within a single Proximity Placement Group (PPG).

Why: PPGs physically co-locate VMs in the same datacenter, minimizing network round-trip time to meet SAP's sub-millisecond latency requirement between application and database tiers.

Provide a shared file system for the /hana/shared volume in a SAP HANA scale-out deployment.

→Use Azure NetApp Files (ANF) with the NFS protocol.

Why: ANF is the SAP-certified, high-performance, shared NFS storage solution required for HANA scale-out configurations. Block storage like Managed Disks cannot be used for this purpose.

Provide a highly available shared file system for /sapmnt and the global transport directory (/usr/sap/trans).

→Use Azure NetApp Files (NFS) or Azure Files Premium (NFS). For Windows, use Azure Files Premium (SMB) or SOFS cluster.

Why: These services provide managed, highly available file shares with the required performance and protocol support (NFS for Linux, SMB for Windows), eliminating the need to build and manage a separate file server cluster.

Design storage for production SAP HANA /hana/data and /hana/log volumes requiring high IOPS and sub-millisecond latency.

→Use Azure Ultra Disk or Premium SSD v2 managed disks. For /hana/log on M-series VMs, Premium SSD with Write Accelerator is also a valid option.

Why: Ultra Disk and Premium SSD v2 meet the stringent IOPS, throughput, and sub-millisecond latency KPIs defined by SAP for production HANA workloads. Standard storage tiers are not supported.

Design a secure network architecture for SAP workloads, isolating production from non-production environments.

→Use a hub-spoke topology. Deploy SAP systems in dedicated spoke VNets for each environment (Prod, QA, Dev). Use Network Security Groups (NSGs) to enforce strict traffic rules between subnets.

Why: This provides strong network isolation at the VNet level and fine-grained traffic control with NSGs, following security best practices and the Azure Landing Zone concept.

Deploy SAP landscapes on Azure using an Infrastructure as Code (IaC) approach for consistency and automation.

→Use the official SAP on Azure Deployment Automation Framework, which leverages Terraform and Ansible. Alternatively, build custom Bicep or Terraform modules.

Why: The framework provides pre-built, SAP-validated templates for deploying the entire landscape (control plane, workload zones, SAP systems), reducing manual effort and ensuring adherence to best practices.

Securely publish SAP Fiori or other web-based SAP applications to external users over the internet.

→Use Azure Application Gateway with the Web Application Firewall (WAF) enabled.

Why: App Gateway provides Layer 7 load balancing, SSL termination, and WAF protection against common web vulnerabilities, making it the ideal and secure entry point for web-based SAP applications.

Deploy an extremely large SAP HANA database (>12 TB memory) that exceeds Azure VM capacity.

→Use SAP HANA on Azure Large Instances (HLI). Connectivity requires an ExpressRoute circuit connecting the HLI stamp to an Azure VNet via an ExpressRoute gateway.

Why: HLI are purpose-built, bare-metal servers providing the massive memory and performance needed for the largest HANA workloads, which are beyond the scale of current virtualized infrastructure.

Deploy an SAP system across Availability Zones while still minimizing latency within each zone.

→Create a separate Proximity Placement Group (PPG) for the resources in each Availability Zone. Pin each PPG to its respective zone.

Why: A single PPG cannot span zones. This approach ensures low-latency co-location of resources *within* a zone, while still achieving high availability *across* zones.

Create and distribute standardized, patched, and pre-configured VM images for SAP deployments across multiple regions.

→Use Azure Image Builder to define a repeatable image creation process. Store and replicate the resulting managed images using Azure Compute Gallery.

Why: This provides a version-controlled, automated "golden image" factory, ensuring consistency and reducing deployment time compared to manually configuring each new VM.

Provide secure RDP/SSH administrative access to SAP VMs without exposing them to the public internet.

→Deploy Azure Bastion (Standard SKU) into a dedicated subnet within the SAP virtual network. Use Bastion to connect to VMs via the Azure portal or native clients.

Why: Bastion acts as a secure, managed jump box, eliminating the need for public IP addresses on SAP VMs or complex VPN setups for administrative access, thereby reducing the attack surface.

Encrypt SAP data volumes using customer-managed encryption keys.

→Use Azure Disk Encryption with a customer-managed key (CMK) stored in Azure Key Vault. This can be combined with SAP HANA native encryption for defense-in-depth.

Why: This configuration gives the customer full control over the data encryption keys, meeting stringent compliance and security requirements for key lifecycle management.

Migrate an on-premises SAP system with a non-HANA database (e.g., Oracle, Db2) to SAP HANA on Azure.

→Use SAP Software Update Manager (SUM) with Database Migration Option (DMO). For minimal downtime, use the "DMO with System Move" or near-Zero Downtime (nZDT) options.

Why: DMO combines database conversion, system upgrade, and data migration into a single, optimized process. It is the standard SAP tool for this task, minimizing downtime compared to classical export/import.

Migrate an on-premises SAP HANA system to Azure with the lowest possible downtime.

→Use SAP HANA System Replication (HSR) to continuously replicate data to the target Azure VM. Perform a final, brief cutover (takeover) during the maintenance window.

Why: HSR minimizes the downtime window to minutes, as only the final sync and takeover are required. Backup/restore or export/import methods result in hours of downtime for large databases.

Transfer a large volume of SAP data (>10 TB) from on-premises to Azure for the initial migration load when network bandwidth is insufficient.

→Use Azure Data Box for the initial bulk data transfer. Use ExpressRoute or VPN for subsequent delta synchronization.

Why: Data Box provides a faster offline transfer method than network-based transfers over limited bandwidth, significantly reducing the initial load time.

Deploy and manage SAP S/4HANA systems on Azure using a simplified, guided experience.

→Use Azure Center for SAP solutions (ACSS). Prerequisites include registering the `Microsoft.Workloads` provider and creating a user-assigned managed identity with required permissions.

Why: ACSS streamlines deployment by bundling best practices and provides a single pane of glass in the Azure portal for basic management (start/stop, monitoring) and quality checks.

Determine the correct Azure VM sizes for a new or migrated SAP system.

→Use the SAP Quick Sizer tool for new implementations. For migrations, analyze SAP EarlyWatch Alert reports from the existing system to get current SAPS and memory usage. Map these to SAP-certified Azure VMs.

Why: These SAP-native tools provide the most accurate workload characterization (SAPS, memory, I/O), which is essential for correctly selecting Azure resources and ensuring performance and supportability.

Integrate a customer-managed Azure environment with an SAP S/4HANA system deployed via RISE with SAP.

→SAP manages the underlying Azure infrastructure in a separate subscription. Establish connectivity from your Azure VNet to the SAP-managed VNet using VNet Peering.

Why: RISE is a managed service offering from SAP. VNet Peering provides the standard, secure, and private network integration path between the RISE environment and other customer workloads in Azure.

Enforce corporate standards and security best practices across all SAP deployments in Azure.

→Use Azure Policy to enforce rules, such as requiring specific VM SKUs, managed disk encryption, NSG association, or mandatory tagging. Use the `DeployIfNotExists` effect to automatically install the VM Extension for SAP.

Why: Azure Policy provides automated, large-scale governance, ensuring all deployments are compliant without relying on manual checks or individual template configurations.

Validate that deployed Azure infrastructure is correctly configured and meets SAP support requirements before go-live.

→Install and enable the Azure VM Extension for SAP (Enhanced Monitoring). Run the SAP on Azure Quality Check tool from GitHub.

Why: The VM extension is mandatory for SAP support. The Quality Check tool proactively validates configurations (storage, networking, OS settings) against a list of known best practices and requirements.

Implement an application-consistent, automated backup solution for SAP HANA databases on Azure VMs.

→Use Azure Backup for SAP HANA, which integrates via the SAP-certified Backint interface. Configure a policy with full/differential and frequent log backups for point-in-time recovery.

Why: Azure Backup provides a native, integrated, and certified solution that automates backup scheduling, retention, and management without requiring custom scripts or separate backup infrastructure.

Implement comprehensive, centralized monitoring for an SAP landscape running on Azure.

→Deploy Azure Monitor for SAP Solutions. Configure providers for SAP HANA, NetWeaver, OS (Linux), and High-Availability Cluster telemetry.

Why: This is a native Azure service designed for SAP. It provides rich, SAP-aware telemetry and visualizations, centralizing monitoring of the entire SAP stack from infrastructure to application.

Apply OS or SAP kernel patches to a high-availability SAP cluster with minimal downtime.

→Use a rolling update approach. Put the secondary node in maintenance mode, patch it, then reboot. Perform a controlled cluster failover to make the patched node primary. Finally, patch the former primary node.

Why: This rolling approach ensures the SAP service remains available on one node throughout the entire maintenance process, minimizing the business service outage.

Automate the process of creating copies or refreshing SAP systems (e.g., refreshing a QAS system from PRD).

→Use SAP Landscape Management (LaMa) with the Azure Connector.

Why: LaMa orchestrates the end-to-end process, including Azure infrastructure tasks (VM stop/start, disk snapshots) and SAP-specific post-copy automation (BDLS), significantly reducing manual effort.

Validate the SAP disaster recovery plan without impacting the production environment.

→Use Azure Site Recovery's "Test Failover" feature which brings up replicated VMs in an isolated VNet. For HSR, use snapshot-based restores to an isolated system or a dedicated tertiary replication target.

Why: Testing in an isolated network prevents IP conflicts and any interference with production systems or ongoing replication, allowing for safe and thorough validation of the DR runbook.

Plan for future resource requirements (CPU, memory, storage) for a growing SAP system on Azure.

→Use Azure Monitor metrics and Log Analytics to analyze historical usage trends. Use this data for forecasting. For storage, leverage the ability to dynamically resize Azure Managed Disks online.

Why: Proactive capacity management based on historical data prevents performance degradation and allows for just-in-time provisioning, optimizing costs compared to significant upfront overprovisioning.

Minimize Azure costs for running a full SAP landscape.

→For production workloads, use 1- or 3-year Azure Reserved Instances. For non-production systems, implement automated start/stop schedules via Azure Automation. Use Azure Hybrid Benefit for licenses where eligible.

Why: Reserved Instances provide large discounts for predictable, 24/7 workloads. Auto-shutdown eliminates compute costs during idle periods for non-production. This combination addresses both major cost drivers.

Track and allocate Azure costs for SAP workloads to specific business units, projects, or SAP systems (SIDs).

→Implement a mandatory tagging strategy for all Azure resources. Use tags like `CostCenter`, `Environment`, `SAP-SID`, and `BusinessOwner`. Analyze costs using Azure Cost Management.

Why: Tagging is the native Azure mechanism for categorizing resources. Consistent tagging enables detailed cost analysis and chargeback, providing essential financial visibility.

Diagnose intermittent network connectivity or latency issues between SAP VMs in Azure.

→Use Azure Network Watcher tools, specifically Connection Monitor to test paths and latency, and NSG Flow Logs to analyze and identify blocked traffic.

Why: Network Watcher provides proactive and reactive tools to pinpoint network issues at the Azure platform level, which is often difficult to diagnose from within the guest OS alone.

Automate OS patching for SAP VMs while ensuring applications are shut down gracefully.

→Use Azure Update Manager with pre/post scripts. The pre-script stops the SAP application and database, and the post-script restarts them after patching is complete.

Why: This combines the automation of Azure patch management with the application-awareness required for SAP, preventing data inconsistencies that could occur from patching a running system.

Implement high availability for SAP Central Services (ASCS/ERS) or SAP HANA on SUSE/RHEL Linux VMs.

→Configure a Pacemaker cluster. Use the `fence_azure_arm` agent for STONITH (fencing) to prevent split-brain scenarios, authenticated via a managed identity.

Why: Pacemaker is the SAP-supported clustering solution on Linux. `fence_azure_arm` is the Azure-native mechanism to reliably isolate a failed node via Azure APIs, which is mandatory for a stable cluster.

Implement high availability for SAP Central Services (ASCS/ERS) on Windows Server VMs.

→Configure a Windows Server Failover Cluster (WSFC). For cluster shared storage, use either Azure Shared Disks or a third-party replication solution like SIOS DataKeeper.

Why: WSFC is the standard for Windows clustering. Azure Shared Disks provide native shared block storage, while SIOS creates a "shared-nothing" cluster, both replacing the need for traditional SANs in the cloud.

Design a high availability (HA) and disaster recovery (DR) strategy for SAP HANA.

→For HA (in-region), deploy VMs across Availability Zones and use synchronous (SYNC) SAP HANA System Replication (HSR). For DR (cross-region), use asynchronous (ASYNC) HSR.

Why: Synchronous replication provides a zero RPO but requires low latency (<2ms), making it ideal for HA across zones. Asynchronous replication tolerates higher cross-region latency, making it the choice for DR.

Configure an Azure Load Balancer to manage the virtual IP address for an SAP HA cluster (ASCS/ERS or HANA).

→Use an Azure Standard Load Balancer. Enable Floating IP (Direct Server Return) on the load balancing rule. Configure a health probe on the specific port monitored by the cluster (e.g., 620xx for ASCS).

Why: The Standard SKU is required for zone-redundancy. Floating IP is necessary for the cluster's virtual IP to function correctly. The specific health probe ensures traffic is only sent to the active node.

Understand the purpose of the Enqueue Replication Server (ERS) in an SAP ASCS high availability cluster.

→The ERS instance maintains a replica of the SAP lock table from the active ASCS instance.

Why: If the ASCS instance fails over, the newly started ASCS instance retrieves the replicated lock table from the ERS. This preserves transaction locks and allows users to continue working without interruption.

Design a complete disaster recovery solution for a multi-tier SAP landscape.

→Use native database replication for the database tier (e.g., async HSR for HANA). Use Azure Site Recovery (ASR) for the application tier (ASCS/ERS and application servers).

Why: This "best-of-breed" approach ensures application consistency for the database via its native replication, while ASR provides a cost-effective and automated way to replicate and fail over the application server VMs.

Implement high availability for an SAP database running on Microsoft SQL Server in Azure VMs.

→Use SQL Server Always On Availability Groups, typically with synchronous-commit mode for HA within a region, combined with a WSFC.

Why: Always On AG is the recommended and fully supported HA/DR solution for SQL Server, providing database-level replication and automatic failover capabilities.

Implement SBD (STONITH Block Device) as a quorum mechanism for a two-node Pacemaker cluster.

→Configure a small Azure Shared Disk and attach it to both cluster nodes. Alternatively, set up a dedicated iSCSI target server on a third VM.

Why: While `fence_azure_arm` is the primary fencing agent, SBD provides an additional witness/quorum mechanism to prevent split-brain, especially in clusters without a third voting node.