SAP S/4HANA in Linux on Azure

This guide presents a set of proven practices for running S/4HANA and Suite on HANA in a high availability (HA) environment that supports disaster recovery (DR) on Azure. The Fiori information applies only to S/4HANA applications.

Architecture

Download a Visio file of this architecture.

This guide describes a typical production system. This architecture uses various virtual machine (VM) sizes. To accommodate the needs of your organization, you can adjust the sizes or reduce this configuration to a single VM.

In this guide, the network layout is simplified to demonstrate architectural principles. It doesn't represent a complete enterprise network.

The architecture uses the following components. Some shared services are optional.

Azure Virtual Network. The Virtual Network service connects Azure resources to each other with enhanced security. In this architecture, a virtual network connects to an on-premises environment through a gateway that you deploy in the hub of a hub-spoke topology. The spoke is the virtual network used for the SAP applications and the database tiers.

Virtual network peering. This architecture uses multiple virtual networks that are peered together. This topology provides network segmentation and isolation for services that you deploy on Azure. Peering connects networks transparently through the Microsoft backbone network and doesn't incur a performance penalty if you implement it within a single region. Separate subnets are used for each tier, including the application tier (SAP NetWeaver) and the database tier, and for shared components like the jump box and Windows Server Active Directory.

VMs. This architecture organizes VMs that run Linux into groups for the application tier and the database tier in the following ways:

• Application tier. This architectural layer includes the Fiori front-end server (FES) pool, the SAP Web Dispatcher pool, the application server pool, and the SAP Central Services cluster. For HA of Central Services on Azure that run in Linux VMs, a highly available network file share service is required, such as Network File System (NFS) file shares in Azure Files, Azure NetApp Files, clustered NFS servers, or SIOS Protection Suite for Linux. To set up a highly available file share for the Central Services cluster on Red Hat Enterprise Linux (RHEL), you can configure GlusterFS on Azure VMs that run RHEL. On SUSE Linux Enterprise Server (SLES) 15 SP1 and later versions or SLES for SAP Applications, you can use Azure shared disks on a Pacemaker cluster as a fencing device to achieve HA.

• SAP HANA. The database tier uses two or more Linux VMs in a cluster to achieve HA in a scale-up deployment. HANA system replication (HSR) is used to replicate contents between primary and secondary HANA systems. Linux clustering is used to detect system failures and facilitate automatic failover. You must use a storage-based or cloud-based fencing mechanism to help ensure that the failed system is isolated or shut down to avoid a partitioned cluster. In HANA scale-out deployments, you can achieve database HA by using one of the following options:

  • Configure HANA standby nodes by using Azure NetApp Files without the Linux clustering component.

  • Scale out without standby nodes by using Azure premium storage. Use Linux clustering for failover.

• Azure Bastion. This service lets you connect to a VM by using your browser and the Azure portal or by using the native Secure Shell (SSH) or Remote Desktop Protocol (RDP) client installed on your local computer. If you use only RDP and SSH for administration, consider using Azure Bastion. If you use other management tools, like SQL Server Management Studio or an SAP front end, use a traditional self-deployed jump box.

Private Domain Name System (DNS) service. Azure Private DNS provides a reliable and secure DNS service for your virtual network. Azure Private DNS manages and resolves domain names in the virtual network without the need to configure a custom DNS solution.

Load balancers. To distribute traffic to VMs in the SAP application tier subnet to increase availability, use Azure Load Balancer. A load balancer provides a layer of security and can serve as an internal-facing or external-facing entry point in the SAP solution infrastructure. VMs behind the load balancer don't have outbound internet connectivity. To allow outbound internet connectivity on the VMs, you need to update your Load Balancer configuration. You can also use Azure NAT Gateway to get outbound connectivity. For SAP web-based application HA, use the built-in SAP Web Dispatcher or another commercially available load balancer. Base your selection on the following considerations:

• Your traffic type, such as HTTP or SAP graphical user interface (GUI) traffic.

• The network features that you need, such as Secure Sockets Layer (SSL) termination.

Load Balancer supports multiple front-end virtual IP addresses. This support is ideal for cluster implementations that include the following components:

• Advanced Business Application Programming (ABAP) SAP Central Services (ASCS)

• Enqueue replication server

These two components can share a load balancer to simplify the solution.

