SAP on AWS in 2026: RISE vs Self-Managed, Sizing and Migration

Running SAP on AWS means deciding two things before any instance is sized: who operates the landscape (SAP through RISE with SAP, or your own team and a partner on AWS), and how you move there. This guide covers both, along with certified instance families, SAP HANA sizing, migration paths, high availability and disaster recovery, operations after go-live and cost levers. It reflects AWS and SAP documentation as of October 2026.

SAP on AWS: the two operating models

“SAP on AWS” covers two quite different arrangements. The two differ in who owns the contract, the cloud account and day-to-day operations.

• RISE with SAP S/4HANA Cloud, private edition (SAP Cloud ERP Private). SAP maintains responsibility for the holistic SLA, cloud operations and technical support, and you choose the cloud service provider. AWS documents that SAP owns and manages the AWS account where RISE is deployed and is responsible for security in the cloud. The setup is single-tenant, with customer environments isolated by AWS accounts and a dedicated VPC.
• Customer-managed SAP on AWS. You hold the SAP licences and the AWS account. You or a partner run the landscape on EC2. AWS states that most SAP solutions on AWS use bring-your-own-software and bring-your-own-licence: no special new SAP licence is needed, you must hold a valid SAP licence and stay compliant, and AWS does not sell SAP licences.

SAP’s product naming is also shifting. SAP’s 2026 service description guide is titled “SAP Cloud ERP Private, RISE with SAP S/4HANA Cloud, private edition and SAP ERP, private cloud edition”, and SAP’s October 2026 news uses “SAP Cloud ERP”. We use “RISE with SAP on AWS” below because it is still the phrase most buyers use.

Our SAP on AWS services page describes how Altivate supports both models. For the RISE side specifically, see our overview of RISE with SAP.

Why the timeline matters in 2026

SAP’s support site states that mainstream maintenance for the Business Suite 7 core applications, including SAP ERP 6.0 and ECC, ends on 31 December 2027. Optional extended maintenance runs from the start of 2028 to 31 December 2030 at a premium of two percentage points on the maintenance basis. SAP’s S/4HANA innovation commitment runs until the end of 2040.

In an article published on 7 October 2026, SAP CTO Philipp Herzig said these dates have not changed. He also set out several consequences of the 2030 date:

• SAP’s agreements with major third-party database providers, and its arrangements for Java 8 and NetWeaver AS Java 7.5, end at the same point.
• Conversions from Business Suite 7 on a third-party database to S/4HANA or SAP Cloud ERP are possible only before the end of 2030. After that, only greenfield is available.
• Moving to HANA does not extend maintenance.
• SAP advises completing the move to SAP Cloud ERP ideally by the end of 2030.

SAP also describes a Transition Option for SAP ERP, private edition: a time-bound subscription covering 2031 to 2033 for the largest, most complex customers. It requires the system to be on SAP ERP, private edition on SAP HANA before 31 December 2030 and does not support Java-dependent capabilities.

The practical reading: the operating-model and hosting decisions below should be settled early in it, not after the first sandbox is built. Our S/4HANA brownfield migration guide covers the conversion itself.

RISE with SAP on AWS vs self-managed SAP on AWS

The table summarises the differences that change day-to-day ownership. It draws on AWS’s RISE documentation and SAP’s service description guide; your own order form and contract govern the details.

On cost, treat vendor and buyer-side claims with care. Neither model is cheaper by default. Build a workload-specific model that includes licence terms, infrastructure, operations, DR and the cost of the skills you would need to keep in-house.

For the edition question that sits next to this one, see our guide on public versus private cloud edition for RISE with SAP.

Certified instance families and SAP HANA sizing on AWS

What “certified” means

AWS and SAP certify specific EC2 instance types for SAP. The authoritative lists are SAP Note 1656099, the SAP Certified and Supported SAP HANA Hardware Directory (filtered to IaaS), and AWS’s “SAP HANA certified and non-certified instances” page. Both SAP Notes require SAP portal access. Do not size from a blog post, including this one; use the live sources.

For in-memory SAP HANA databases, the AWS SAP Lens states that memory-optimised instances (the r, x and u families) are the only options. Within AWS’s certified-instance table, the current-generation scale-up families include:

