Licensed for Distribution

Achieve SAP S/4HANA Reliability and Extensibility in the Public Cloud

18 February 2026 - ID G00842264 - 21 min read
By Alessandro Galimberti, Tobi Bet,
Hosting SAP S/4HANA in the cloud and extending SAP applications through cloud value-added services requires deep multidomain expertise. This research guides heads of I&O and their teams to build resilient deployments, while leveraging advanced PaaS and SaaS offerings to drive business innovation.

Insights at a Glance

Deploying SAP S/4HANA in the public cloud offers organizations the potential for greater scalability, reliability, and innovation, but also introduces architectural and operational complexities. Organizations must focus on designing cloud-aware architectures that deliver high availability and resilience, while leveraging hyperscaler-native PaaS and SaaS services to extend SAP capabilities.
As organizations are embracing the SAP Clean Core methodology and migrating their SAP deployments to public cloud hyperscalers, integrating a robust SAP-aware cloud architecture with advanced extensibility capabilities is becoming a critical priority.
To achieve a successful implementation of your SAP S/4HANA deployments in cloud, you must:
  • Design a cloud aware architecture: Design an architecture that integrates your SAP estate with both industry best practices and the unique capabilities of your cloud provider of choice. Avoid relying exclusively on standardized templates, as they may be either overly complex or insufficient to address your specific requirements.
  • Design for resilience and availability: Architect your production SAP environments with multi-zone, high-availability features and comprehensive business continuity disaster recovery. This ensures that your SAP environment is protected against common cloud failures.
  • Leverage extensibility from multiple providers: Connect SAP data to hyperscaler-native PaaS and SaaS services for advanced analytics and business process improvements. Do not fall into a vendor lock-in trap by limiting your organization to solutions offered solely by SAP or your chosen cloud provider.

Impact Brief

Organizations moving their SAP S/4HANA and other SAP systems to the cloud are redesigning their architectures. They are looking to align with prescriptive guidelines from SAP and hyperscalers to achieve expected KPIs for availability and performance.
Such architecture must incorporate best practices for high availability and disaster recovery, and leverage provider-native services to ensure operational continuity and minimize service disruptions.
Additionally, with the surging of Clean Core methodology as a way to reduce risk and cost of SAP upgrades, SAP customization is shifting from custom-code developed within the platform, to extensibility options enabled by SAP and third-party systems.
Leveraging value-added PaaS and SaaS services to enhance the value of data residing in their SAP environments will be essential if businesses hope to compete, and for government agencies to achieve their mission.
Organizations should look beyond just the SAP stack and identify the most suitable technology stack for each SAP extension — particularly for those critical extensibility initiatives that serve as key business differentiators — by broadening their evaluation beyond the solutions offered by SAP — which offers SAP BTP as main extensibility platform — and the cloud hyperscaler currently hosting their SAP estate.

Actions

  • Design a cloud-aware architecture that enables your SAP workloads to meet the availability and resiliency KPIs needed by your organization by leveraging industry’s best practices and the unique capabilities of your selected cloud provider.
  • As a best practice, architect production SAP on cloud environments using mult-zone, high-availability configurations and comprehensive DR capabilities to support resilient and uninterrupted business operations.
  • Enable extensibility by integrating SAP systems with hyperscaler-native PaaS and SaaS services, such as analytics, AI, and IoT, to drive innovation and process improvement.
  • Utilize vendor-specific SDKs and connectors to standardize seamless integration between SAP and cloud-native platforms, enhancing vendor supportability and simplifying life cycle management.

Cautions

  • Misalignment between your SAP architecture in the cloud and expectations from your business can result in wasted investments and, more critically, may result in poor performance, reduced availability, limited rightsizing and tuning opportunities, and, in severe cases, data loss.
  • Inadequate focus on cloud resiliency will lead to unplanned downtime and significant operational disruptions for your SAP estate on public cloud.
  • Overlooking extensibility options offered by cloud hyperscalers will limit organization’s ability to innovate, adapt to market changes and for government agencies to achieve their mission.
  • Suboptimal integration and connection practices between SAP and third-party systems can introduce security vulnerabilities, degrade system performance, and increase overall architectural complexity.