Load Balancer also supports multiple-system identifier (multi-SID) SAP clusters. This feature allows multiple SAP systems on SLES or RHEL to share a common HA infrastructure to help reduce costs. We recommend that you evaluate the cost savings and avoid placing too many systems in one cluster. Azure supports up to five SIDs per cluster.

Application gateway. Azure Application Gateway is a web traffic load balancer that you can use to manage the traffic to your web applications. Traditional load balancers operate at the transport layer, known as Open Systems Interconnection (OSI) layer 4, by using Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). They route traffic based on the source IP address and port to a destination IP address and port. Application Gateway can make routing decisions based on extra attributes of an HTTP request, such as the uniform resource identifier (URI) path or host headers. This type of routing is known as application layer, or OSI layer 7, load balancing. S/4HANA provides web application services through Fiori. You can load balance this Fiori front end, which consists of web apps, by using Application Gateway. If you use public IP addresses, they must use the Standard IP address SKU.

Gateway. A gateway connects distinct networks and extends your on-premises network to an Azure virtual network. We recommend Azure ExpressRoute for creating private connections that don't go over the public internet. You can also use a site-to-site connection. To help reduce latency, use ExpressRoute Global Reach or ExpressRoute FastPath.

Zone-redundant gateway. You can deploy ExpressRoute or virtual private network (VPN) gateways across zones to guard against zone failures. This architecture uses zone-redundant virtual network gateways for resiliency instead of a zonal deployment that's based on the same availability zone.

Proximity placement group. This logical group places a constraint on VMs that you deploy in an availability set or a virtual machine scale set. A proximity placement group helps enforce colocation by ensuring that Azure deploys the VMs in the same datacenter. This configuration reduces physical distance between resources to minimize application latency.

Network security groups (NSGs). To restrict incoming, outgoing, and intra-subnet traffic in a virtual network, you can create NSGs.

Application security groups. To define fine-grained network security policies that are based on workloads and centered on applications, use application security groups instead of explicit IP addresses. You can group VMs by name and secure applications by filtering traffic from trusted segments of your network.

Azure Storage. Storage provides data persistence for a VM in the form of a virtual hard disk. We recommend that you use Azure managed disks.

Recommendations

This architecture describes a small, production-level deployment. Deployments vary based on business requirements, so consider these recommendations as a starting point.

VMs

In application server pools and clusters, adjust the number of VMs based on your requirements. For more information about how to run SAP NetWeaver on VMs, see Plan and implement an SAP deployment on Azure. The guide also applies to SAP S/4HANA deployments.

For more information about SAP support for Azure VM types and for throughput metrics, see SAP note 1928533. To access SAP notes, you need an SAP Service Marketplace account. For a list of certified Azure VMs for the HANA database, see the SAP certified and supported SAP HANA hardware directory.

SAP Web Dispatcher

The Web Dispatcher component load balances SAP traffic among the SAP application servers. To achieve HA of SAP Web Dispatcher, Load Balancer implements either a failover cluster or the parallel Web Dispatcher setup. For internet-facing communications, we recommend a stand-alone solution in the perimeter network to address security requirements. For more information, see SAP Web Dispatcher as an infrastructure component.

Fiori FES

This architecture meets multiple requirements and assumes that you use the embedded Fiori FES model. All the technology components are installed directly on the S/4 system, so each S/4 system has its own Fiori launchpad. The S/4 system manages the HA configuration for this deployment model. This approach removes the need for extra clustering or VMs. For this reason, the architecture diagram doesn't include the FES component.

For more information about deployment options, see SAP Fiori deployment options and system landscape recommendations. For simplicity and performance, the software releases between the Fiori technology components and the S/4 applications are tightly coupled. This setup makes a hub deployment suitable for only a few, specific use cases.

If you use the FES hub deployment, the FES is an add-on component to the classic SAP NetWeaver ABAP stack. Set up HA the same way that you protect a three-tier ABAP application stack that has clustered or multiple-host capability. Use a standby server database layer, a clustered ASCS layer with HA NFS for shared storage, and at least two application servers. Traffic is load balanced via a pair of Web Dispatcher instances that can be either clustered or parallel. For internet-facing Fiori apps, we recommend an FES hub deployment in the perimeter network. Use Azure Web Application Firewall on Application Gateway as a critical component to deflect threats. Use Microsoft Entra ID with Security Assertion Markup Language (SAML) for user authentication and single sign-on (SSO) for SAP Fiori.

Download a Visio file of this architecture.

