Hyperscaler Selection for RISE with SAP Workloads.

The choice of hyperscaler inside a RISE with SAP contract is one of the most commercially consequential decisions a buyer makes during the negotiation, and one of the least examined. The SAP account team presents the three hyperscaler options as broadly equivalent, with implementation defaults already in place. In practice, the choice of AWS, Microsoft Azure, or Google Cloud changes the commercial economics, the performance profile, the integration map, the reserved capacity strategy, the exit posture, and the operating model implications of the seven year program. This pillar article walks through the buyer side framework for hyperscaler selection in RISE, the comparative analysis across the three major options, and the contractual mechanics that turn a selection into a defensible position.

Why hyperscaler selection matters inside RISE

The first instinct of many buyers is to treat the hyperscaler under RISE as a SAP problem. The argument is that SAP manages the platform, the buyer pays a per FUE subscription, and the underlying infrastructure is invisible. That argument is wrong. The hyperscaler choice changes the commercial structure of the program in three specific ways. It determines the price floor SAP can offer, because SAP procures hyperscaler capacity at different terms in each cloud. It shapes the integration cost with the rest of the buyer's estate, including data lakes, identity, networking, and analytics. It defines the exit profile in the event the buyer ever needs to leave RISE.

Across more than five hundred RISE engagements, the choice of hyperscaler has produced material differences in seven year TCO, sometimes in the order of ten to fifteen percent of the contract value. The differences come from infrastructure pricing under SAP's reseller terms, from network egress and data ingress patterns, from the ease of integration with the buyer's existing cloud estate, and from the operating model adjustments required to run SAP alongside the rest of the workload portfolio.

The choice is also load bearing for the rest of the cloud strategy. A buyer who runs analytics on Google Cloud, identity on Azure, and chooses AWS for RISE has built a three cloud operating model whether they intended to or not. A buyer who chooses the hyperscaler that aligns with the rest of their estate gets a consolidation effect that is invisible in the RISE proposal but very visible in the operating cost five years out.

The commercial mechanics that differ by hyperscaler

The commercial relationship between SAP and each hyperscaler is different, and the differences flow through to the buyer in ways that the proposal does not always make explicit. SAP procures committed capacity from each provider at terms negotiated separately, and the gross margin SAP earns on infrastructure varies across the three. That margin variation is the headroom the SAP account team has to discount specifically for the buyer's preferred hyperscaler.

Buyers who ask for the same RISE quote on each of the three hyperscalers tend to receive different prices, and the differences are not always proportional to the publicly stated list rates of each provider. The variation reflects the reseller margin SAP has on each platform, the regional capacity SAP has pre committed, and the time of quarter the proposal is built. A buyer who quotes for all three hyperscalers in parallel creates a competitive dynamic that the SAP account team has to respond to internally, and the response is usually visible as a price improvement.

The commercial conversation should also surface the reserved capacity that SAP holds at each hyperscaler. SAP commits to multi year reservations at AWS, Azure, and Google Cloud, and the reservation profile influences the prices SAP can offer. A region with abundant reserved capacity is cheaper to quote than a region where SAP is buying on demand. Buyers who understand the underlying capacity profile of each region are in a position to negotiate around it.

AWS as a RISE platform

AWS is the largest SAP RISE hyperscaler partner by absolute volume and the most mature operating environment for RISE deployments. The technical pattern for SAP HANA on AWS is well established, the regional footprint is broad, and the operating cadence is predictable. SAP has long running commercial agreements with AWS that include committed capacity tiers, which can translate into competitive pricing in specific regions.

The commercial profile of AWS as a RISE hyperscaler tends to favour buyers in North America, in Western Europe, and in select Asia Pacific regions where AWS capacity is plentiful. The regional footprint includes sovereign cloud options in some jurisdictions, which matter for regulated buyers. The integration map is strong for buyers who already operate analytics, machine learning, or data lakes on AWS, because data movement between RISE and the rest of the AWS estate stays within the provider's network and avoids egress charges that would apply across hyperscaler boundaries.

The buyer side considerations specific to AWS include the maturity of SAP service offerings on AWS, the breadth of the partner ecosystem for AWS managed SAP environments, the availability of SAP certified regions in the markets the buyer operates in, and the depth of the existing AWS commercial relationship. Buyers who already have material AWS commitments outside SAP, such as enterprise discount programmes or strategic supplier agreements, can sometimes blend the RISE workload into the broader AWS relationship for additional commercial leverage.

Microsoft Azure as a RISE platform

Microsoft Azure has the longest standing alliance with SAP at the strategic level, with public commitments around RISE that include go to market collaboration, joint product roadmaps, and reserved capacity programmes. The integration with the rest of the Microsoft estate, including Microsoft 365, Power Platform, and Azure AD, is the deepest of the three hyperscalers and is the most common reason buyers choose Azure as the RISE platform.

The commercial profile of Azure as a RISE hyperscaler tends to favour buyers who already have an enterprise agreement with Microsoft and who can leverage that relationship in the RISE conversation. The pattern that has produced consistent results is a parallel conversation, with Microsoft and SAP each aware that the buyer is talking to the other, and each willing to extend commercial concessions to ensure the RISE workload lands on Azure. The buyer is the only party that benefits from running the conversation in parallel.