How to Execute

This research note outlines best practices relevant to running SAP applications on multiple cloud hyperscalers and managed service providers. The SAP-recommended solution, SAP Cloud ERP Private is managed and operated by SAP on its reference architecture. This research note highlights key differences associated with this solution when relevant for the reader.

Design a Cloud-Aware Architecture

A broad range of SAP business applications — including SAP S/4HANA, SAP ECC, SAP BW, and SAP BW/4HANA — operate on SAP NetWeaver or its successor, the SAP ABAP Platform. This middleware platform was launched before public cloud hyperscalers were introduced. Before public cloud hyperscalers became a trend, numerous outsourcing providers offered shared, multitenant platforms designed to host SAP workloads for their clients. In some instances, these platforms evolved into what is now known as SAP Community Cloud offerings.
Consequently, as client demand for public cloud adoption increased, SAP began certifying leading hyperscalers to support the deployment of SAP workloads on their public cloud infrastructures. How to Choose the Right Cloud and Managed Services Provider for SAP S/4HANA provides a comprehensive framework for evaluating and selecting cloud providers that best align with your organization.
To ensure proper performance, SAP maintains a rigorous certification program that enables a select group of cloud providers and issues highly prescriptive guidelines to ensure that SAP systems deployed on public cloud infrastructure consistently meet customer expectations for availability and performance.1 Hyperscalers have also integrated and extended such guidelines with the best practices tailored to their cloud offering.2
The architecture shown in Figure 1 is a high-level summarization on how to deploy a productive SAP instance on one of the major hyperscaler platforms. It’s important to note that implementation via a specific cloud provider might differ from the architecture depicted, as some hyperscalers lack certain capabilities, thus increasing the risk and operational burden that an organization needs to accept on that cloud.
Although Figure 1 focuses on a SAP S/4HANA deployment, the same architecture can be used for any SAP ABAP and SAP NetWeaver-based system hosted in a supported cloud hyperscaler. These include SAP Fiori (stand-alone hub), SAP ECC and SAP BW/4HANA.
Figure 1: SAP S/4HANA on Public Cloud IaaS Reference Architecture
A reference architecture for solutions built on the SAP S/4HANA platforms, SAP ABAP and SAP NetWeaver-based system in the cloud. This architecture offers about 99.99% SLA availability, along with a near-zero recovery point objective and a recovery time objective of less than one hour.
This architecture can offer an availability SLA up to 99.99%, with a near-zero RPO and an RTO of less than one hour. Customers can decide to relax the high-availability or disaster recovery features represented in the figure above for nonproduction instances.
Within Region 1, we can identify:
  • SAP Database, which is replicated among the two zones using synchronous replication. Certain databases such as SAP HANA can offload read-intensive activities to the secondary node during normal operations. Switching between nodes is controlled by a failover cluster based on Linux Pacemaker.
  • SAP Central Services (ASCS) and Enqueue Replication (ERS), which are part of a dedicated failover cluster, orchestrated using a Windows or Linux failover cluster. SAP ASCS are the “core” of SAP NetWeaver. They provide SAP Message Server, used as a load balancer for users and batch on different SAP Application Servers, and SAP Enqueue Server, used for managing the “lock table” held in a memory portion. This has the purpose of preventing two transactions from changing the same data in the database simultaneously. On the opposite node where SAP ASCS are running, an SAP ERS is running, which is a replication mechanism used to replicate on a secondary server the “lock table” held in memory by SAP ASCS. In case of failure of SAP ASCS, SAP ERS will store a copy of all uncommitted SAP Transactions. An NFS file system, often provided as a service from the cloud provider, takes care of sharing SAP executables and other relevant executables among nodes.
  • Multiple SAP Application Servers and SAP Web Dispatcher (WD), which are deployed in multiple virtual machines to address both scalability and zone resilience. At least two cloud virtual machines running one SAP AS each and two running SAP WD will be deployed, with at least one SAP AS on each cloud zone. SAP AS will also have visibility of the network file system used by an SAP ASCS cluster in order to share an SAP kernel and other SAP executables between all SAP components.
  • Backup, which is performed using (if available) a cloud-native solution integrated with a third-party solution if some features are not available — this is common in less mature cloud providers, or when using a non-HANA database on SAP ECC. Cloud object storage is the preferred backup repository. SAP HANA databases require certified backup solutions.