For more information, see Inbound and outbound internet connections for SAP on Azure.

Application servers pool

To manage logon groups for ABAP application servers, use the following SAP transaction codes:

These transactions rely on the load-balancing capability in the Central Services message server to distribute incoming sessions and workloads across the pool of SAP application servers that manage SAP GUI and RFC traffic.

SAP Central Services cluster

The SAP Central Services contain a single instance of the message server and the enqueue replication service. Unlike the work processes of application servers, these components are single points of failure in the SAP application stack. You can deploy Central Services to a single VM when the Azure single-instance VM availability service-level agreement (SLA) meets your requirements. If your service-level objective (SLO) requires higher availability, you need to deploy these services on an HA cluster. For more information, see Central Services in the application servers tier.

Networking

This architecture uses a hub-spoke topology in which the hub virtual network serves as a central point of connectivity to an on-premises network. The spokes are virtual networks that peer with the hub. You can use the spokes to isolate workloads. Traffic flows between the on-premises datacenter and the hub through a gateway connection.

Network interface cards

Traditional on-premises SAP deployments implement multiple network interface cards (NICs) per machine to segregate administrative traffic from business traffic. On Azure, the virtual network is a software-defined network that routes all traffic through a single network fabric. As a result, you don't need multiple NICs for performance reasons. If your organization needs to segregate traffic, you can deploy multiple NICs for each VM, connect each NIC to a different subnet, and then use NSGs to help enforce different access control policies.

Azure NICs support multiple IP addresses. This support aligns with the SAP-recommended practice to use virtual host names for installations. For more information, see SAP note 962955.

Subnets and NSGs

This architecture divides the virtual network address space into subnets. You can associate each subnet with an NSG that defines the access policies for the subnet. Place application servers on a separate subnet. This approach makes it easier to secure application servers by managing the subnet security policies instead of the individual servers.

When you associate an NSG with a subnet, the NSG applies to all the servers within the subnet and provides fine-grained control over the servers. Set up NSGs by using the Azure portal, Azure PowerShell, or the Azure CLI.

ExpressRoute Global Reach

If your network environment includes two or more ExpressRoute circuits, ExpressRoute Global Reach can help you reduce network hops and reduce latency. This technology is a Border Gateway Protocol (BGP) route peering that you set up between two or more ExpressRoute circuits to bridge two ExpressRoute routing domains. Global Reach reduces latency when network traffic traverses more than one ExpressRoute circuit. It's available only for private peering on ExpressRoute circuits.

Global Reach doesn't support changes to network access control lists or other attributes. All routes that an ExpressRoute circuit learns, whether from on-premises or Azure, are advertised across circuit peering to other ExpressRoute circuits. We recommend that you set up network traffic filtering on-premises to restrict access to resources.

FastPath

FastPath implements Microsoft Edge exchanges at the entry point of the Azure network. FastPath reduces network hops for most data packets. As a result, FastPath reduces network latency, improves application performance, and is the default configuration for new ExpressRoute connections to Azure.

For existing ExpressRoute circuits, contact Azure support to activate FastPath.

FastPath doesn't support virtual network peering. If a virtual network connected to ExpressRoute is peered with other virtual networks, traffic from your on-premises network to the other spoke virtual networks is routed through the virtual network gateway. To address this problem, connect all virtual networks directly to the ExpressRoute circuit.

Load balancers

SAP Web Dispatcher handles load balancing of HTTP and HTTPS traffic to a pool of SAP application servers. This software load balancer provides application layer services, known as layer 7 in the ISO networking model, that are capable of SSL termination and other offloading functions.

Load Balancer is a network transmission layer service (layer 4) that balances traffic by using a five-tuple hash from data streams. The hash is based on a source IP address, source port, destination IP address, destination port, and protocol type. Use Load Balancer in cluster setups to direct traffic to the primary service instance or the healthy node if there's a fault. We recommend that you use Standard Load Balancer for all SAP scenarios. Load Balancer is secure by default, and no VMs behind the load balancer have outbound internet connectivity. To enable outbound internet in the VMs, you must adjust your load balancer configuration.

For traffic from SAP GUI clients that connect to an SAP server via the Dynamic Information and Action Gateway (DIAG) protocol or RFC, the Central Services message server balances the load through SAP application server logon groups. No extra load balancer is needed.

Storage

Azure Storage is a software-defined storage solution for all cloud workloads. The following table lists specific storage types that Microsoft tests, certifies, and recommends for SAP application workloads.

