AWS and SAP have maintained a close partnership for over a decade — AWS is a certified infrastructure provider for SAP workloads, and SAP's own RISE with SAP offering is available deployed on AWS infrastructure. Despite this partnership, the licensing rules governing SAP software running on AWS EC2 are non-trivial, and organisations that move SAP workloads to AWS without adequate licensing analysis regularly find themselves in breach of their SAP licence agreements.
The core issue is processor counting. SAP on-premise licences are sized against physical processor cores. When those same SAP workloads run on AWS EC2 instances, the question of what constitutes a "processor core" for SAP licensing purposes becomes complex — and the answer has significant cost implications.
How SAP Counts Processors on AWS EC2
SAP's licensing metric for most on-premise products (ERP, S/4HANA, BW, Basis) is the physical processor core — specifically, the number of processor cores in the hardware environment running the SAP software. On dedicated physical hardware, this count is straightforward. On AWS EC2, it is not.
SAP treats each vCPU in an EC2 instance as equivalent to one physical processor core for licensing purposes — unless the instance is deployed on a Dedicated Host. This distinction is commercially critical: an EC2 instance with 64 vCPUs generates a 64-core SAP licence requirement, even if a comparable physical server would deliver the same performance with 16 physical cores.
The vCPU-to-Core Problem
AWS's Intel-based EC2 instances use hyperthreading, meaning each physical core presents as two vCPUs. For AWS billing and instance sizing purposes, all vCPUs are counted. For SAP licensing purposes, SAP historically required customers to count all vCPUs as processor cores — even where hyperthreading meant the physical core count was half the vCPU count.
This created a significant licensing penalty for SAP customers moving to AWS compared to dedicated on-premise hardware. SAP has updated its virtualisation guidance to allow core-factor adjustments in specific configurations, but the application of these adjustments requires careful contractual and technical verification. Without explicit SAP approval in your licence agreement, defaulting to vCPU-equals-core is the conservative and compliant position.
Compliance Risk: In SAP audit findings we have reviewed, the most common AWS-related finding is insufficient processor licences — specifically, customers who sized their SAP licences against physical cores but deployed on standard (shared-tenancy) EC2 instances without obtaining SAP's written acknowledgement of a core-factor adjustment. The audit remediation cost in these cases typically runs 2–4× the cost of simply licensing correctly at deployment. Advisory firms including Redress Compliance conduct pre-migration licence sizing reviews for SAP customers moving to AWS to prevent this outcome.
SAP on AWS: Three Deployment Models and Their Licensing Implications
Model 1: BYOL on Standard EC2 (Shared Tenancy)
The most common initial approach — customers lift their existing SAP licences and deploy on standard EC2 instances. This is the simplest operationally but creates the most licensing risk. SAP licence fees are calculated on vCPU count (not physical cores), which typically means 2× the licence requirement compared to equivalent on-premise hardware. For a significant SAP estate, this can represent millions in additional licence fees that customers simply do not anticipate when migration planning begins.
Model 2: BYOL on Dedicated Hosts
AWS Dedicated Hosts provide dedicated physical servers, allowing customers to use physical core counts (not vCPU counts) for SAP licensing purposes. This addresses the core-counting penalty but at a higher infrastructure cost — Dedicated Hosts typically run 15–30% more expensive than equivalent on-demand EC2 capacity. The commercial question is whether the SAP licence saving justifies the infrastructure premium. For large SAP estates with significant processor licence exposure, Dedicated Hosts consistently produce better overall TCO.
Model 3: RISE with SAP on AWS
RISE with SAP on AWS is SAP's managed cloud ERP offering, where SAP takes responsibility for the underlying infrastructure (running on AWS) and the customer pays a subscription fee rather than maintaining processor licences. Under RISE, the processor licensing complexity is eliminated — it becomes SAP's problem, absorbed into the subscription price. The commercial question shifts to whether the RISE subscription price represents better TCO than BYOL on AWS plus infrastructure and operational costs. See our RISE with SAP Negotiation guide for the full economics.
| Deployment Model | Licence Basis | Relative Infrastructure Cost | Compliance Complexity |
|---|---|---|---|
| BYOL – Standard EC2 | vCPU count (2× physical) | Lowest | High — vCPU counting, audit risk |
| BYOL – Dedicated Hosts | Physical core count | Medium (+15–30%) | Low — clean physical count |
| RISE with SAP on AWS | Subscription (no BYOL) | Highest (fully managed) | None (SAP responsibility) |
| BYOL – AWS Nitro-based with adjustment | Core-factor adjusted | Low to medium | Medium — requires SAP approval |
SAP Named User Licences on AWS
Named user licences are not affected by the infrastructure platform — they are user-based, not processor-based. An organisation's SAP Professional User, Limited Professional User, and Employee User counts remain the same whether SAP runs on-premise or on AWS EC2. The platform migration does not create user licence exposure, but it can create opportunities to review and rationalise user licence counts at the same time as the infrastructure migration.
AWS EDP and SAP RISE: The Dual Commitment Problem
Many enterprise organisations running SAP on AWS have both an AWS Enterprise Discount Programme (EDP) commitment and a separate SAP RISE or BTP subscription commitment. These create a complex interplay: AWS EDP commitments may not count RISE subscription payments toward the EDP threshold, and RISE subscription fees paid to SAP (which deploys on AWS infrastructure) may not satisfy the customer's direct AWS spend commitment.
Before signing a RISE with SAP on AWS agreement, organisations should obtain written clarification from both SAP and AWS on how RISE payments are treated relative to any existing AWS EDP commitments. The failure to clarify this early has led to organisations discovering they owe AWS shortfall fees at EDP true-up because RISE payments did not count toward their EDP threshold.
SAP HANA on AWS: Certification and Sizing
SAP HANA has specific hardware certification requirements — SAP maintains a published list of certified AWS EC2 instance types for HANA workloads. Using uncertified instance types is a licence compliance issue and voids SAP support obligations. When sizing HANA on AWS, organisations must use certified instance types from SAP's current certification matrix, which is updated periodically as new EC2 instance families are certified.
The certified instance types for HANA are predominantly in the x1, x2, u-, and hpc families — high-memory instances that provide the RAM required for HANA's in-memory architecture. These are not the least expensive EC2 instance types, and this infrastructure cost reality should be factored into any HANA-on-AWS business case.
Pre-Migration Licence Review: What to Do Before Moving SAP to AWS
The following steps reduce compliance risk and optimise total cost when migrating SAP to AWS:
- Current licence audit: Document your existing SAP processor licences, including the physical hardware specifications on which they were originally sized. This establishes the baseline for the AWS deployment calculation.
- Deployment architecture decision: Decide between shared-tenancy EC2, Dedicated Hosts, and RISE before proceeding — each has fundamentally different licence implications and the decision should be made before infrastructure procurement.
- SAP written confirmation: If planning to use core-factor adjustments or Nitro-based instance counting, obtain written confirmation from SAP in your licence agreement before deployment. Verbal assurances from SAP account teams are not enforceable.
- HANA certification check: Verify that intended EC2 instance types are on SAP's current HANA certification matrix for your HANA version before commitment.
- AWS EDP alignment: If you have an AWS EDP commitment, clarify how SAP RISE or BTP payments are treated against your EDP threshold before signing RISE.
For comprehensive SAP on AWS advisory — including pre-migration licence review, RISE TCO analysis, and audit risk assessment — our cloud contract negotiation and software licensing advisory practices provide expert support. Download our Cloud Contract Framework for the full SAP cloud migration licensing checklist. See also our complete SAP Licensing Guide and articles on SAP HANA Licensing and RISE with SAP Negotiation.