Within Region 2, we can identify:
  • SAP Database, which is replicated from the primary region using asynchronous replication. This server is configured outside the failover cluster in the primary region. Failover is initiated manually.
  • SAP ASCS and SAP Application Servers, which are replicated using a cloud-aware (or, if available, a cloud-native) block replication software service such as AWS Elastic Disaster Recovery or Microsoft Azure Site Recovery. Such software uses block-level continuous data replication to ensure that target machines are always replicated in their most up-to-date state during a disaster or drill, as well as to achieve consistent RPO of a few seconds. The continuous data replication takes place in a low-cost “staging area,” which reduces the compute and storage footprint to a minimum.
  • NFS as a service, which is replicated using the provider-native replication technology.
  • Backup vaulting capabilities are provided by replicating to Region 2 the Object Storage used as backup repository in Region 1. Depending on regulatory requirements and risk assessment, only certain backups can be replicated to Region 2 (i.e., only weekly backups).

SAP HANA Scale-Out Architecture

While the scale-up architecture shown above supports up to 32TB of memory, while deploying HANA databases larger than 12TB of memory, a different architecture — SAP HANA scale-out — is advised to be deployed to allow horizontal scalability of the systems. In this architecture, the HANA database is divided into multiple compute nodes, with each node responsible for running a specific portion of the database. In most configurations, these compute nodes share data through one storage solution.
This is enabled through solutions such as Amazon FSx for NetApp ONTAP and Microsoft Azure NetApp Files. They offer more flexible headroom for future database growth and enable benefits and efficiencies for managing backups with faster and more effective failover.
Shared storage systems inherently provide redundancy with duplication from multiple disks and RAID techniques in the same way that a traditional SAN design protects users from information loss should any single disk fail. Google has opted for a different approach with its SAP HANA scale-out system with host autofailover. This solution automatically remaps block storage to a new server in the event of a scale-out node failure, thereby eliminating the complexity associated with using a network file system as back-end storage for a database. Additionally, to enable fast backup, both AWS and Google provide consistency groups that manage cross-storage device snapshots, allowing the creation of instance-synced snapshots for backup recovery and DR scenarios.
To ensure high-availability production servers, utilize an N+1 configuration, which distributes the workload across multiple nodes. This configuration allows for redundancy so that if one node fails, the others can continue to handle the workload. Additionally, as the servers share the same storage, if one compute node fails, the system can still access the data from other nodes, ensuring continuous operation and minimizing downtime.

Cloud Architectures in SAP Cloud ERP Private

SAP Cloud ERP Private, focuses on the delivery of a unified SLA that monitors the availability of each SAP “System"3 (SID) in its entirety. For production environments, SAP Cloud ERP Private offers three tiers of SLA: a standard availability of 99.7%, with a paid upgrade option for 99.9% availability. An additional 99.95% option is available in the SAP Private Tailored Option (PTO) only. In all cases, nonproduction systems are covered by an SLA of 95%.
This approach diverges from Gartner best practices listed above and leading cloud providers’ best practices, which are widely adopted by Gartner clients and extensively implemented by managed service providers (MSPs) competing with SAP Cloud ERP Private. Unlike what is an industry standard, SAP’s baseline SLA of 99.7% does not include high availability by default — a de facto requirement for productive SAP applications deployed in the public cloud, and a standard practice among the majority of Gartner clients deploying SAP in cloud for several years.
Our Organization Committed to RISE with SAP; What Now? describes the key differences in approach between SAP Cloud ERP Private and competing MSPs. For further technical information, the downloadable attachment below provides detailed specifications for each SAP Cloud ERP Private reference architecture.
SAP Cloud ERP Private Reference Architectures
Download (pptx)