Storage recommendations by use case

The following storage types aren't supported for SAP:

• Azure Standard HDD storage

• Azure Standard SSD storage (except for specific use cases according to SAP note 2015553)

Because application servers don't host any business data, you can also use the smaller P4 and P6 premium disks to help manage costs. For SAP applications, we strongly recommend that you use Premium SSD, Premium SSD v2, or Ultra Disk Storage. To learn how the storage type affects the VM availability SLA, see SLAs for online services. For HA scenarios, Azure shared disk features are available on Premium SSD and Ultra Disk Storage. For more information, see Azure managed disks and Azure managed disk types.

You can use Azure shared disks with Windows Server, SLES 15 SP1 and later, or SLES for SAP. When you use an Azure shared disk in Linux clusters, the Azure shared disk serves as a fencing block device to isolate a failed node. It provides a quorum vote in a cluster network partitioning scenario. This shared disk doesn't have a file system and doesn't support simultaneous writes from multiple cluster member VMs.

Azure NetApp Files has built-in file sharing functionalities for NFS and SMB.

For NFS share scenarios, Azure NetApp Files provides HA for NFS shares that you can use for /hana/shared, /hana/data, and /hana/log volumes. For the availability guarantee, see SLAs for online services. If you use Azure NetApp Files-based NFS shares for the /hana/data and /hana/log volumes, you need to use the NFS v4.1 protocol. For the /hana/shared volume, the NFS v3 protocol is supported.

For the backup data store, we recommend Azure cool and archive access tiers. These storage tiers are cost-effective ways to store infrequently accessed, long-lived data. Consider using the Azure NetApp Files Standard tier as a backup target or the Azure NetApp Files backup option. For a managed disk, we recommend the cool or archive access tier for the backup data tier.

Ultra Disk Storage and Azure NetApp Files Ultra tier significantly reduce disk latency and enhance the performance of critical applications and SAP database servers.

Premium SSD v2 is designed for performance-critical workloads like SAP. For more information about this storage solution's benefits and limitations, see Deploy a Premium SSD v2.

Performance considerations

SAP application servers communicate constantly with the database servers. For performance-critical applications that run on any database platform, including SAP HANA, activate Write Accelerator for the log volume if you use Premium SSD v1. This approach can improve log-write latency. Premium SSD v2 doesn't use Write Accelerator. Write Accelerator is available for M-series VMs.

To optimize inter-server communications, use Accelerated Networking. Most general-purpose and compute-optimized VM instance sizes that have two or more vCPUs support Accelerated Networking. On instances that support hyper-threading, VM instances with four or more vCPUs support Accelerated Networking.

You should optimize the Linux TCP/IP stack and buffers in the network interface to achieve consistent performance. Follow Microsoft-recommended settings. For example, adjust the following items:

• Kernel parameters to optimize read and write memory buffers

• Bottleneck bandwidth and round-trip propagation time (BBR) congestion control

• Adjust TCP parameters for better consistency and throughput

• NIC ring buffers for TX/RX

For more information about SAP HANA performance requirements, see SAP note 1943937.

To achieve high input/output operations per second (IOPS) and disk bandwidth throughput, follow the common practices for storage volume performance optimization. For example, combining multiple disks to create a striped disk volume can improve your input/output (I/O) performance. Turning on the read cache for storage content that changes infrequently can also speed up data retrieval. For more information, see SAP HANA Azure VM storage configurations.

Premium SSD v2 is designed for performance-critical workloads like SAP. Premium SSD v2 is SAP certified and lets you independently size capacity, IOPS, and throughput. For more information about its benefits, limitations, and optimal use scenarios, see Azure managed disk types.

Ultra Disk Storage is a storage solution that meets intensive IOPS and the transfer bandwidth demands of applications like SAP HANA. You can dynamically change the performance of these disks and independently configure metrics like IOPS and MBps without rebooting your VM. We recommend that you use Ultra Disk Storage instead of Write Accelerator when possible.

Some SAP applications require frequent communication with the database. Because of distance, network latency between the application and database layers can negatively affect application performance. Azure proximity placement groups set a placement constraint for VMs deployed in availability sets. Within the logical construct of a group, colocation and performance are favored over scalability, availability, and cost. Proximity placement groups can improve the user experience for most SAP applications.

