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's deployed in the hub of a hub-spoke topology. The spoke is the virtual network that's 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 are deployed on Azure. Peering connects networks transparently through the Microsoft backbone network and doesn't incur a performance penalty if it's implemented 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 such as 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 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 that's installed on your local computer. If only RDP and SSH are used 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 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 Standard Load Balancer. Standard Load Balancer provides a layer of security by default. VMs that are behind Standard Load Balancer don't have outbound internet connectivity. To enable outbound internet on the VMs, you need to update your Standard 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:

• 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.

Standard 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.

Standard 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 and User Datagram Protocol. 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 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, ensure that they use the Standard IP address SKU. Avoid the Basic IP address SKU because it's planned for deprecation on September 30, 2025.

Gateway. A gateway connects distinct networks and extends your on-premises network to an Azure virtual network. Azure ExpressRoute is the recommended Azure service 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 are deployed in an availability set or a virtual machine scale set. A proximity placement group helps enforce colocation by ensuring that VMs are deployed 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 Azure Virtual Machines planning and implementation guide. 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 SAP certified and supported SAP HANA hardware directory.

SAP Web Dispatcher

The Web Dispatcher component is used for load balancing SAP traffic among the SAP application servers. To achieve HA of SAP Web Dispatcher, Azure Load Balancer implements either a failover cluster or the parallel Web Dispatcher setup. For internet-facing communications, a stand-alone solution in the perimeter network is the recommended architecture to address security requirements. Embedded Web Dispatcher on ASCS is an advanced configuration. If you use this configuration, consider proper sizing because of the extra workload on ASCS.