Buyer side considerations specific to Azure include the regional footprint for SAP certified Azure regions, the sovereign cloud options available in specific jurisdictions, the integration with the buyer's existing Azure AD identity model, and the operational pattern of running SAP on Azure alongside other Microsoft workloads. The largest single risk in choosing Azure for RISE is the concentration risk it creates in a single strategic supplier, particularly for buyers who already run a significant share of their estate on Microsoft. The risk is manageable but should be priced into the seven year operating model.

Google Cloud as a RISE platform

Google Cloud is the youngest of the three RISE hyperscalers and the most commercially aggressive in specific regions. SAP and Google have invested in joint go to market activity, in joint engineering on SAP HANA on Google Cloud, and in regional capacity commitments. The result is that Google Cloud quotes for RISE are sometimes materially below the equivalent AWS or Azure quotes, particularly for buyers in regions where Google is investing in capacity growth.

The commercial advantage of Google Cloud often translates into an aggressive list price improvement at the proposal stage, sometimes combined with promotional credits, joint marketing, or accelerator funding. Buyers who quote Google Cloud as a primary option, even when they do not intend to choose it, create a useful price reference for the AWS and Azure conversations.

The buyer side considerations specific to Google Cloud include the regional footprint for SAP certified regions, which is narrower than AWS or Azure in some markets. The integration map for buyers whose data lakes and analytics estate already run on Google Cloud, which is the strongest case for the choice. The operating model maturity of Google Cloud for SAP, which is improving rapidly but is still earlier in the journey than AWS or Azure. The strategic question of whether the buyer wants a third strategic cloud relationship if AWS and Azure are already part of the estate.

The technical considerations that flow through to commercial outcomes

The technical evaluation of hyperscalers for RISE is often delegated to architecture teams that are looking for the right answer on performance, availability, and resilience. The commercial team should be in the room for the evaluation, because each technical decision creates a commercial implication that surfaces in the contract and in the operating cost over seven years.

Network architecture is the largest of these. The pattern of how the RISE tenancy connects to the rest of the buyer's network, how analytics and reporting consume RISE data, and how integrations exchange data with non SAP systems determines network cost over time. Buyers who model the egress, the ingress, and the cross region traffic before signing find their network cost is predictable. Buyers who do not model it find that network is one of the surprise lines on the year two operating bill.

Disaster recovery architecture is the next. The choice of cross region replication, the recovery point objective, and the recovery time objective each carry commercial implications under RISE. The RISE proposal usually quotes a default DR posture. Buyers with material business continuity requirements need to specify the posture in the contract and pay for it explicitly, rather than assuming the default meets their needs.

Identity and access management is the third. RISE integrates with the buyer's identity provider in patterns that vary by hyperscaler. Buyers with mature identity programmes find that the integration with one hyperscaler is materially cleaner than with the others. The cleaner integration translates into lower implementation cost, fewer ongoing identity management issues, and a faster end user provisioning process.

The contractual mechanics that protect the hyperscaler decision

Once the hyperscaler decision is made, the contract should commit to it explicitly. The RISE order form schedules should name the hyperscaler, the region, and the deployment topology. The schedules should also commit to the conditions under which the hyperscaler can change during the contract term, the buyer's consent rights over any change, and the commercial protections in the event SAP decides to migrate the RISE tenancy to a different provider.

The buyer should also write the data egress commitment into the order form. RISE termination is hard if data is held inside a hyperscaler tenancy that the buyer cannot extract under reasonable terms. The order form should commit to specific export formats, defined extraction time windows, and commercial terms for data egress that do not penalise the buyer for exiting.

Reserved capacity belongs in the same conversation. The buyer should understand the reserved capacity SAP holds at the chosen hyperscaler in the chosen region, the implications for performance and burst capacity, and the path to scale if business volumes grow. Reserved capacity is also a renewal lever. SAP's reserved capacity profile at each hyperscaler shifts over time, and the buyer who tracks the shifts has more leverage in renewal conversations than the buyer who treats hyperscaler as a fixed input.

Running a competitive process across hyperscalers

The single largest source of buyer leverage in RISE hyperscaler selection is a structured competitive process. The pattern that has produced consistent results in past engagements is a parallel RFP with all three hyperscalers, with SAP in the room for each conversation, and a documented evaluation framework that the buyer publishes to all parties.

The framework should be specific. Commercial terms over seven years, with explicit treatment of price, reserved capacity, and growth scenarios. Technical performance commitments, with named SLAs and committed remediation paths. Operating model fit, with a defined integration map to the rest of the buyer's estate. Strategic relationship, including joint roadmap visibility and executive sponsorship.

Buyers who run the process in parallel find that the final RISE proposal arrives at a different commercial level than the opening proposal. The improvement is the result of the competitive pressure. Buyers who allow SAP to nominate the hyperscaler, or who default to the hyperscaler the SAP account team prefers, give up the leverage that the parallel process creates. The cost of running the parallel process is small. The cost of not running it is consistently visible in the final contract terms.

Conclusion

Hyperscaler selection for RISE with SAP is one of the highest leverage decisions inside the negotiation. The choice of AWS, Microsoft Azure, or Google Cloud changes the commercial structure, the integration map, the operating model, and the exit profile of the seven year program. Buyers who treat the choice as a strategic supplier decision, run a parallel competitive process across the three providers, surface the technical considerations that flow through to commercial outcomes, and write the resulting decision into the order form arrive at RISE contracts that are materially better than the opening proposal. The instinct to treat hyperscaler as a SAP problem is the single most common reason buyer side leverage in this decision goes unused. The discipline to treat it as a buyer side decision is one of the highest return moves in the entire RISE negotiation.