The placement of a network virtual appliance (NVA) between the application and the database layers of any SAP application stack isn't supported. The NVA requires a significant amount of time to process data packets. As a result, it unacceptably slows application performance.

We also recommend that you consider performance when you deploy resources with availability zones, which can enhance service availability. Consider creating a clear network latency profile between all the zones of a target region. This approach helps you decide on the resource placement for minimum latency between zones. To create this profile, run a test by deploying small VMs in each zone. Recommended tools for the test include PsPing and Iperf. After testing, remove these VMs. For a public domain network latency test tool that you can use instead, see Availability zone latency test.

Azure NetApp Files has unique performance features that allow real-time tuning to meet the needs of the most demanding SAP environments. For performance considerations when you use Azure NetApp Files, see Sizing for HANA database on Azure NetApp Files.

Scalability considerations

The various layers of the SAP application stack have different scaling patterns.

Application layer scaling

At the SAP application layer, Azure provides a range of VM sizes for scaling up (vertically) and scaling out (horizontally). For an inclusive list, see SAP applications on Azure: Supported products and Azure VM types in SAP note 1928533. More VM types are continually certified, so you can scale up or scale down in the same cloud deployment.

Database layer scaling

For more information, see Certified and supported SAP HANA hardware directory.

Availability considerations

Resource redundancy is the general theme in highly available infrastructure solutions. For single-instance VM availability SLAs for various storage types, see SLAs for online services. To increase service availability on Azure, deploy VM resources by using Azure Virtual Machine Scale Sets, which provides flexible orchestration, availability zones, and availability sets.

The Azure regional availability sets deployment model is a supported option. However, we recommend that you adopt the virtual machine scale sets with availability zones model for new SAP deployments to enhance availability and increase deployment flexibility.

In this distributed installation of the SAP application, the base installation is replicated to achieve HA. For each layer of the architecture, the HA design varies.

Deployment approaches

On Azure, SAP workload deployment can be either regional or zonal, depending on the availability and resiliency requirements of the SAP applications.

Deployment options comparison

We recommend that you use Azure flexible scale set zonal deployment for all new SAP deployments to ensure optimal cloud elasticity and resiliency.

For more information about deployment across zones, within a single zone, and in regions without zones, see HA architecture and scenarios for SAP NetWeaver.

Web Dispatcher in the application servers tier

You can achieve HA by using redundant Web Dispatcher instances. For more information, see SAP Web Dispatcher. The availability level depends on the size of the application that's behind Web Dispatcher. In small deployments that have few scalability concerns, you can colocate Web Dispatcher with the ASCS VMs. This approach helps you save on independent operating system maintenance and gain HA at the same time.

Central Services in the application servers tier

For HA of Central Services on Azure Linux VMs, use the appropriate HA extension for the selected Linux distribution. It's customary to place the shared file systems on highly available NFS storage by using the SUSE Distributed Replicated Block Device (DRBD) or Red Hat GlusterFS. To provide a highly available NFS and eliminate the need for an NFS cluster, you can use other cost-effective or robust solutions like NFS over Azure Files or Azure NetApp Files. Azure NetApp Files shares can host the SAP HANA data and log files. This setup lets you use the HANA scale-out deployment model with standby nodes, while NFS over Azure Files is good for highly available, non-database file sharing.

NFS over Azure Files supports the highly available file shares for both SLES and RHEL. This solution works well for highly available file shares like /sapmnt and /saptrans in SAP installations.

Azure NetApp Files supports HA of ASCS on SLES. For more information about ASCS on RHEL HA, see SIOS Protection Suite for Linux.

The improved Azure fence agent is available for both SUSE and Red Hat and provides faster service failover than the previous version of the agent.

Another fencing option is to use Azure shared disks for the fencing device. On SLES 15 SP1 or SLES for SAP 15 SP1 and later, you can set up a Pacemaker cluster by using Azure shared disks. This option is simple and doesn't require an open network port like the Azure fence agent.

A recently supported and simpler Pacemaker configuration on SLES 15 and later is HA SAP NetWeaver with simple mount and NFS on SLES for SAP Applications VMs. In this configuration, the SAP file shares are taken out of the cluster management, which makes it simpler to operate. Use this HA configuration for all new deployments.

To further manage costs of a large SAP landscape, Linux clusters support ASCS multi-SID installation on Azure. Sharing an availability cluster among multiple SAP systems simplifies the SAP landscape and reduces operation costs.

