updated date: 31.Oct.2023

This blog is part of the Business Continuity with RISE and BTP blog series:
part 1 – Concept Explained
part 2 – Technical Building Blocks in RISE 👈
part 3 – Technical Building Blocks in BTP

4. Technical Building Blocks in RISE

RISE with SAP Private Cloud Edition is a ‘SaaS-like’ one-stop offering with managed IaaS services (considering hyperscaler reference architecture of SAP on Azure, SAP on AWS, and SAP on GCP), managed SAP Basis services, and application support. In this section, we won’t be discussing the commercial combinations or the exact same offerings in SAP RISE, but rather will just explain the technical building blocks of what makes running SAP on hyperscalers (Azure, AWS, and GCP) possible.

4.1. IaaS Level

4.1.1. Network

Load Balancers are functioned for monitoring and failover. With load balancers, the active server failure and be detected, then the traffic can be redirected to the redundant server. Below table is a summary of load balancers been used in RISE with SAP. Here’s an example of how SSO request with High Availability works under load balancing in RISE.

Azure	Azure Load Balancers	cross-AZ, or cross-region failover Standard Load Balancer for OSI Layer 4 (TCP/UDP) load balancing Application Gateway for OSI Layer 7 (HTTP) load balancing
Azure	Azure Traffic Manager	cross-region failover DNS-based traffic load balancer
AWS	AWS Elastic Load Balancer (ELB)	cross-AZ, or cross-region failover Network Load Balancer (NLB) for OSI Layer 4 (TCP/UDP) load balancing Application Load Balancer (ALB) for OSI Layer 7 (HTTP/HTTPS) load balancing
AWS	Amazon Route53	cross-AZ, or cross-region failover Amazon Route 53 Application Recovery Controller, can do automate failover
Google	Google Cloud Load Balancer	Network Load Balancer (NLB) for OSI Layer 4 (TCP/UDP/other IP protocol) load balancing Application Load Balancer (ALB) for OSI Layer 7 (HTTP/HTTPS) load balancing
SAP	SAP Web Dispatcher	A reverse proxy server for SAP systems, used to distribute incoming requests from clients to the appropriate application servers in a SAP landscape.

4.1.2. Storage

RISE with SAP Private Cloud Edition running on Azure, AWS, and GCP, consume hyperscaler native storage component. There native storage components are with built-in features/services of backup, replication (either synchronous or asynchronous), snapshot, and recovery.

Azure	Azure Managed Disks	Azure managed disks are block-level storage volumes used with Azure Virtual Machines. For SAP workloads, it is used to store the kernel, executable, and data. Azure Monitor can be used for monitoring the health Azure Managed Disks are available within one Availability Zone with Locally Redundant Storage (LRS) feature by having 3 replicas within one single data center with zone-redundant storage (ZRS) feature, Azure Managed Disks can be synchronously replicated across availability zone within a region, hence make cross-availability-zone failover possible with Azure Site Recovery, which facilitates replication and failover across regions, as well as Azure Backup for regular backups and point-in-time recovery, can make cross-region failover possible
	Azure Files	provides redundancy within the same region as well as in different regions integrates with Azure Backup, to enable scheduling regular backups of file shares
	Azure NetApp Files	Azure native, first-party, enterprise-class, high-performance file storage service, provides high-performance and low-latency for SAP workloads provides SMB or NFS shares for SAP’s global transport directory
	Azure Blob Storage	provides LRS for within one data center, and ZRS for cross availability zone within one region with Object Replication feature, makes object asynchronously available in another region support NFS mount
AWS	Elastic Block Storage (EBS)	EBS provides block-level storage volumes for use with EC2 instances. EBS for SAP Workload is used to store all the kernel, executable and data. Amazon CloudWatch can be used to monitor the health of EBS Volume EBS Volume is only available within one Availability Zone. with Amazon EBS snapshots, cross-availability-zone failover is possible by using the snapshots to recover EBS Volume into a separate Availability Zone with AWS Elastic Disaster Recovery or AWS Backups, it is possible to do cross-region failover. For HANA Database Server EC2 instances, HANA System Replication (HSR) can be used to achieve the same purpose
	Elastic File System (EFS)	EFS is used to support shared file systems such as SAP Kernel, Interface Files, Batch Job files, Logs, and Transport files Amazon CloudWatch can be used to monitor the health of EFS EFS is cross-availability-zone resilient, meaning that failover of EFS over Availability Zones within one region is possible with Amazon EFS replication, EFS can be replicated into another region
	Amazon FSx	Amazon FSx for NetApp ONTAP is a fully managed service that provides highly reliable, scalable, high-performing, and feature-rich file storage built on NetApp’s popular ONTAP file system (use case: for SAP HANA) Amazon FSx for Windows File Server provides fully managed Microsoft Windows file servers
	Simple Storage Services (S3)	S3 is used to support backup of SAP systems, and also archival (historical data) Amazon CloudWatch can be used to monitor the health of S3 S3 is cross-availability-zone resilient, meaning that failover of S3 over Availability Zones within one region is possible with S3 Replicating objects feature, S3 can be asynchronously replicated into another region