Three cautions apply when you read the live table. First, OLTP and OLAP production support are flagged per row, and some rows differ on OLAP sizing (standard versus workload-based) or mark OLAP as unsupported, so check the row for your exact size. Second, AWS says certain families (X1, X2idn, X2iedn and High Memory) may not be available in every Availability Zone, so confirm availability in your target AZ, for example with the describe-instance-type-offerings CLI command. Third, previous-generation instances stay fully supported, but AWS recommends current-generation instances for new HANA implementations or migrations. All current and previous generation HANA instance types can run non-production workloads (SAP Note 2271345).

For scale-out, AWS’s certified current-generation rows are largely OLAP-only, with a maximum of 16 OLAP nodes. AWS lists the u-6tb1.56xlarge and u-6tb1.112xlarge for OLTP scale-out with a maximum of 4 nodes, and marks OLTP scale-out as unsupported on several other rows. Check the live table before committing to a scale-out topology.

A sizing method that survives review

1. Start from the workload, not the instance list. AWS’s SAP Lens recommends SAP Quick Sizer for greenfield or changed deployments, with technical and functional teams completing the inputs together. For a conversion of an existing system, the ABAP on HANA sizing report in SAP Note 1872170 is the referenced route (SAP portal access needed).
2. Validate the complex cases. Use SAP expert sizing for complex implementations and a proof of concept where you need to measure performance rather than estimate it.
3. Map the memory requirement to a certified row. Check the OLTP or OLAP flag, the OLAP sizing mode and the memory for that exact size in AWS’s table and the SAP hardware directory.
4. Confirm the instance exists in your target Availability Zone before you design the HA pair around it.
5. Right-size after go-live. For running systems, AWS recommends reviewing historical CloudWatch CPU and memory data. We cover the cost side below.

Support requirements to plan for from day one

AWS’s support requirements for SAP on AWS (SAP Note 1656250) are specific: enable detailed CloudWatch monitoring on each EC2 instance (one-minute metrics), install and run the AWS Data Provider for SAP on each instance, and hold an AWS Business Support or Enterprise Support plan on any account running SAP systems.

Migration paths to SAP on AWS

The migration route depends on where you start (ECC on anyDB, ECC on HANA, or an existing S/4HANA system) and where you are going (a self-managed S/4HANA on EC2, or RISE). AWS’s HANA migration documentation lists the options below. We separate infrastructure tools from conversion tools because the two are often confused.

What each term means for planning

• Homogeneous versus heterogeneous. Moving HANA to HANA keeps the database platform and can use HSR or backup and restore. Moving from Oracle, SQL Server or another database to HANA changes the database platform and uses DMO, system copy or DMOVE2S4.
• Bulk data transfer. AWS lists Snowball Edge and S3 Transfer Acceleration among the options for moving large volumes, and Direct Connect where network transfer is the plan.
• AWS Launch Wizard for SAP is a deployment tool, not a migration tool. It guides sizing, configuration and deployment, shows an estimated cost, provisions resources and can optionally install HANA and SAP software that you supply. It supports HANA single-node scale-up (up to 24 TB memory), scale-out, NetWeaver on HANA or ASE (single and distributed), cross-AZ HANA HA, cross-AZ NetWeaver setup, and SUSE or RHEL cluster configuration, and it is managed afterwards with AWS Systems Manager. It builds the target landscape; SUM, DMO or replication still moves the data.
• AWS Migration Hub Orchestrator. AWS’s HANA migration page still lists it, but AWS Migration Hub, including Orchestrator, closed to new customers on 7 November 2025. Existing customers can finish ongoing migrations, and AWS points new users to AWS Transform. We do not treat Orchestrator as an option for new SAP projects.
• AWS DMS. AWS’s documentation does not describe AWS Database Migration Service as an SAP migration path. The documented routes are SAP’s own: DMO (SUM), system copy and HSR-based methods. Be cautious of any plan that relies on DMS for an SAP system.

For network design, cutover planning and dependency mapping that sit around these tools, see our work on AWS cloud migration and modernization.

High availability and disaster recovery for SAP on AWS

AWS’s HA/DR documentation describes a range of patterns. The right choice is a business decision about downtime and data loss, not a technical default. Start by agreeing the RTO and RPO per system, then pick the cheapest pattern that meets them.

Some practical details from the documentation:

