Enhancing Operational Efficiency with Cloud-Based Solutions

Running SAP S/4HANA and Microsoft Azure is a real infrastructure decision with real trade-offs, not a marketing exercise. This guide covers the architecture layers, VM selection logic, high availability configuration, and disaster recovery patterns you need to make informed choices before and after deployment.

TL;DR: Key Takeaways

• M-series and Mv2-series VMs are the primary certified families for production SAP HANA workloads on Azure.
• High availability requires independent cluster configurations for both the HANA DB tier and the SAP Central Services layer.
• HANA System Replication (HSR) synchronous mode is required for zero-data-loss HA within a region; asynchronous mode is used for cross-region DR.
• Azure NetApp Files and Ultra Disk are the storage tiers that meet SAP HANA I/O performance requirements.
• Proximity Placement Groups reduce network latency between app servers and the HANA database tier.

What SAP S/4HANA on Azure Actually Looks Like

SAP S/4HANA is an in-memory ERP suite that runs exclusively on SAP HANA as its database layer. That constraint matters enormously for infrastructure planning because SAP HANA has strict memory, I/O, and latency requirements that not every cloud VM family can meet. Azure is one of the few cloud platforms with certified large-memory VM support and bare-metal options for HANA workloads, backed by a 25-year SAP-Microsoft partnership that includes joint certification programs and co-engineered integrations.

This guide focuses on architecture, VM selection, high availability (HA) configuration, and disaster recovery (DR). It does not cover migration methodology or licensing. If you’re evaluating or optimizing an existing deployment, start here.

The Reference Architecture for SAP S/4HANA on Azure

Core Architecture Layers

The standard architecture separates into four layers: SAP application servers, the SAP HANA database tier, shared file systems, and Azure networking components. The application servers run the ABAP (Advanced Business Application Programming) workload and communicate with the HANA database over a low-latency internal network path. Shared storage handles SAP transport directories and other data shared across application server instances.

Networking and Proximity

Azure Virtual Network with dedicated subnets for each tier keeps traffic segmented and simplifies security group management. ExpressRoute or a VPN Gateway handles connectivity back to on-premises systems. Proximity Placement Groups (PPGs) pin your application server VMs and HANA DB VMs to the same physical datacenter rack, which reduces network round-trip time to single-digit milliseconds. That matters because synchronous HANA System Replication adds write latency on every transaction, and any additional network overhead compounds the problem.

The Azure Architecture Center publishes a maintained reference diagram for SAP S/4HANA deployment models. Treat that as the canonical visual reference. What we’re covering here is the reasoning behind the configuration choices, not a reproduction of the diagram.

Choosing the Right Azure VM for SAP HANA Workloads

Certified VM Families

SAP HANA requires certified VM types. Not every Azure VM qualifies. The SAP HANA Hardware Directory is the authoritative source for what’s supported, and SAP Note 1928533 governs which Azure VM families are approved for production S/4HANA deployments. Skipping this check and deploying on an uncertified instance type puts you outside SAP’s support boundary. That’s a risk most enterprise teams can’t accept.

The M-series and Mv2-series are the primary options for S/4HANA OLTP workloads. M-series VMs cover memory configurations from around 192 GB up to 3 TB for single-node deployments. Mv2-series extends further for workloads requiring more memory. The Edsv4 series covers smaller non-production or sandbox environments where cost control matters more than peak throughput. Azure’s powerful computing resources support enterprise-grade deployments with the performance characteristics SAP HANA demands.

Scale-Up vs. Scale-Out

Scale-up means one large VM handles the entire HANA database. Scale-out distributes the HANA database across multiple nodes. For most S/4HANA OLTP workloads, scale-up on a single M-series or Mv2-series VM is the right call. Scale-out adds operational complexity and is better suited to BW/4HANA analytical workloads with massive data volumes. When your workload approaches the 3 TB memory boundary of standard Azure VMs, you face a real decision: move to HANA Large Instances (HLI) or redesign. HLI carries a significant cost premium and a different operational model with less Azure control-plane flexibility. Use the Azure Pricing Calculator to model the cost difference for your specific workload profile before committing.

Designing High Availability for SAP S/4HANA on Azure

Review your organization’s current RTO (Recovery Time Objective) and RPO (Recovery Point Objective) requirements before reading this section. The configuration choices below map directly to those targets.

Zone-Redundant Deployments

High availability in this context means protecting both the SAP application layer and the HANA database layer independently. Azure Availability Zones are the primary mechanism for zone-redundant deployments. Spreading your application servers and HANA DB across two zones gives you protection against a single datacenter failure. The trade-off is latency: synchronous HANA System Replication across zones adds measurable write latency compared to same-zone replication. In our experience, this is acceptable for most OLTP workloads but worth measuring in your environment using the SAP HANA hardware and cloud measurement tool (HCMT) before go-live.

Pacemaker and Azure Load Balancer

Pacemaker is the open-source cluster manager used to automate failover for the HANA DB tier on Linux. It works alongside STONITH (Shoot The Other Node In The Head), a fencing mechanism that prevents split-brain scenarios during failover. Azure Load Balancer sits in front of the cluster and redirects client connections to the active HANA node after a failover event. Configuring this correctly requires careful attention to probe intervals and timeout values. Many teams underestimate the testing burden here. Plan for multiple failover drills in a non-production environment before your first maintenance window.

SAP Central Services Clustering

HA for SAP Central Services (ASCS/ERS) requires a separate cluster configuration from the DB tier. This is a common oversight. The ASCS instance handles message server and enqueue server functions; losing it without a standby takes down the entire SAP application layer. Configure a separate Pacemaker cluster for ASCS/ERS with Azure NetApp Files providing the shared storage backend.

SAP HANA System Replication: Modes and Trade-offs