Fiori front-end server (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 for user authentication and single sign-on 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 transaction codes:

• SMLG: Load balance logon users.
• SM61: Manage batch server groups.
• RZ12: Manage remote function call (RFC) groups.

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 requirement. If your SLA 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 where 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, then use NSGs to help enforce different access control policies.

Azure NICs support multiple IP addresses. This support aligns with the practice that SAP recommends of using virtual host names for installations in 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 route peering that's 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 learned by an ExpressRoute circuit, 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. Load Balancer is used 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. Standard Load Balancer is secure by default, and no VMs behind Standard Load Balancer have outbound internet connectivity. To enable outbound internet in the VMs, you must adjust your Standard 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

Some customers use standard storage for their application servers. Because standard managed disks aren't supported, we recommend that you use Azure Premium SSD or Azure NetApp Files in all scenarios. A recent update to SAP note 2015553 excludes the use of Azure Standard HDD storage and Azure Standard SSD storage for a few specific use cases.

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 Azure SSD v1, SSD v2, or Ultra Disks. To understand how the storage type affects the VM availability SLA, see SLAs for online services. For HA scenarios, Azure shared disk features are available on Azure Premium SSD and Azure 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 a failed node block device. 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 can be used 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 that you use Azure cool and archive access tiers. These storage tiers are cost-effective ways to store long-lived data that's infrequently accessed. Also, consider using the Azure NetApp Files Standard tier as a backup target or the Azure NetApp Files backup option. For a managed disk, the recommended backup data tier is the Azure cool or archive access 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, enable 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.

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. Enabling the read cache on storage content that changes infrequently can also speed up your data retrieval. For more information, see SAP HANA Azure virtual machine storage configurations.

Premium SSD v2 is designed for performance-critical workloads like SAP. For more information about its benefits, limitations, and optimal use scenarios, see Azure managed disk types.

Ultra Disk Storage is a new generation of storage that meets intensive IOPS and the transfer bandwidth demands of applications such as SAP HANA. You can dynamically change the performance of ultra 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 that are 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 greatly 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 enable 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

At the SAP application layer, Azure provides a wide range of VM sizes for scaling up and scaling out. 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.

On the database layer, this architecture runs SAP S/4HANA applications on Azure VMs that can scale up to 24 terabytes (TB) in one instance. If your workload exceeds the maximum VM size, you can use a multiple-node configuration for as much as 96 TBs (four 24-TB instances) for online transaction processing applications. 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. Azure provides different deployment options, like Virtual Machine Scale Sets with flexible orchestration (one fault domain configuration), availability zones, and availability sets, to enhance the availability of the resources.

As customer deployments on Azure have grown over the years, Microsoft has enhanced Azure VM deployment models to include Virtual Machine Scale Sets to help ensure cloud elasticity and resiliency. Considering the available deployment options, we strongly recommend that you use Azure flexible scale set zonal deployment for all new deployments. 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 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 enables 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 now 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 much 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 cluster supports ASCS multi-SID installation on Azure. Sharing an availability cluster among multiple SAP systems simplifies the SAP landscape and reduces operation costs.

On Standard Load Balancer, you can enable the HA port and avoid the need to configure load balancing rules for many SAP ports. In general, if you enable 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

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.

• For manual failover, deploy more than one HANA instance and use HSR.

• For automatic failover, use both HSR and Linux HA extension (HAE) for your Linux distribution. Linux HAE provides cluster services for HANA resources, detects failure events, and orchestrates the failover of faulty services to a healthy node.

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. VMs in a single zone are treated as if they're in a single update or fault domain. When zonal deployment is selected, VMs in the same zone are distributed to fault and upgrade domains on a best-effort basis.

In Azure regions that support this feature, a minimum of three zones are available. The maximum distance between datacenters in these zones isn't guaranteed. To deploy a multiple-tier SAP system across zones, you must know the network latency within a zone and across targeted zones and how sensitive your deployed applications are to network latency.

Take these considerations into account when you decide to deploy resources across availability zones:

• Latency between VMs in one zone
• Latency between VMs across chosen zones
• Availability of the same Azure services, or VM types, in the chosen zones

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 get activated. With all components of this SAP system colocated in the same zone, network latency is minimized.

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, there are active application servers 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. The dormant application servers can be brought 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.

There are several payment options for VMs:

• For workloads that don't have predictable time of completion or resource consumption, consider the pay-as-you-go option.

• Consider using Azure reservations if you can commit to using a VM over a one-year or three-year term. VM reservations can significantly reduce costs. You can save up to 72% compared to pay-as-you-go options.

• Use Azure spot VMs to run workloads that can be interrupted and don't require completion within a predetermined timeframe or SLA. Azure deploys spot VMs when there's available capacity and evicts them when it needs the capacity back. Spot VMs costs are lower than other VMs. Consider spot VMs for these workloads:

  • High-performance computing scenarios, batch processing jobs, or visual rendering applications

  • Test environments, including continuous integration and continuous delivery workloads

  • Large-scale stateless applications

• Azure Reserved Virtual Machine Instances can reduce your total cost of ownership by combining Azure Reserved Virtual Machine Instances rates with a pay-as-you-go subscription so that you can manage costs across predictable and variable workloads. For more information, see Azure Reserved Virtual Machine Instances.

For an overview of pricing, see Linux virtual machines pricing.

Load Balancer

In this scenario, Azure load balancers are used to 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. There's no hourly charge for Standard Load Balancer when no rules are configured.

ExpressRoute

In this architecture, ExpressRoute is the networking service that's used for creating 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 an end-to-end solution that enables you to create and run SAP systems as a unified workload on Azure and provides a more seamless foundation for innovation. The Azure 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 (RBAC).

• Grant access to Azure VMs through Lightweight Directory Access Protocol, 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

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.

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 front-end server pools. To minimize data transfer costs, deploy active front-end servers that host Fiori applications within the same virtual network as the S/4 systems. Alternatively, you can configure these front-end servers in the perimeter network, which takes advantage of virtual network peering to establish connectivity with the S/4 systems.

For infrastructure security, data is encrypted in transit and at rest. For information about network security that applies to S/4HANA, see Security for your SAP landscape.

To encrypt Linux VM disks, you have several options. For SAP HANA data-at-rest encryption, we recommend that you use the SAP HANA-native encryption technology. For support of Azure disk encryption on specific Linux distributions, versions, and images, see Azure Disk Encryption for Linux VMs.

Communities

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

• Run SAP applications on the Microsoft platform blog
• Azure community support
• SAP Community
• Stack Overflow SAP

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
• Virtual Machines planning and implementation for SAP NetWeaver

Related resource

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