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 will leave the numbers to your actual quotes. What stays consistent across customers is the shape of the decision.

This is a working summary of how to compare them.

What each option is

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

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

Where the choice is actually made

Cost is almost never the deciding factor by itself. The operating model is.

• If your priority is to operate less and to have a single contractual line of responsibility for the SAP layer, RISE leans more attractive. The operational simplicity is genuine.
• If your priority is control over the operating model, the network architecture, the patch cadence and the integrations with the rest of your platform, self-hosting on AWS leans more attractive. The flexibility is genuine.
• If you have an existing custom Basis operating model that works for you, RISE will ask you to change parts of it. Some teams happily do; others cannot.

Once the operating-model question is answered, the cost work follows: model your actual workloads, your peak users, your data volumes, and your HA and DR targets against the two options. The numbers that come back will be specific to your case.

Where RISE tends to fit well

• You want SAP to carry SAP-layer support, including database patches and incident response inside the SAP stack.
• Predictable subscription billing is a finance preference rather than a procurement detail.
• You are starting a clean S/4HANA implementation and want the infrastructure decisions made for you.
• Your in-house Basis bench is small and you would rather invest its time in transformation than in operations.

Where self-hosted on AWS tends to fit well

• You want SAP in the same network as your data lake, analytics, custom integrations or non-SAP systems, with the latency profile that comes with that.
• You expect to compress cost over time by right-sizing, reserving capacity and lifecycling storage.
• You want flexibility on patch windows, HA topology and DR strategy.
• You operate SAP for multiple customers and want shared platform economics across them.

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 the non-production tier and any analytical workloads.

• RISE gives finance and audit a clean SAP-warranty story for the productive tier.
• Self-hosted dev, QAS and sandbox systems cost less when sized down or shut down off-hours.
• Analytical tiers, replication targets and custom HANA workloads live next to your data lake on AWS.
• One monitoring and audit surface can cover both sides if the platform supports it.

The trade-off is operating two flavours of SAP infrastructure. That has a cost, especially for small Basis teams.

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. Direct Connect, Transit Gateway peering, 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 is available if you choose to 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 is the right Reserved Instance and Savings Plan mix for 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. 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 the self-hosted route, 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.