Leverage Cloud Value-Added PaaS and SaaS Services to Extend Your SAP Functionalities

Customers have historically extended and integrated their SAP ERP systems using a mix of customizations internally in their SAP systems and external “satellite” systems.
For new SAP workloads, such as newer SAP S/4HANA releases, SAP has shifted its strategy to deliver innovations through extensions, with the goal of minimizing the complexity and risks associated with upgrade projects, reducing implementation lead time and effort. This approach, known as the “Clean Core” concept, encourages SAP developers to move beyond traditional custom programming within the SAP environment. Instead, developers are now focused on building industry-specific solutions by leveraging external systems, often cloud-based services, to enhance business processes and improve business-related KPIs. Quick Answer: What Does Clean Core Mean For Your SAP Sourcing Strategy? provides further details on Clean Core.
Cloud providers offer a wide range of “value added” hyperscaler-native, PaaS and SaaS services, such as data lakes, data and analytics, AI, and others aimed to extend the value of the data hosted in SAP. While SAP extensibility and Clean Core can be achieved through various approaches, leveraging value-added cloud services provided by SAP and by hyperscalers can simplify extension development, reduce maintenance overhead and provide access for modern capabilities such as Generative AI.
Public cloud hyperscalers offer “ready-made SAP extensibility” by delivering a suite of value-added PaaS and SaaS solutions.
Each hyperscaler enables seamless connectivity between SAP systems — whether hosted within their own cloud environment, on another hyperscaler, or on-premises — and a wide range of their PaaS and SaaS services via API integration. This integration is mostly enabled by an SDK installed within the SAP environment. Additionally, SAP — through its Business Technology Platform (BTP) — enables organizations to augment data stored in SAP by utilizing components provided directly by SAP, as well as by leveraging a curated subset of PaaS and SaaS services from select hyperscalers.
A comparison of features offered natively by various hyperscalers and by SAP through BTP is presented in Table 1. The services listed are not mutually exclusive; customers have the flexibility to host their SAP systems in different environments — including another hyperscaler, on-premises, or within SAP Cloud ERP Private — while still consuming API-based services from other providers. However, it is important to note that this approach may introduce additional latency and incur egress costs.

Comparison of SDKs for SAP ABAP

Amazon Web Services
Google Cloud
Microsoft Azure
SAP
Product
AWS SDK for ABAP
ABAP SDK for Google Cloud
ABAP SDK for Azure
SAP BTP
Region availability for connected services
All AWS Regions and Local Zones.
Some AWS services might not be available in a specific region or local zone.
All Google Cloud Regions.
Some Google services might not be available in a specific region.
All Azure Cloud Regions.
Some services might not be available in a specific region.
Hyperscaler-provided services limited regions:
  • AWS: 12 Regions (38 Regions in total).
  • Azure: 10 Regions (47 Regions in total)
  • Google Cloud: 10 Regions (42 Regions in total)
  • Alibaba Cloud: 1 Region (28 Regions in total)
SAP Cloud DC: 21 regions
Cloud service availability
SDK currently supports all AWS services.
New daily release.
SDK currently supports all Google Cloud services.
New version every few months.
SDK currently supports only a few Azure services.4
Last major update 1+ year ago.
80+ of services are offered. Availability of services varies by provider and by region.
Cloud service management
Managed by AWS and the customer using a shared responsibility model.
Managed by Google Cloud, and the customer using a shared responsibility model.
Managed by Microsoft Azure, and the customer using a shared responsibility model.
Managed by SAP and the customer using a shared responsibility model.
Cost
There are no additional costs associated with the SDK. Customers are charged for the cloud resources and services utilized through the SDK; however, certain SAP “indirect licensing” fees may also be applied.
There are no additional costs associated with the SDK. Customers are charged for the cloud resources and services utilized through the SDK; however, certain SAP “indirect licensing” fees may also be applied.
There are no additional costs associated with the SDK. Customers are charged for the cloud resources and services utilized through the SDK; however, certain SAP “indirect licensing” fees may also be applied.
BTP services are priced for three cost models:
  • Pay as you go (PAYG)
  • Business Technology Platform Enterprise Agreement (BTPEA), usage-based, with credits
  • Subscription for fixed sets of services and rates, not usage-based.