HANA System Replication (HSR) is the native mechanism for both HA and DR. Understanding the replication modes is the most important technical decision in this space.

• SYNC mode: Synchronous replication. The primary node waits for acknowledgment from the secondary before committing a transaction. Zero data loss on failover. Required for HA within a region. Adds write latency proportional to network round-trip time between nodes.
• ASYNC mode: Asynchronous replication. The primary commits without waiting for secondary acknowledgment. Used for cross-region DR where network latency makes synchronous replication impractical. Accepts some data loss (RPO greater than zero) in exchange for no write latency impact.
• SYNCMEM mode: A middle option where the primary waits for the secondary to write to memory but not to disk. Less common in Azure deployments.

Choosing SYNC for your DR replication across Azure regions is a mistake we’ve seen teams make when they’re trying to achieve zero RPO for DR. The latency between Azure regions makes synchronous cross-region replication impractical for production OLTP workloads. Use SYNC within a region for HA and ASYNC across regions for DR.

Disaster Recovery Architecture on Azure for SAP S/4HANA

DR for SAP S/4HANA on Azure typically uses a secondary Azure region with asynchronous HSR to a standby HANA instance. Azure paired regions are the recommended DR target for most enterprise deployments because Microsoft prioritizes recovery sequencing for paired regions during large-scale outages.

Azure Site Recovery (ASR) can protect the SAP application server layer by replicating VM state to the secondary region. ASR does not replace HSR for the HANA database tier. These two tools work together: ASR handles the app servers, HSR handles the database. Conflating them creates gaps in your DR coverage.

What does this mean for RTO and RPO? With asynchronous HSR and ASR, your RPO is the replication lag of the async HSR stream, typically seconds to minutes depending on transaction volume. Your RTO depends on how quickly you can start the standby HANA instance, run the ASR failover for app servers, and reconnect clients. Teams that have rehearsed this process regularly achieve RTOs measured in hours. Teams that haven’t rehearsed it face unpredictable recovery times. Test your DR failover procedure in a non-production environment before you need it in production.

Storage and Networking Requirements That Affect Performance

Storage Tiers for SAP HANA

SAP HANA has strict I/O requirements for both throughput and latency. Azure Premium SSD v2 and Ultra Disk are the storage tiers that meet SAP’s published KPIs. Standard SSDs don’t qualify for production HANA data and log volumes. Azure NetApp Files is the recommended solution for shared NFS storage used by SAP transport directories and shared application data. Run the HCMT tool against your storage configuration to validate that you’re meeting SAP’s baseline before go-live.

Network Latency and PPGs

Proximity Placement Groups pin VMs to the same physical datacenter rack. This reduces network latency between your SAP application servers and the HANA database tier from potentially 2-4 ms to sub-millisecond. For synchronous HSR, every millisecond of write latency is added to every committed transaction. PPGs are not optional for production S/4HANA deployments. Configure them before you deploy your VMs, not after, because adding a VM to a PPG after the fact may require redeployment.

Operational Practices for Long-Term Efficiency

Azure Monitor combined with the SAP on Azure monitoring extension surfaces HANA-specific metrics that generic Azure monitoring doesn’t expose: HANA memory utilization, CPU ready time, disk IOPS per volume, and replication lag. Set alert thresholds on replication lag for your HSR streams. A growing lag on your async DR replication is an early warning of a problem you want to catch before a failover event.

Scheduled OS patching requires careful coordination with the HANA cluster state. The sequence matters: take the secondary node out of the cluster, patch it, verify HSR replication resumes, then perform a controlled failover to the patched node before patching the original primary. Document this sequence before your first maintenance window. Teams that improvise it under time pressure make mistakes that cause unplanned downtime.

VM right-sizing after go-live is common. Azure allows resizing between M-series tiers without redeploying the OS, but it requires a planned downtime window. Cross-reference your actual HANA memory consumption against your VM’s available memory using HANA Studio or the HANA cockpit at 30 and 90 days post-go-live. Overprovisioned memory means you’re paying for capacity you don’t need. Underprovisioned memory means HANA is paging, which kills performance.

Stay Current: SAP-certified Azure VM families and supported configurations change as new hardware generations release. Subscribe to the Microsoft Tech Community SAP blog and review SAP Note 1928533 periodically to catch updates that affect your deployment’s support status. Azure maintains high compliance standards that support enterprise deployments across regulated industries.

Frequently Asked Questions About SAP S/4HANA on Azure

What Azure VM types are certified for SAP HANA?

The M-series and Mv2-series are the primary certified families for production S/4HANA OLTP workloads. Always verify against the SAP HANA Hardware Directory and SAP Note 1928533 before selecting a VM SKU.

How do I configure high availability for SAP S/4HANA on Azure across availability zones?

Deploy HANA DB VMs across two Azure Availability Zones with synchronous HSR between them. Use Pacemaker with STONITH for automated failover and Azure Load Balancer to redirect client connections. Configure a separate Pacemaker cluster for ASCS/ERS.

What is the difference between synchronous and asynchronous HSR?

Synchronous HSR (SYNC mode) waits for secondary acknowledgment before committing, giving zero data loss but adding write latency. Asynchronous HSR (ASYNC mode) commits without waiting, suitable for cross-region DR where latency makes synchronous replication impractical.

Does Azure Site Recovery replace HSR for SAP HANA DR?

No. Azure Site Recovery protects the SAP application server layer. HSR handles the HANA database tier. You need both for a complete DR solution.

When should I consider HANA Large Instances instead of standard Azure VMs?

When your workload exceeds the memory capacity of standard M-series or Mv2-series VMs. HANA Large Instances carry a significant cost premium and offer less Azure control-plane flexibility, so model the cost difference carefully using the Azure Pricing Calculator before deciding.