GCP	Persistent Disk	By default, each Compute Engine virtual machine (VM) instance has a single boot Persistent Disk volume that contains the operating system. Zonal persistent disks provide durable storage and replication of data within a single zone within a region. Regional persistent disks provide durable storage and synchronous replication of data between two zones in the same region, with that, cross-availability-zone replication (RPO=0) is possible for HA or in-region DR purpose Persistent Disk Asynchronous Replication enables cross-region replication for DR (low RTO and RPO) capability, without additional Google Compute Engine operations Google Cloud Backup and DR provides central backup management, and can be used for backup and replication of Persistent Disks
	Filestore	Filestore has built-in backup feature for cross-availability-zone and cross-region for DR purpose with Cloud Storage, it is also possible to replicate Filestore data across regions Google Cloud Backup and DR provides central backup management, and can be used for backup and replication of Persistent Disks
	Cloud Storage	Cloud Storage stores data redundantly in one region, dual-regions, or multi-regions. This allows customer to obtain the desired level of availability at the lowest cost for designated purposes (eg. SAP backup for DR purpose).

4.1.3. Compute

RISE with SAP Private Cloud Edition running on Azure, AWS, and GCP, consume hyperscaler native compute resources, and have been fully virtualised.

For Virtual Machines on Azure, AWS, and GCP, there are built-in Hypervisors doing monitoring, auto-restart, and self-healing.

Azure Virtual Machine	offers optimisation for SAP workloads, hypervisor is based on Hyper-V Azure Site Recovery, which facilitates replication and failover across regions Availability Set deployment within one availability zone Active-Active deployment cross availability zones within same region with distributed ASCS / ERS instance deployed
AWS EC2	offers optimised types for SAP workloads, hypervisor is Nitro Hypervisor AWS Elastic Disaster Recovery cross regions failover Placement Groups deployment within one availability zone Active-Active deployment cross availability zones within same region with distributed ASCS / ERS instance deployed EC2 is available within an Availability Zone only, nevertheless the data are stored within EBS Volume, which can support cross-availability-zone and cross-region failover. And EC2 resources can be reserved in other availability zone and region.
Google Compute Engine	offers optimised types for SAP workloads, hypervisor is based on KVM Google Cloud Backup and DR provides central backup management and can facilitate backup, replication and failover across regions for Google Compute Engine, SAP databases (HANA, ASE, IQ, MaxDB), and file shares. For HANA, both backint backups and block-based, incremental-forever backups are supported Managed Instance Groups deployment within one availability zone Active-Active deployment cross availability zones within same region with distributed ASCS / ERS instance deployed Workload Manager is a Compute Engine service that provides continuous analysis of your SAP configurations to identify issues, detect misconfigurations, and improve system reliability

4.2. Operating System Level

Clustering solution on OS level for high availability and disaster recovery purpose failover.

SUSE Linux (SLES) Pacemaker	high availability with Pacemaker Cluster for SAP workload
Redhat Linux (RHEL) PowerHA	Red Hat Enterprise Linux High Availability Add-on provides all the necessary packages for configuring a pacemaker-based cluster that provides reliability, scalability, and availability to critical production services. In addition, the components for the Red Hat High Availability solutions for SAP NetWeaver, S/4HANA and SAP HANA
Microsoft Windows Server Failover Cluster	Windows Server Failover Clustering for SAP workload

4.3. Application and Database Level

Application Server

