How to compare hyperscalers for RISE objectively.

The hyperscaler decision inside a RISE with SAP deployment is rarely made on the basis of evidence. It is made on the basis of the existing enterprise cloud relationship, the account team push, the SI partner preference, or the legacy assumption that one hyperscaler runs SAP better than the others. None of those inputs survives a structured comparison. The three major hyperscalers, AWS, Microsoft Azure, and Google Cloud Platform, each carry strengths and trade offs for SAP RISE workloads. The decision that holds across the seven year term is the decision that uses an evidence weighted framework, scored against the workload, and defensible against the board. This article walks the eight criteria the firm uses across every hyperscaler selection engagement.

Start by rejecting the account team supplied framework

The first artefact every hyperscaler conversation produces is a comparison slide from the favoured vendor. The slide is honest in what it claims and dishonest in what it omits. The numbers on the slide reflect a specific workload, often selected to favour the vendor presenting it, and they are not the numbers that will drive the buyer organisation cost across the seven year term. The buyer side discipline is to set the slide aside and to begin the comparison against the actual workload profile and the actual business case requirements.

The framework the firm uses has eight criteria, with each criterion weighted against the specific buyer context. The criteria are reserved capacity pricing, geographical region availability, data residency and sovereignty controls, network architecture and egress economics, native service availability outside the SAP perimeter, exit cost and portability, support and account engagement model, and existing enterprise commitment leverage. Each criterion is scored against documented evidence rather than against vendor claim, and the composite score produces a defensible recommendation.

Criterion one. Reserved capacity pricing against the actual workload

The reserved capacity pricing comparison is the single most consequential criterion for the seven year cost. Each of the three hyperscalers publishes reserved instance or committed use pricing for the workload categories that SAP RISE consumes. The differences between the three are material but not as material as the differences within each one across reserved tier, term length, payment structure, and region. The comparison the firm builds runs the actual workload profile through the published price calculators for each hyperscaler, with the three year and five year reserved tiers captured separately.

The actual delta between the lowest priced hyperscaler and the highest priced hyperscaler for a typical SAP RISE workload sits in the range of eight to fifteen percent on raw infrastructure cost across a seven year term. The number is significant but it is rarely the deciding factor on its own. The deciding factor is the combination of the raw price and the surrounding criteria that change the value of the price across the term.

Criterion two. Geographical region availability for the operating footprint

The geographical footprint of the three hyperscalers is different and the difference matters for organisations that operate across multiple regions. AWS carries the broadest global footprint with the most mature regional availability across Asia Pacific, Europe, and the Americas. Microsoft Azure has parity in most enterprise regions and a stronger footprint in some specific geographies that matter for public sector and regulated workloads. Google Cloud Platform has a narrower regional footprint but with strong availability in the regions where the platform is established.

The criterion matters because the SAP RISE workload runs in the hyperscaler region, and the region selection drives the latency, the cross region transfer cost, the data residency posture, and the regional failover architecture. The buyer side scoring captures the operating footprint, names the regions where the workload has to land, and scores each hyperscaler against the availability and the regional maturity in those specific regions. The comparison is not a global average, it is a region by region match against the named operating footprint.

Criterion three. Data residency and sovereignty controls

The data residency controls inside each hyperscaler have converged across the three major platforms, but the implementation differences are material for regulated organisations. The criteria the firm captures inside the comparison are the contractual residency commitment, the technical residency controls inside the platform, the certifications held in the named regions, the sovereign cloud offering available in the relevant geographies, and the data classification model the hyperscaler supports.

The decision turns on the regulatory exposure the organisation carries. Financial services organisations operating in the European Union score the sovereign offerings of each hyperscaler closely, including the partner sovereign cloud relationships that AWS and Microsoft hold with named European operators. Public sector organisations score the certifications held in the home country closely. The hyperscaler that scores best on this criterion for a US technology company is not the hyperscaler that scores best for a German financial services organisation, and the framework reflects that.

Criterion four. Network architecture and egress economics

The egress cost across the three hyperscalers carries material differences that surface across the seven year term for organisations with high cross region data movement, hybrid architecture interconnects, or backup and disaster recovery flows that move data outside the primary region. AWS publishes egress pricing that is lower than the Microsoft Azure rates in most regions, with Google Cloud Platform sitting between the two. The differences are bounded but they accumulate over time.

The buyer side scoring on this criterion models the expected egress profile across the seven year term, with attention to the hybrid architecture flows that will run from the RISE environment into the on premise systems that remain in place, the backup flows that move data to a separate region or a separate hyperscaler for disaster recovery, and the data analytics flows that may move RISE generated data into a separate platform for reporting. The composite egress cost across the term can shift the comparison by several percentage points and is rarely captured inside the account team supplied slide.

Criterion five. Native service availability for the workload roadmap

The SAP RISE workload runs inside the hyperscaler region, but the surrounding architecture often consumes hyperscaler native services that sit outside the SAP perimeter. The criterion captures the availability and the maturity of the native services that the buyer roadmap requires. The services typically scored are managed Kubernetes, managed databases for non SAP workloads, native data analytics platforms, native AI and machine learning services, and the developer tooling that the buyer team is expected to use across the term.

Criterion six. Exit cost and architectural portability

The exit cost criterion captures the cost and complexity of moving the RISE workload off the hyperscaler if the buyer organisation decides to switch hyperscalers at a future point. The three hyperscalers carry similar architectural patterns for SAP workloads, which means that the technical portability is comparable across them. The differences are in the commercial mechanisms, with each hyperscaler offering different incentives for migration in and different friction for migration out.

The buyer side scoring captures the data egress cost at exit, the architectural rebuild effort if any, the timeline to exit, and the commercial penalties associated with breaking the reserved capacity commitment ahead of term. The criterion is consequential because the hyperscaler decision inside a RISE deployment is a seven year commitment with material switching cost, and the criterion forces the comparison to capture the cost of being wrong rather than only the cost of being right.

Criterion seven. Support and account engagement model

The support model each hyperscaler offers for SAP workloads is different in structure and pricing. AWS runs a dedicated SAP competency programme and offers SAP specific support tiers with named technical account managers for enterprise customers. Microsoft Azure runs a similar programme with strong SAP integration through the partnership with SAP on the joint engineering work. Google Cloud Platform has a narrower SAP support footprint but with a strong technical bench for the workloads where the platform is established.

The criterion captures the support response time commitments, the SAP specific competency, the named account engagement, and the regional support availability for the operating footprint. The scoring differentiates between the marketing claim and the operational reality, with reference checks against existing SAP customers on each platform forming part of the evidence.

Criterion eight. Existing enterprise commitment leverage

The final criterion captures the existing enterprise commitment the buyer organisation already holds with each hyperscaler. The discount tier the organisation has negotiated, the unused committed spend that can be applied to the SAP RISE workload, and the contractual flexibility inside the existing enterprise agreement all bear on the effective cost of running RISE on each platform. The criterion is not a tiebreaker, it is a material input that can shift the composite score by several percentage points in either direction.

The eight criteria together produce a composite score that is documented, defensible, and reproducible. The recommendation that emerges from the framework is not always the obvious one. The firm has seen organisations that began the conversation expecting to deploy on the incumbent hyperscaler conclude with a different recommendation once the framework was applied. The discipline of the framework is that it forces the comparison onto evidence rather than preference, and the recommendation that survives the framework is the recommendation that holds across the seven year term. The hyperscaler decision is a seven year commercial commitment with material consequences for the cost, the architecture, and the operating model. The decision deserves a structured comparison rather than a slide deck.