On the load balancer, you can turn on the HA port and avoid the need to configure load balancing rules for many SAP ports. In general, if you turn on the direct server return (DSR) feature when you set up a load balancer, server responses to client inquiries can bypass the load balancer. This feature is also known as floating IP. The load balancer can be on-premises or on Azure. This direct connection keeps the load balancer from becoming the bottleneck in the path of data transmission. For the ASCS and HANA database clusters, we recommend that you enable DSR. If VMs in the back-end pool require public outbound connectivity, further configuration is required.

For traffic from SAP GUI clients that connect to an SAP server via DIAG protocol or RFC, the Central Services message server balances the load by using SAP application server logon groups. No extra load balancer is needed.

Application servers in the application servers tier

You can achieve HA by load balancing traffic within a pool of application servers.

Database tier

Production HANA databases hold critical business data. Configure HANA servers with HA to protect the content and service availability.

HANA replication configuration

The architecture in this guide depicts a highly available SAP HANA database system that consists of two Azure VMs. The native system replication feature of the database tier provides either manual or automatic failover between replicated nodes.

The following details apply to automatic failover:

• Linux HAE provides cluster services for HANA resources.
• Automatic failover detects failure events automatically.
• Automatic failover orchestrates failover of faulty services to healthy nodes.
• The typical failover time is between 60 seconds and 120 seconds.

The following details apply to manual failover:

• It requires admin intervention.
• It has a longer RTO.
• It's less complex and less costly.
• It suits non-production environments.

Deploy VMs across availability zones

Availability zones can enhance service availability. Zones refer to physically separated locations within a specific Azure region. They improve workload availability and protect application services and VMs against datacenter outages. Applications treat VMs in a single zone as though they're in a single update or fault domain. When you select zonal deployment, the application distributes VMs in the same zone to fault and upgrade domains on a best-effort basis.

Availability zone requirements

Before you deploy SAP systems across availability zones, take the following considerations into account:

• Intra-zone latency: Network latency between VMs in one zone.

• Inter-zone latency: Network latency between VMs across chosen zones.

• Service availability: Confirm that Azure services are available in all chosen zones.

• VM type availability: Verify that the required VM types are available in all chosen zones.

• Application sensitivity: Determine application tolerance for network latency.

• Latency profile: Create a network latency profile by using PsPing or Iperf.

For comprehensive considerations, see SAP HA availability zones guide.

Active/passive deployment example

In this example deployment, the active/passive status refers to the application service state within the zones. In the application layer, all four active application servers of the SAP system are in zone 1. Another set of four passive application servers is built in zone 2 but is shut down. They're activated only when needed.

The two-node clusters for Central Services and the database are stretched across two zones. If zone 1 fails, Central Services and database services run in zone 2. The passive application servers in zone 2 are activated. All components of this SAP system are colocated in the same zone, which minimizes network latency.

Active/active deployment example

In an active/active deployment, two sets of application servers are built across two zones. In each zone, two application servers in each set are active. As a result, application servers are active in both zones in normal operations.

The ASCS and database services run in zone 1. The application servers in zone 2 might have longer network latency when they connect to the ASCS and database services because of the physical distance between the zones.

If zone 1 goes offline, the ASCS and database services fail over to zone 2. You can bring the dormant application servers online to provide full capacity for application processing.

DR considerations

Every tier in the SAP application stack uses a different approach to provide DR protection. For DR strategies and implementation information, see DR overview and infrastructure guidelines for SAP workloads and DR guidelines for SAP applications.

Cost considerations

Use the Azure pricing calculator to estimate costs.

For more information, see Azure Well-Architected Framework cost optimization.

VMs

This architecture uses VMs that run Linux for the management, SAP application, and database tiers.

VM payment options

Use Spot Virtual Machines for the following use cases:

• High-performance computing (HPC) scenarios
• Batch processing jobs
• Visual rendering applications
• Test environments and continuous integration/continuous delivery (CI/CD) workloads
• Large-scale stateless applications

For pricing information, see the following articles:

• Linux VMs pricing
• Azure Reserved Virtual Machine Instances
• Azure reservations documentation

Load Balancer

In this scenario, Azure load balancers distribute traffic to VMs in the application tier subnet.

You're charged only for the number of configured load-balancing and outbound rules. Inbound network address translation rules are free. No hourly charge applies for the Load Balancer when no rules are configured.

ExpressRoute