• HSR replication modes are sync on disk, sync in-memory and async. Operation modes are delta_datashipping, logreplay and logreplay_readaccess. The scenarios include active/passive and an active/active setup with a read-enabled secondary.
• The overlay IP can be routed through AWS Transit Gateway or a Network Load Balancer. Manual takeover is possible with HANA Cockpit, Studio or hdbnsutil.
• AWS Launch Wizard for SAP can automate the HSR and cluster deployment.
• AWS Backup supports SAP HANA databases on EC2, and later added HANA HA databases, cross-Region and cross-account copy, and PrivateLink. Region support varies and AWS’s earlier announcements excluded some Regions, including UAE, so verify current Region support before you rely on it in a Gulf Region.

AWS’s HA/DR testing guide maps failure scenarios to recovery methods: resource exhaustion, single points of failure, AZ or network failure, corruption or deletion, and Region failure. Corruption and Region failure are cross-Region, manual-decision cases. AWS recommends testing planned and unplanned outages of Pacemaker clusters before go-live, first without business data. A DR design that has never been exercised is a plan, not a capability. Our AWS migration and disaster recovery guide goes deeper on the testing side.

For RISE, the same ideas apply but the packaging differs. AWS’s RISE documentation describes Metro DR (multi-AZ, synchronous replication) and Regional DR (a second Region, asynchronous replication). It lists the availability SLA, RTO and RPO as the key requirements adjustable through option packages from SAP, and it defers definitions, clauses and penalties to the SAP RISE agreement. Read those clauses before you assume a number.

Operations and managed services after go-live

Go-live is where the work of owning an SAP landscape starts. In a customer-managed model, someone has to own the following, and none of it is automated by the cloud itself:

• Monitoring that meets AWS support terms. Detailed CloudWatch monitoring and the AWS Data Provider for SAP on every instance, as noted above.
• Backup verification. A backup that has never been restored is unverified. Schedule restore tests into the operating calendar.
• Cluster care. Pacemaker clusters need patching, failover testing and hook maintenance alongside the operating system and HANA.
• SAP Basis and application support. Transports, kernel and support-package maintenance, job monitoring, interfaces and incident response.
• Cost and capacity review. Right-sizing and commitment reviews on a regular cadence, as set out in the next section.

This is the work that managed services for SAP on AWS covers,. Whether you take it in-house, split it with a partner or hand it over entirely, write the split down: who is on call, who approves changes, and who owns the backup restore test. Our SAP application management services page describes how Altivate runs this work, and our piece on managed services built around outcomes rather than tickets explains the commercial model we prefer.

In a RISE model, SAP runs the cloud operations in scope, but the application layer, integration, data and the extension account around it still need an owner. AWS’s RISE guide has chapters on connectivity, security, reliability, observability, change management, data integration and analytics, agentic AI, and extensions, which is a useful checklist of what sits at the edge of the SAP-managed boundary. For data work around RISE, see our data and analytics on AWS page.

Cost levers for SAP on AWS

These levers come from the AWS SAP Lens and apply mainly to customer-managed landscapes. In RISE, your commercial terms are set in the SAP order form. We do not quote discount percentages because they depend on your commitment, Region and instance family.

• Plan the horizon before you commit. Estimate expected SAP usage over at least three years before buying Savings Plans or Reserved Instances.
• Match the commitment type to how stable the design is. EC2 Instance Savings Plans and Standard Reserved Instances are the highest-discount options. Compute Savings Plans or Convertible Reserved Instances suit components that are likely to change instance family.
• Remember capacity. Savings Plans do not reserve capacity. Pair them with On-Demand Capacity Reservations where you need guaranteed availability, which matters for large memory-optimised instances that are not offered in every AZ.
• Right-size on real usage. Use about three months of data that includes quarter-close peaks. AWS Compute Optimizer defaults to 14 days, and enhanced metrics extend that to three months. A 14-day window can miss the peak that the system must survive.
• Stop non-production when it is idle. Schedule stop and start with AWS Systems Manager or SAP Landscape Management.
• Review on-demand usage regularly, roughly monthly, so that steady workloads move onto commitments.
• Choose the DR pattern deliberately. A backup-and-restore design costs less than a continuously running cross-Region replica, and the trade is a longer RTO.