SAP NetWeaver (ABAP and JAVA) provides the run-time environment for SAP installation-based applications
ABAP Central Services (ASCS) and Enqueue Replication Server (ERS) functioned as the Message Queue servers (asynchronous communication) for High Availability purpose
ABAP Central Services (ASCS) contains the ABAP message server and the Standalone Enqueue Server
Enqueue Replication Server (ERS) contains the replication table, which is a copy of the lock table of the Standalone Enqueue Server in the ASCS instance.

Database Server

HANA System Replication (HSR) is a mechanism ensuring the high availability of your SAP HANA system
supports a recovery point objective (RPO) of 0 seconds and a recovery time objective (RTO) measured in minutes.
depending on physical datacenter distance of the 2 HANA Database Servers, both synchronous replication (less than 100km) and asynchronous replication (more than 100km) are possible
scalability: Scale Up (increase RAM) and Scale Out (increase host)
scale out pattern: Worker Node (active/hot standby) and Standby Node (cold/passive standby) are the mechanism to create redundancy for high availability purpose

4.4. IaC and CI/CD pipeline

When deploying hyperscaler infrastructure resources, with IaC enabled, the provisioning of infrastructure can be through code instead of through manual processes.

AWS	AWS Cloud Formation, AWS Cloud Development Kit (AWS CDK) / for Kubernetes / for Terraform, AWS Cloud Control API
Azure	deploy IaC on Azure
GCP	IaC recommendation

For application code change, CI/CD pipeline is recommended to automate and govern change management. This is especially necessary when doing side-by-side extensibility to keep the core clean. Below is a summary of available CI/CD pipeline services:

SAP Continuous Integration and Delivery (on SAP BTP)	native integration with SAP CAP, Fiori, Integration Suite
Azure DevOps	integration with SAP
AWS CodePipeline	integration with SAP (Cloud Foundry Apps, Fiori Apps)
Google Cloud Build	integration with SAP (tutorial)

Disclaimer

The blog content does not necessarily represent the official opinion of SAP, Microsoft, Amazon Web Services, or Google Cloud. The opinions appearing in this blog are backed by SAP, Azure, AWS, GCP documentation which can be revealed in the corresponding reference links.
The blog content is only focusing on technical discussion, hence can not be used as commercial basis, nor should be used as SAP official offering documentation.

Acknowledgment to contributors/reviewers/advisors:

Ke Ma (a.k.a. Mark), author, Senior Cloud Architect, RISE Cloud Advisory RA group

Special THANK YOU to RISE with SAP community members, who contributed to this blog:

Ferry Mulyadi, Partner Solution Architect, Amazon Web Services

Micah Waldman, Product Management Lead, Google Cloud Business Continuity

Thorsten Staerk, Customer Engineer, Google Cloud

Frank Gong, Digital Customer Engagement Manager, SAP ECS

Marc Koderer, Chief Architect, SAP ECS

Boris Maeck, Head of Technology and Architecture, SAP ECS

Aaron Smyth, Principle Service Architect, SAP

Sven Bedorf, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, MEE

Kevin Flanagan, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, EMEA North

Luc DUCOIN, Cloud Architect & Advisor Expert, RISE Cloud Advisory, EMEA North

Richard Traut, Head of Cloud Architecture & Advisory, RISE Cloud Advisory, EMEA North

Peter van den Berg, Cloud Architect & Advisor Expert, RISE Cloud Advisory, MEE

Extended Reading: 
case study: extra-large scale HANA DB sets in RISE S4 PCE, by SAP ECS colleague Marc Koderer
SAP on Azure documentation, by Microsoft 
SAP on Google Cloud documentation, by Google Cloud

Some more previous blogs:
DNS integration with SAP RISE in multi-cloud environment series guide – Azure
DNS integration with SAP RISE in multi-cloud environment series guide – AWS
DNS integration with SAP RISE in multi-cloud environment series guide – GCP
Harmonized Single Sign-On for SAP RISE Customers in Multi-Cloud Environment
Demystify Single Sign-On on Server Side for SAP RISE Customers
empower SAP RISE enterprise users with Azure OpenAI in multi-cloud environment
Unlock the Power of Business Data for SAP RISE Customers: Mastering Data Management and Cultivating Insights
Extend the Power of Data for SAP RISE Customers: data federation with SAP in multi-cloud GCP
Extend the Power of Data for SAP RISE Customers: data federation with SAP in multi-cloud AWS
Extend the Power of Data for SAP RISE Customers: data federation with SAP in multi-cloud Azure