In this architecture, ExpressRoute is the networking service used to create private connections between an on-premises network and Azure virtual networks.

All inbound data transfer is free. All outbound data transfer is charged based on a predetermined rate. For more information, see ExpressRoute pricing.

Management and operations considerations

To help keep your system running in production, consider the following points.

Azure Center for SAP solutions

Azure Center for SAP solutions is a comprehensive solution that you can use to create and run SAP systems as a unified workload on Azure. The Center for SAP solutions guided deployment experience creates the necessary compute, storage, and networking components that you need to run your SAP system. Then you can automate the installation of the SAP software according to Microsoft best practices. You can take advantage of the management capabilities for both new and existing Azure-based SAP systems.

Backup

You can back up SAP HANA data in many ways. After you migrate to Azure, continue to use any existing backup solutions that you have. Azure provides two native approaches to backup. You can back up SAP HANA on VMs or use Azure Backup at the file level. Azure Backup is Backint certified by SAP. For more information, see Azure Backup FAQ and Support matrix for backup of SAP HANA databases on Azure VMs.

Identity management

Use a centralized identity management system to control access to resources at all levels.

• Provide access to Azure resources through Azure role-based access control (Azure RBAC).

• Grant access to Azure VMs through Lightweight Directory Access Protocol (LDAP), Microsoft Entra ID, Kerberos, or another system.

• Support access within the apps themselves through the services that SAP provides, or use OAuth 2.0 and Microsoft Entra ID.

Monitoring

To maximize the availability and performance of applications and services on Azure, use Azure Monitor. Azure Monitor is a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. Azure Monitor shows how applications are performing and proactively identifies problems that affect them and the resources that they depend on.

For SAP applications that run on SAP HANA and other major database solutions, see Azure Monitor for SAP solutions to learn how Azure Monitor for SAP can help you manage SAP services availability and performance.

Security considerations

This section describes the available security mechanisms that you can use to protect your SAP data.

Application security

SAP has its own user management engine to control role-based access and authorization within the SAP application and databases. For more information, see SAP HANA security overview.

Network security

To improve network security, consider using a perimeter network that uses an NVA to create a firewall in front of the subnet for Web Dispatcher and the Fiori FES pools. You can configure these servers in the perimeter network and use virtual network peering to establish connectivity with the S/4 systems. Alternatively, for scenarios in which cost optimization is a priority, deploy active front-end servers that host Fiori applications within the same virtual network as the S/4 systems to minimize data transfer costs.

For comprehensive network security guidance that applies to S/4HANA, see Security for your SAP landscape.

Data encryption

Azure infrastructure security ensures that data is encrypted in transit and at rest. For SAP workloads on Linux VMs, you have several encryption options to protect your data.

Recommended encryption approaches

For SAP HANA data-at-rest encryption, we recommend SAP HANA-native encryption technology. For broader SAP workloads on Linux, we recommend the following approaches:

• Database-native encryption: Use SAP HANA's built-in encryption for data, log, and backup files to protect SAP database content.

• Encryption at host: Turn on host-based encryption, optionally combined with Storage service encryption and customer-managed keys, for VM-level protection.

To enhance the security of data in Azure Files, you can turn on encryption in transit for Azure Files NFS.

Avoid Azure disk encryption for SAP workloads

We don't recommend Azure disk encryption for SAP systems that run on Linux because of the following limitations:

• Support limitations and operational complexity

• Documented reliability problems with backup, recovery, and HA scenarios

• Lack of support by SAP-certified Linux distributions for production SAP environments

Azure disk encryption is scheduled for retirement on September 15, 2028. Plan for alternative encryption mechanisms for new deployments and migrate existing systems to the recommended approaches.

Communities

Communities can answer questions and help you set up a successful deployment. Consider the following resources:

• SAP on Azure Product Announcements Summary – SAP Sapphire 2025
• Azure community support
• SAP Community

Contributors

Microsoft maintains this article. The following contributors wrote this article.

Principal author:

• Ben Trinh | Principal Architect

To see nonpublic LinkedIn profiles, sign in to LinkedIn.

Next steps

For more information and examples of SAP workloads that use some of the same technologies as this architecture, see the following articles:

• Deploy SAP S/4HANA or BW/4HANA on Azure
• Use Azure to host and run SAP workload scenarios
• Plan and implement an SAP deployment on Azure
• Data encryption guidance

Related resource

• Run SAP production workloads by using an Oracle database on Azure