How to model RISE infrastructure cost across hyperscalers.

Hyperscaler infrastructure cost is the single largest variable inside a RISE with SAP TCO model. The choice of AWS, Azure, or Google Cloud changes the seven year cost by tens of millions of dollars on a typical enterprise workload, and the change is not always intuitive. List rates suggest that one provider is cheaper. Reserved instance pricing reshuffles the order. Network egress patterns flip it back. Region availability and zone redundancy bring still another set of variables. The buyer who models hyperscaler infrastructure cost as a single line in the RISE TCO will lose visibility into the largest commercial lever the deal contains. This article documents how to model RISE infrastructure cost across hyperscalers in a way that surfaces the real economics.

Decompose the workload before pricing it

The first error in cross hyperscaler modelling is to compare list prices on equivalent instance types and treat the resulting delta as the answer. The workload that RISE will host is not a uniform compute estate. It is a mix of application servers, database servers, batch processing nodes, integration runtimes, file storage, backup and archive, observability stack, and network ingress and egress. Each component has a different price curve across hyperscalers. The application server tier may favour one provider. The database tier may favour another. The storage and archive tier may favour a third.

The countermove is to decompose the workload into at least six pricing tiers and price each one separately, with the relevant instance family, storage class, and reserved capacity option for each. Aggregating up only after the component pricing is complete is the only way to see where each provider is actually cheaper.

Calibrate reserved capacity to commitment risk

Reserved instance pricing is the most powerful lever in cross hyperscaler comparison. A three year reserved commitment can reduce list pricing by forty to sixty percent depending on provider and region. The countermove to that leverage is to recognise that reserved capacity is a commitment, and a poor reserved capacity choice creates downstream cost in two ways. Underutilised capacity is paid for whether used or not. Overrun capacity is billed at list rate during the period when the reservation does not cover it.

A defensible RISE infrastructure model calibrates reserved capacity to confirmed steady state load, not to peak. The peak load runs on on demand pricing or on burst capacity. The steady state runs on reserved capacity at the longest commitment that aligns with the RISE term itself. The buyer who reserves to peak will pay for reserved capacity that sits unused. The buyer who reserves nothing will pay list rate for everything.

Model network and egress separately

Network and egress cost is the cost line that breaks RISE infrastructure models. Compute and storage are predictable. Egress is not. A workload that exchanges large data volumes with external systems, that backs up to a different cloud, or that supports a global user base with traffic crossing region boundaries, can generate egress charges that are a meaningful percentage of total infrastructure spend. The hyperscaler that looked cheapest on compute may not be cheapest once egress is included.

The countermove is to model network and egress as a separate line in the cross hyperscaler comparison, with a defensible egress volume estimate based on three years of actual traffic from the existing estate. The estimate will be wrong, but it will be wrong by a measurable amount, and the comparison will surface which provider's egress pricing structure is most aligned with the buyer's actual traffic pattern.

Account for region availability

Not every hyperscaler offers every region with full RISE certification. The buyer who needs production capacity in a specific country, for data residency or performance reasons, will find that one or more providers do not offer a certified region or offer it only in a primary plus disaster recovery configuration that has a different price curve from the standard region pairs. This is not a minor technical detail. It can be the difference between a clean three year reserved commitment and a complex multi region configuration with paired capacity.

The countermove is to map the buyer's required regions against each hyperscaler's certified RISE region availability before pricing. A provider that does not offer a certified region in a required jurisdiction is excluded from the comparison. The comparison runs only across providers that can deliver the full geographic footprint.

Stress test against price shifts

Hyperscaler pricing is not static. Each provider has shifted compute and storage pricing several times in the past five years, sometimes by meaningful percentages. A model that prices the seven year RISE term at current rates is exposed to provider side price changes the buyer cannot control. The countermove is to stress test the model against price shift scenarios. A ten percent compute price increase in year three. A fifteen percent storage price increase in year four. A doubling of egress rates in year five. None of these scenarios are predictions. They are exposure tests.

The output of the stress test is not a single number but a range. The range shows the buyer how durable each hyperscaler choice is against the kinds of price moves the provider has made in the past. A provider with a tighter range under stress is, in commercial terms, the lower risk choice even if its current pricing is slightly higher.

Surface the lock in cost

The final variable in cross hyperscaler modelling is lock in. A buyer who selects a hyperscaler for the RISE deployment is committing to that provider's storage formats, networking patterns, identity model, and integration tooling. Migration off that provider, three years later, is not a software migration. It is a re platforming exercise with significant cost. The TCO model should include an estimate of migration cost away from the chosen provider, as a contingency line, so the buyer understands the embedded switching cost.

The countermove is to require, in the RISE contract itself, that the contract supports a hyperscaler change with defined transition terms. The lock in cannot be eliminated, but it can be made visible and partially mitigated through contract language that requires SAP cooperation with a future provider change.

Conclusion

Cross hyperscaler modelling inside the RISE TCO is not a comparison of three list prices. It is a decomposed exercise across compute, storage, network, egress, region availability, reserved capacity strategy, price shift exposure, and lock in cost. A buyer who runs the decomposed exercise will produce a hyperscaler recommendation that is defensible against the executive committee and durable against the seven year term. A buyer who runs the simple list price comparison will pick a provider on a number that does not survive contact with the actual workload. The work is more involved, but the financial difference is large enough that the work pays for itself many times over.