RISE with SAP vs self-hosted on AWS: how to compare them honestly

RISE with SAP and self-hosted SAP on AWS solve overlapping problems with very different operating models. The cost ranges for both depend on more variables than any short comparison can cover honestly, so we leave the numbers to your actual quotes. What stays consistent across customers is the shape of the decision, and the clearest way to see it is to look at who owns which layer.

What each option is

RISE with SAP is a subscription private-cloud offering from SAP. SAP carries the SAP software layer, the database, and the underlying infrastructure, delivered on a hyperscaler of your choice within the available regions. You bring your processes, configuration, transports and custom code; SAP manages upgrades, patching, sizing, HA and backup within the contract scope.

Self-hosted SAP on AWS means you own the AWS account, the EC2 instances and the SAP application layer. SAP licenses stay on your side. You decide the operating model, the patch cadence, the HA topology and the DR posture, whether in-house or with a partner.

Who owns what

Cost is almost never the deciding factor by itself; the operating model is. This table is the fastest way to feel which model you actually want to live inside.

Read down the two columns: if most of what you want is in the "SAP" cells, RISE's operational simplicity is genuine. If you keep wanting the "you" column, meaning control over network, patch cadence and DR, self-hosting's flexibility is equally genuine. If you have a custom Basis operating model that works, RISE will ask you to change parts of it; some teams happily do, others cannot.

Where each tends to fit

The hybrid pattern that often wins

A pattern that fits many mid-size landscapes is RISE for the productive S/4HANA tier and self-hosted on AWS for non-production and analytical workloads.

The trade-off is real: you now operate two flavours of SAP infrastructure, which has a cost, especially for a small Basis team. The payoff is a clean SAP-warranty story on the productive tier, cheaper non-production, analytical tiers next to your data lake, and, if the platform supports it, one monitoring and audit surface across both.

Questions worth asking SAP about RISE

1. What is the FUE conversion ratio for your user mix, and when does it get recalculated?
2. How are patch windows scheduled, and what is the process for delaying one when a business event requires it?
3. What network topology is available between your VPCs and the RISE landscape, whether Direct Connect, Transit Gateway peering or VPN?
4. How do you export audit data, and how long does SAP retain it on its side?
5. What is the exit clause, and what migration support exists if you come off RISE later?

Questions worth asking AWS or your partner about self-hosting

1. Which EC2 family for your HANA sizing, and what is its roadmap over the next year or two?
2. What Reserved Instance and Savings Plan mix fits your steady-state versus variable workload?
3. What storage layout for /hana/data and /hana/log, and the trade-offs at your data volume?
4. What cross-AZ failover pattern is appropriate for HANA System Replication on your chosen EC2 family?

A sequencing that works

1. Define the operating model you want to live with, whether RISE-led, self-hosted or hybrid.
2. Build the cost model on your own numbers. Push back on vendor "average customer" estimates.
3. Run two short evaluations: a RISE sandbox tenant and a self-hosted sandbox account.
4. Choose. The longer the evaluation drags, the more the indecision costs.

How Farrenio fits

We are an AWS reseller for SAP-on-AWS workloads. We can model both options against your landscape, design the landing zone if you go self-hosted, as covered in the landing-zone checklist, and monitor either side from one console. If RISE is the right call for you, we will say so.

If you want help running the math, write to contact@farrenio.com with your system list, user count and data volume.