Support
AWS SDK and AWS services accessed are supported by AWS. Support level might vary depending on the support plan owned by the customer.
Google SDK and Google services accessed are supported by Google. Support level might vary depending on the support plan owned by the customer.
Microsoft services accessed are supported by Microsoft.
Support for ABAP SDK for Azure is provided by email.
Support is provided by SAP and included as part of SAP Support agreement.
Source: Gartner (February 2026)
Additional extensibility options are available and may serve as viable alternatives to the SDKs and SAP BTP listed above for extending SAP applications in the cloud. Table 2 below illustrates that different top hyperscalers have chosen different approaches to achieve SAP extensibility:
  • AWS has prioritized a unified, programmatic SDK approach, enabling centralized consumption of its cloud services. The same SDK is also published within SAP BTP for customers in need to centralize the extensibility options within BTP.
  • Google has similarly adopted a unified programmatic SDK strategy, facilitating centralized access to cloud services and integration with SaaS offerings such as Google Workspace. Also, Google offers a BTP version of their SDK albeit with some limitations. Additionally, Google has developed select ad hoc connectors where they offer distinct advantages.
  • Microsoft has focused on purpose-built, ad hoc connectors and deep integration with its broader ecosystem, including seamless connectivity with Microsoft services such as Microsoft 365, Microsoft Sentinel and Defender, Microsoft Entra ID, and others.
Most SAP products provide a certain level of integration with SAP S/4HANA and other SAP solutions operating on the SAP ABAP Platform and SAP NetWeaver. In addition to the various extensibility options offered by cloud hyperscalers, Table 2 below highlights the most notable SAP products that enable extensibility within the SAP ERP environment.

Other Cloud Services for SAP Extensibility in the Public Cloud

Amazon Web Services
Google Cloud
Microsoft Azure
SAP BTP
Products for PaaS and SaaS extensibility
Amazon Q Developer for SAP ABAP
Amazon Quick Suite integration with SAP
AWS Glue support for SAP OData
BigQuery Connector for SAP
Cloud Data Fusion integrations for SAP
SAP BTP edition of ABAP SDK for Google Cloud
SDKs part of the ABAP SDK for Google Cloud:
AI Foundry and Copilot Integration
Fabric Data Integration
SAP and Microsoft integration scenarios
Joule Studio
SAP Build
SAP Business Data Cloud
SAP Integration Suite
A lower number of links or references in the table does not indicate a less comprehensive offering; rather, it reflects differences in how each provider presents and documents in different webpages their value-added services.
Source: Gartner (February 2026)

SAP Cloud Services Connectivity

Most of the solutions listed in Table 1 and Table 2 utilize private network endpoints,5— such as AWS VPC Endpoints, Google Cloud Private Service Connect, Azure VNET Service Endpoints, and Azure Private Link — to ensure egress-friendly, secure and low-latency connectivity. In contrast, SAP cloud services like SAP Business Technology Platform (BTP) and SAP Business Data Cloud rely on public internet connectivity. This is even when the BTP service is hosted within the same cloud provider and region as your SAP S/4HANA environment.
When planning to adopt SAP BTP for extending your SAP ERP functionalities, consider the potential impact of increased latency and egress costs in your planning and budgeting processes, especially if your use case involves regularly transferring large volumes of data. Additionally, SAP BTP’s deployment in a limited number of cloud regions may pose challenges related to latency, data sovereignty and data transfer costs

Success Measures