Where AWS Regions fit: Gulf and wider considerations

For customers in the Gulf, Region choice affects latency, data residency and DR design. AWS has existing Middle East Regions in Bahrain (launched 2019) and the UAE (2022). AWS says its first Saudi Arabia Region is on track to launch in December 2026, with three Availability Zones and more than US$5.3 billion of planned investment. As of October 2026 that Region is planned, not live, so re-check its status before you design around it. Confirm that the instance families you need, and the AWS services you rely on for backup and monitoring, are offered in the specific Region.

SAP on AWS or another hyperscaler?

Buyers often ask how AWS compares with Azure for SAP. We would frame the comparison on the facts that affect your landscape, not on general claims:

• Certification: for each provider, check the SAP Certified and Supported SAP HANA Hardware Directory for the exact sizes you need, in the Region you plan to use.
• Existing commitments: enterprise agreements, skills and licensing arrangements with a provider often decide the question.
• Region footprint and data residency: compare the Regions that meet your regulatory requirements.
• Surrounding services: where your analytics, integration and security tooling already live.
• Commercial model: under RISE you can choose the cloud service provider, so the question becomes which provider SAP offers in your geography and on what terms.

We run a neutral comparison on those points when we assess a landscape; the answer depends on your estate, not on a general ranking.

How to decide

Frequently asked questions

Can SAP HANA run on AWS?

Yes. AWS and SAP certify EC2 instance types for SAP HANA, including r-, x- and u-series families. The authoritative lists are SAP Note 1656099, the SAP HANA Hardware Directory and AWS’s certified-instance page. Check the row for your exact size, because OLTP and OLAP support are flagged per instance size.

Is RISE with SAP on AWS the same as running SAP on AWS myself?

No. In RISE, SAP owns and manages the AWS account and holds the holistic SLA, cloud operations and technical support. In a customer-managed model, you hold the account and the operating responsibility, and you need your own AWS Support plan for it.

Do I need to buy SAP licences from AWS?

No. AWS does not sell SAP licences. Most SAP solutions on AWS use bring-your-own-licence, so you must hold a valid SAP licence and stay compliant.

Which instance families are certified for SAP HANA?

AWS’s table includes r5/r5b, r6i, r7i and r8i, x2idn and x2iedn, x8i, and the High Memory u-series, with different memory limits by size. Treat any list in an article as a pointer, and confirm in the live AWS table and the SAP hardware directory, including availability in your target Availability Zone.

How do I size SAP HANA on AWS?

Use SAP Quick Sizer for new or changed deployments, the HANA sizing report in SAP Note 1872170 for existing ABAP systems, SAP expert sizing for complex cases and a proof of concept to measure performance. Then map the memory requirement to a certified row and right-size after go-live using CloudWatch data.

Can I use AWS Database Migration Service to move SAP?

AWS’s SAP documentation does not describe DMS as an SAP migration path. The documented routes are SAP’s own: SUM DMO, DMO with System Move, DMOVE2S4, classical system copy and HANA System Replication initialised from backup.

What does AWS Launch Wizard for SAP do?

It guides sizing, configuration and deployment, provisions the resources and can install HANA and SAP software that you supply. It also supports cross-AZ HANA HA and cluster configuration. It is a deployment tool and does not migrate or convert your data.

What availability can I get for SAP on AWS?

It depends on the pattern. A multi-AZ HANA pair with synchronous replication and Pacemaker targets near-zero RPO with recovery in minutes or less, according to AWS. For RISE, SAP defines the SLA, RTO and RPO in the order form and the service description, so read those documents rather than assuming a figure.

When must I move off ECC?

SAP states that mainstream maintenance for Business Suite 7 ends on 31 December 2027, with optional extended maintenance to 31 December 2030. SAP advises completing the move to SAP Cloud ERP ideally by the end of 2030.

Do you manage SAP on AWS after go-live?

Yes. Altivate provides SAP application management services for SAP landscapes, and our SAP on AWS services page describes our SAP on AWS services.

Altivate is an SAP Gold Partner and is ISO/IEC 27001 certified. Details of AWS and SAP terms in this guide were checked against their public documentation in October 2026 and can change, so confirm them against current sources and your contract before you decide. For the S/4HANA side of the programme, see our SAP S/4HANA page.