SAP and AWS have invested heavily in their partnership, and for good reason: SAP's software runs on AWS infrastructure for hundreds of enterprises worldwide. AWS is SAP-certified for HANA, S/4HANA, BW/4HANA, and the full portfolio of SAP applications. What the partnership brochures do not fully explain is the licensing complexity that enterprise buyers must navigate when migrating — or expanding — their SAP footprint on AWS.
We have advised on more than 80 SAP on AWS engagements. The commercial risks are consistent and avoidable. This guide covers what you need to know before signing anything.
Bring Your Own Licence: What It Really Means
The Bring Your Own Licence (BYOL) model is the default assumption for most enterprises moving SAP to AWS. You continue paying SAP for your software licences and support under your existing SAP agreement. AWS charges separately for infrastructure (EC2 instances, storage, networking). In theory, it is straightforward.
The Cloud Deployment Rights Trap
The first thing to verify is whether your existing SAP licence agreement actually permits cloud deployment. SAP licence agreements signed before 2018 often contain on-premises deployment restrictions or are silent on cloud infrastructure. Running SAP on AWS under such an agreement — even with AWS certification — may technically constitute a licence breach.
SAP is generally willing to add cloud deployment rights through a contract amendment, but this amendment process creates a renegotiation opportunity for SAP. Organisations that approach SAP requesting a contract amendment without a clear commercial strategy often find that SAP uses the process to push price increases, expand the scope of the agreement, or introduce new products.
"Before any SAP workload moves to AWS, conduct a formal licence agreement review. The cost of the review is trivial compared to the risk of triggering an unplanned contract renegotiation from a position of technical dependency."
Named User and Processor Metric Portability
SAP licences are metric-based — Named User licences are tied to individuals who access the system, while Processor licences are based on the number of active processors in the SAP landscape. Both metrics are theoretically portable to cloud deployments, but the practical application is more nuanced. In an AWS environment, virtual processors (vCPUs) map to SAP processor metrics in ways that can increase your licence requirement — or expose you to compliance exposure — if you are not careful during sizing.
SAP's policy on virtualisation and processor counting has evolved significantly. Always confirm the current SAP policy with SAP directly, in writing, before finalising your AWS infrastructure architecture.
Contract Review Before You Migrate
A structured SAP licence agreement review before migration should cover five areas: cloud deployment rights (explicit confirmation that AWS is an authorised deployment platform), virtualisation rules (how SAP counts processors in your specific AWS configuration), geographic restrictions (some SAP licence agreements contain deployment geography restrictions that affect which AWS regions you can use), third-party access provisions (cloud deployments often introduce new integration patterns that need to be evaluated against SAP's third-party and indirect access rules), and audit clause mechanics (understanding how SAP would conduct an audit of your AWS deployment differs meaningfully from an on-premises audit scenario).
RISE with SAP on AWS vs BYOL: Commercial Comparison
RISE with SAP is SAP's managed cloud offering. When a customer chooses RISE on AWS infrastructure, SAP manages the entire stack — HANA database, S/4HANA application, BTP platform entitlements, and the underlying AWS infrastructure — under a single SAP subscription contract. This is fundamentally different from the BYOL model, where the customer holds separate SAP licence and AWS infrastructure contracts.
| Dimension | RISE with SAP (AWS) | SAP BYOL on AWS |
|---|---|---|
| Commercial relationship | Single contract with SAP | Separate SAP licence + AWS contracts |
| Infrastructure visibility | Bundled — AWS costs not transparent | Full visibility and control of AWS spend |
| Customisation flexibility | Limited by RISE terms | Full control over architecture |
| Support accountability | SAP responsible end-to-end | Split between SAP (software) and AWS (infra) |
| Typical total cost (large enterprise) | Generally higher at scale | Generally lower with optimisation |
| Negotiation complexity | Complex RISE commercial model | Two separate negotiation tracks |
For most large enterprises with complex, customised SAP landscapes, BYOL on AWS with specialist commercial advisory support tends to deliver better commercial outcomes than RISE. The key advantage is commercial transparency: with BYOL, you know exactly what you are paying SAP and what you are paying AWS, and you can optimise both independently.
RISE makes more sense for organisations that have straightforward, lightly customised SAP landscapes and want to reduce operational complexity. For a detailed assessment of whether RISE is right for your organisation, see our guide to SAP RISE Contract Negotiation.
Indirect Access Risk in the Cloud
Cloud deployments tend to introduce more integration points than on-premises deployments. APIs, middleware layers, third-party analytics tools, and data integration platforms all potentially represent indirect access exposure under SAP's licence terms. The SAP Digital Access model — which replaced the older indirect access model for S/4HANA — charges on a document-based metric rather than a user-based metric. However, older SAP ECC and ERP deployments on AWS may still be subject to the older indirect access framework.
Before migrating to AWS, conduct an integration mapping exercise. Document every system that reads from or writes to your SAP database. Evaluate each integration against your current SAP licence terms. This is particularly important for organisations running analytics platforms, data warehouses, or RPA solutions that interact with SAP data — all of which are potential indirect access exposure points. See our detailed guide on SAP Indirect Access Licensing for the full framework.
SAP Support in an AWS Deployment
In a BYOL deployment, your SAP support contract remains entirely separate from your AWS relationship. SAP Enterprise Support (or Premium Engagement, or the PSLE tier) covers SAP software defects, patches, and system access. AWS provides infrastructure support through its own support plans. When something goes wrong in your SAP on AWS environment, the question of whether it is a SAP software issue or an AWS infrastructure issue is not always clear — and finger-pointing between vendors can extend resolution times significantly.
Third-Party Support Considerations
Some organisations running SAP on AWS use third-party support providers such as Rimini Street to reduce SAP support costs — typically by 40–60% relative to SAP's standard support fees. Third-party support is fully compatible with AWS infrastructure deployments, but the contractual terms of third-party support agreements should be reviewed for any cloud deployment restrictions before migrating. See our article on SAP S/4HANA Migration Negotiation for more context on the support transition landscape.
Negotiating SAP and AWS Together
One of the most consistently underutilised strategies for enterprises running SAP on AWS is the coordinated negotiation of both agreements. SAP and AWS have a deep commercial partnership — SAP is one of AWS's largest software partners, and AWS is one of SAP's preferred cloud platforms. This interdependence creates commercial leverage for the buyer that is rarely exploited.
AWS EDP as SAP Leverage
AWS's Enterprise Discount Programme (EDP) is a multi-year committed spend agreement that delivers infrastructure discounts of 10–30% depending on commitment level. When negotiating your EDP, the size of your SAP on AWS workload is a material factor in the AWS EDP economics. Conversely, your AWS commitment can strengthen your negotiating position with SAP — particularly if you are a large AWS customer whose SAP workload represents a significant portion of SAP's own cloud revenue.
Coordinating the timing of your SAP and AWS negotiations — rather than renewing each independently — allows you to use each vendor's commercial interest in the other as leverage. This is a complex negotiation to run without specialist support, but the savings can be material: we have seen coordinated negotiations deliver an additional 8–15% improvement on SAP software costs relative to isolated SAP-only negotiations.
MACC Credits and SAP Software
Microsoft's Azure Commitment (MACC) has a well-known mechanism for offsetting software costs via marketplace commitments. AWS has an equivalent mechanism through AWS Marketplace — SAP software available through the AWS Marketplace can potentially draw down against your committed EDP spend. The practical application of this depends on SAP's AWS Marketplace listing terms for your specific products, and the commercial benefit is not universal, but it is worth evaluating during your joint negotiation.
True Cost Modelling for SAP on AWS
A complete cost model for SAP on AWS should include: SAP licence fees (current and projected under renewal terms), SAP support fees (at current or reduced rates if third-party support is being evaluated), AWS EC2 instance costs for the SAP landscape (applying Reserved Instance or Savings Plan discounts), AWS storage costs for HANA data volumes, AWS networking and egress costs (often underestimated in initial SAP migration business cases), AWS Managed Services or System Integrator costs for ongoing operations, and internal staffing or managed service costs for SAP Basis and BASIS administration in the cloud.
The most common modelling error we see is the failure to account for AWS Reserved Instance or Savings Plan optimisation on the SAP workload. SAP HANA instances are typically large, predictable, long-running workloads — the ideal candidate for 1–3 year Reserved Instance commitments that can reduce instance costs by 30–50%. Organisations that migrate to AWS without locking in these commitments at the time of migration typically overpay on infrastructure for 12–18 months before someone notices.
"The infrastructure savings from Reserved Instances on SAP HANA workloads are almost always larger than the negotiated discount on the SAP licence itself. Get your AWS RI strategy right before you focus on SAP price negotiations."
What to Do Next
If you are planning a SAP migration to AWS or approaching your SAP or AWS renewal, the following actions will position you most favourably: conduct a formal SAP licence agreement review to confirm cloud deployment rights before architecture decisions are made; model RISE vs BYOL under your specific cost assumptions with full transparency on AWS infrastructure pricing; evaluate third-party support as a cost reduction lever if your organisation is on SAP ECC or older S/4HANA; coordinate the timing of your SAP and AWS renewals to maximise cross-leverage; and engage specialist advisory support before either vendor's account team begins their commercial process.
For a detailed review of your SAP licence position and AWS commercial terms, contact our team. We have advised on more than 80 SAP on cloud engagements and have deep familiarity with both SAP's and AWS's commercial frameworks. See our related SAP S/4HANA Migration Guide for the full strategic framework.
Frequently Asked Questions
Can I use my existing SAP licences on AWS?
Yes, under SAP's BYOL model — provided your licence agreement includes cloud deployment rights. Older agreements may require a contract amendment. Review your agreement before migrating to avoid triggering an unplanned commercial renegotiation from a position of technical dependency.
How does RISE with SAP differ from BYOL on AWS?
RISE is SAP's managed cloud subscription bundling infrastructure, software, and BTP under one SAP contract. BYOL keeps SAP and AWS as separate commercial relationships. BYOL typically delivers better commercial visibility and total cost outcomes for large enterprises; RISE simplifies operations but reduces transparency. See our RISE Contract Negotiation guide for a full comparison.
Does moving SAP to AWS affect our SAP support costs?
In the BYOL model, no — your SAP support fees are governed by your SAP agreement, not your infrastructure platform. If migrating to RISE, Enterprise Support is bundled in. Third-party support providers are compatible with AWS deployments and can deliver 40–60% support cost reductions for organisations on stable SAP versions.
Can we negotiate SAP and AWS contracts together?
Yes, and this is one of the most valuable strategies available. Coordinated negotiations exploit the commercial interdependence between SAP and AWS. We have seen coordinated negotiations deliver 8–15% additional improvement on SAP software costs versus isolated negotiations. Specialist advisory support is required to execute this effectively.