Organizations that properly design the best cloud architecture for their SAP ERP estate will benefit from a stable and resilient platform, minimizing the risk of unplanned disruptions during critical business operations. Additionally, by selecting the most suitable extensibility options for each use case, organizations can maintain their competitive edge leveraging best-of-breed solutions rather than committing exclusively to a single vendor.
Design a Cloud Aware Architecture for SAP Workloads:
  • Determine whether a scale-up approach is sufficient to meet your requirements, or if a scale-out architecture is necessary. Transitioning between these two architectures constitutes a significant project and has an impact on both your overall system architecture and your cloud resource reservations.
  • While many discussions focus on SLA percentages (e.g., 99.7%, 99.9%, etc.), their practical implications are often unclear to business stakeholders. Translate instead SLA percentages into human-understandable terms,6 (for example, a 99.7% SLA equates to 2 hours, 11 minutes, and 29 seconds of allowable downtime per month). SAP SLAs determine the watermark for service credits not the service RPO/RTO capabilities. Define acceptable outage windows and design an architecture that can reliably meet these requirements.
  • Assess the resiliency of your entire architecture holistically, rather than concentrating only on individual components or relying solely on SLA commitments from your MSP without verifying the supporting architectural design. Include in your architectural due diligence:
    • The overall cloud architecture and landing zone design.
    • Third-party interfaces and any other extensibility that are tightly integrated with your SAP estate.
    • Interconnectivity between your SAP cloud estate and your organization’s network, and with any extensibility applications you currently utilize or plan to implement in the future.
  • Conduct disaster recovery tests at least annually, though more frequent testing is recommended.
SAP Extensibility through cloud services:
  • Engage with your current cloud provider to assess their ability to deliver the technical capabilities required to support your extensibility objectives. Benchmark these offerings against those provided by other leading hyperscalers, as well as SAP.
  • When planning extensibility initiatives that are expected to deliver a significant business advantage to your organization, prioritize long-term vendor viability. Ensure that this consideration is embedded as one of the primary criteria in your decision-making process.
  • Review ongoing initiatives that address similar requirements — such as the enablement of GenAI-based features — where commercial and technical synergies, including indirect licensing for SAP or leveraging existing skills in programming languages beyond ABAP, may make an option more attractive than others.
This research is based on Gartner analyst expertise; vendor briefings with SAP, AWS, Microsoft and Google; and other sources, such as MSPs, system integrators and independent software vendors operating in the SAP on cloud market.

1 SAP regularly publishes and maintains a comprehensive set of SAP Notes for each supported cloud provider Refer to 1380654 - SAP support in IaaS environments, SAP for the most current list of supported cloud providers, as well as links to provider-specific notes detailing the support prerequisites for your chosen hyperscaler.

2 Each SAP-certified cloud hyperscaler provides dedicated SAP-specific documentation. For reference, below are links to the public documentation from the three leading hyperscalers by market share:

3 According to the Service Level Agreement for Private Cloud Edition Services and Tailored Option Services, SAP, the SLA is calculated per each SAP System: “System” means one or more interrelated and interdependent components such as databases, servers, networks, load balancers, web dispatchers, tenants, etc. which when taken as a whole are used to operate a tier. Each combination of components used within each tier is equivalent to one System. System Availability Percentage is measured at the tier level. For example, your SAP S/4HANA production instance is considered a “System.” So, it is your SAP S/4HANA Quality instance and so on.
4 As of now, ABAP SDK for Azure supports direct integration with following services:
  • Azure Blob Storage
  • Azure Cosmos DB
  • Azure Event Grid
  • Azure Event hubs
  • Azure Key Vault
  • Azure OpenAI
  • Azure Operations Management Suite Log Analytics
  • Azure Service Bus
  • Microsoft EntraID
  • Microsoft Graph API
  • Microsoft Graph API
  • Microsoft Office365 SharePoint
5 For detailed documentation on cloud network endpoints see:
6 Consider using an online tool such as uptime.is, to translate SLA percentages into human-understandable acceptable downtimes.