Choosing between AWS and Azure for your SAP workloads is a strategic infrastructure decision with significant commercial implications. Instance economics, hyperscaler partnerships with SAP, migration incentives, and the RISE infrastructure choice all factor into a decision that will govern your SAP infrastructure costs for a decade.
SAP maintains its own certification programme for cloud infrastructure, validating specific instance types from each hyperscaler as certified to run SAP HANA and SAP NetWeaver/S/4HANA workloads. Only instances on SAP's certified list are supported for production SAP HANA deployments under SAP's standard support terms. Running SAP HANA on uncertified infrastructure — regardless of how powerful it is — may void your SAP support entitlement for that environment.
Both AWS and Azure maintain comprehensive catalogues of SAP-certified instances covering a wide range of memory sizes (from 192 GB for smaller S/4HANA deployments up to 24 TB for the very largest HANA databases). The certification parity between the two platforms is high — both offer comparable compute coverage for SAP workloads, making the infrastructure capability difference between them less significant than the commercial and strategic differences.
This guide is part of our comprehensive SAP license negotiation guide. For the RISE commercial framework that governs managed SAP deployments on hyperscaler infrastructure, see our RISE with SAP review.
SAP HANA's in-memory architecture places high demands on instance memory. The correct instance family for a given HANA database depends on the HANA database size, the workload type (OLTP vs mixed OLAP/OLTP), and the target SLA for system availability.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
AWS offers HANA-certified instances across several families. The x1e family offers up to 3.84 TB of RAM in a single instance and is certified for scale-up HANA deployments of very large databases. The u- (high memory) instances extend to 24 TB through a bare metal architecture, suitable for the largest SAP HANA databases in a scale-up configuration. For scale-out HANA (distributing a single database across multiple nodes), the r5 and r6i families provide the density-performance balance that SAP recommends.
AWS's Dedicated Hosts option allows SAP customers to run HANA on dedicated physical infrastructure — relevant for licensing (Oracle licences on AWS, for example, require specific host-level arrangements) and for compliance scenarios requiring physical isolation.
Azure offers two tiers of SAP HANA infrastructure. Standard Azure virtual machines include HANA-certified instances from the M-series (up to 12 TB RAM) and Mv2-series (up to 12 TB RAM in VMs, up to 24 TB in specific configurations), delivering the HANA memory requirements for large enterprise deployments within a standard virtual machine environment. For the very largest HANA databases and highest SLA requirements, Azure also offers HANA Large Instances (HLI) — bare metal hardware managed by Microsoft in dedicated data centre space, sized from 2 TB to over 20 TB, and certified for scale-up HANA deployments.
| Dimension | AWS | Azure |
|---|---|---|
| Max scale-up HANA RAM (VM) | 24 TB (u- bare metal) | 24 TB (HLI bare metal) |
| Standard VM HANA max | ~6 TB (x1e.32xlarge) | ~12 TB (Mv2) |
| Certified instance families | x1, x1e, x2, u-, r5, r6i, r7i | M-series, Mv2, HLI |
| Scale-out HANA support | Yes (r5/r6i families) | Yes (M-series) |
| Bare metal options | Yes (u- family) | Yes (HLI) |
| HANA Reserved Instances | 1 and 3-year RIs | 1 and 3-year reservations |
SAP has strategic partnerships with all three major hyperscalers — AWS, Azure, and GCP — each with different commercial histories and current strategic emphasis. Understanding the nature of each partnership affects how you can leverage hyperscaler and SAP relationships in commercial negotiations.
AWS and SAP have maintained a strategic partnership since 2011, and AWS is the largest hyperscaler by SAP HANA certified instance coverage and market share for self-managed SAP deployments. The SAP on AWS partnership includes joint co-sell arrangements (SAP account teams and AWS account teams jointly selling SAP workloads on AWS), AWS Marketplace availability for some SAP products, and AWS migration funding programmes for customers moving SAP workloads from on-premise to AWS.
AWS's SAP competency programme validates a large network of system integrators and migration partners who are certified to run SAP migration projects on AWS infrastructure — providing broad partner ecosystem access for SAP transformation projects.
Microsoft Azure and SAP have one of the closest partnerships in enterprise technology. The SAP on Azure partnership goes beyond infrastructure to include deep product integration: SAP BTP services are available within the Azure Marketplace, SAP and Microsoft jointly sell to enterprise accounts, and there are specific product integrations between SAP applications and Microsoft 365, Teams, and Azure AI services.
For organisations already running significant Microsoft workloads on Azure, the SAP-Microsoft partnership creates potential commercial synergies — Azure spend for SAP workloads may count towards Microsoft Azure Committed Spend (MACC) thresholds, unlocking Enterprise Agreement discounts across both Microsoft and SAP commercial relationships. This commercial interconnection is a genuine differentiator for organisations with large Microsoft estates.
Organisations with significant AWS or Azure committed spend have leverage in both their hyperscaler and SAP negotiations. If your SAP workloads would represent a meaningful addition to your hyperscaler committed spend, you can use this to negotiate better rates from both parties — SAP wants workloads on a hyperscaler where you already have a relationship, and the hyperscaler wants your SAP workloads contributing to your committed spend threshold.
When selecting RISE with SAP, customers choose their preferred hyperscaler (AWS, Azure, or GCP) for the managed S/4HANA Private Cloud Edition infrastructure. This choice is made at contract signature and is not easily reversed mid-contract — changing hyperscalers within a RISE subscription typically requires a contract amendment and potentially a migration project.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
Within RISE, SAP manages the hyperscaler infrastructure on the customer's behalf. The customer does not directly purchase or manage hyperscaler resources — SAP does, and the infrastructure cost is embedded within the RISE subscription fee. As a result, the hyperscaler choice in RISE affects the underlying cost to SAP (and therefore SAP's margin on the subscription) rather than a direct line item on the customer's invoice.
However, the hyperscaler choice in RISE has strategic implications beyond the RISE contract itself. If you plan to run significant BTP workloads, data and analytics platforms, or custom applications alongside your RISE S/4HANA deployment, the hyperscaler on which those workloads run determines the network topology, data transfer costs, and native service availability. Running BTP and custom extensions on the same hyperscaler as your RISE deployment minimises latency and avoids cross-hyperscaler data transfer costs.
During RISE commercial negotiations, signalling your preference for a specific hyperscaler — and making clear that the hyperscaler has offered commercial incentives for your SAP workloads — can be used as leverage with SAP to improve the RISE subscription terms. SAP has commercial reasons to place workloads with specific hyperscalers at different times, and your hyperscaler preference may align with SAP's commercial incentives in ways that benefit your negotiation. This is a nuanced tactic that requires experienced specialist support to execute effectively — see our SAP negotiation firm rankings for specialist recommendations.
The alternative to RISE for cloud-based SAP is self-managed SAP on hyperscaler infrastructure — where you directly purchase and manage compute, storage, and networking from AWS or Azure, and run SAP software (either BYOL from your existing licence estate or a new purchase) on that infrastructure. Self-managed deployments offer more control over infrastructure sizing and costs but require SAP Basis expertise to operate and maintain.
The economics of self-managed SAP on AWS or Azure vs RISE are complex and organisation-specific. For organisations with strong internal SAP Basis capability, existing hyperscaler committed spend, and a desire to maintain infrastructure control, self-managed can be more cost-effective than RISE — particularly for stable ECC landscapes where active SAP management services add limited value.
Both AWS and Azure actively compete for SAP workload migrations from on-premise data centres. Both hyperscalers offer migration funding programmes that can significantly offset the cost of an SAP cloud migration project.
AWS's Migration Acceleration Program (MAP) provides funding for qualified SAP migration projects. MAP funding is structured in two phases: an Assess phase that funds a migration readiness assessment, and an Execute phase that provides cash credits, infrastructure credits, and funded professional services (through AWS partners) for the migration project itself. MAP funding for large SAP migrations can reach into the millions of dollars and is accessed through your AWS account team and a certified AWS MAP partner.
Microsoft's Azure Migrate and Modernize programme provides similar funding for SAP workload migrations to Azure. Microsoft's programme has the added commercial angle of potential SAP licensing incentives — for organisations moving to RISE on Azure, Microsoft and SAP sometimes jointly structure migration incentive packages that include both Azure infrastructure credits and SAP transition credits. This dual-incentive structure makes Azure particularly attractive for large RISE deals where both SAP and Microsoft are competing for strategic account influence.
| Incentive Type | AWS | Azure |
|---|---|---|
| Migration funding programme | AWS MAP (cash + credits) | Azure Migrate & Modernize |
| Infrastructure credits | Available via MAP | Available via programme |
| Partner-funded services | MAP partner funding | Microsoft + partner funding |
| Joint SAP-hyperscaler incentives | Available, less structured | Strong for RISE on Azure |
| Microsoft EA benefit | N/A | Azure spend vs MACC threshold |
A like-for-like comparison of SAP infrastructure costs between AWS and Azure is complex because the specific instance sizes, Reserved Instance terms, storage configurations, networking costs, and support level choices all affect the total. The following analysis captures the key cost dimensions and the typical relative positioning of AWS vs Azure for SAP workloads.
For HANA-certified instance families, on-demand pricing between AWS and Azure is broadly comparable — within 5–15% of each other for equivalent memory configurations. Azure Mv2 instances are competitive with AWS x1e instances at the 4–6 TB memory range, which covers the majority of mid-large SAP deployments. For very large HANA databases (above 6 TB), the infrastructure architecture choices diverge (AWS u- bare metal vs Azure HLI) and direct comparison becomes less meaningful.
Both AWS and Azure offer substantial discounts for committed usage. AWS Reserved Instances for HANA-certified families typically provide 35–45% savings vs on-demand for 1-year terms, and up to 65% for 3-year terms with upfront payment. Azure Reservations for M-series instances provide comparable savings. The flexibility of AWS Savings Plans (which apply across a wider range of instance types) gives AWS a modest advantage for organisations whose SAP infrastructure profile is expected to evolve over the commitment period.
SAP HANA requires high-performance storage — typically SSD-based storage with low latency and high IOPS. Both AWS (EBS gp3/io2 Block Express) and Azure (Ultra Disk, Premium SSD v2) offer HANA-certified storage options. Networking costs for data egress are broadly similar between the two platforms. For RISE deployments, storage and networking are embedded in the SAP subscription fee and are not separately visible to the customer.
The hyperscaler choice for SAP workloads is rarely determined by infrastructure unit price alone. Several strategic factors often carry more weight than per-hour compute costs.
The most pragmatic factor for many organisations is which hyperscaler they already have a committed relationship with. Concentrating SAP workloads on your primary hyperscaler simplifies commercial management, may contribute to committed spend thresholds that unlock broader discounts, and leverages existing technical expertise and tooling investments.
For organisations deeply committed to the Microsoft stack — Azure Active Directory, Microsoft 365, Teams, Dynamics 365, Power Platform — Azure's native integrations with SAP create genuine operational advantages. SAP's Joule AI copilot has specific integration hooks with Microsoft 365 Copilot; Azure AI services are certified for certain SAP BTP AI use cases; and the SAP-Microsoft partnership roadmap includes ongoing product integration commitments. For Microsoft-centric enterprises, Azure is often the natural SAP hyperscaler choice independent of pure infrastructure economics.
If your SAP data strategy includes building a data lakehouse, deploying AI models against SAP data, or integrating SAP analytics with a broader enterprise data platform, the hyperscaler's native data and AI services become a significant factor. AWS's analytics ecosystem (Redshift, EMR, SageMaker) and Azure's equivalent (Synapse Analytics, Azure ML, Fabric) both integrate with SAP — but your data platform team's expertise and existing tool investments may make one hyperscaler the natural fit.
Evaluating AWS vs Azure for your SAP landscape? Get independent infrastructure and commercial analysis.
Whether you are choosing a hyperscaler for a self-managed SAP deployment or selecting the infrastructure underlying a RISE subscription, the commercial terms are negotiable. The key negotiation principles are: compete the hyperscalers against each other, leverage your SAP migration project as a migration incentive trigger, and align infrastructure commitments with your SAP contract renewal timeline.
Requesting commercial proposals from both AWS and Azure simultaneously, on the same infrastructure specification, creates genuine commercial competition. Both hyperscalers' enterprise teams have discretion to offer additional incentives — migration credits, reserved instance pricing, professional services funding — when competing for a strategic SAP workload. Organisations that approach only one hyperscaler typically leave significant value on the table.
Hyperscaler Reserved Instance terms (typically 1 or 3 years) and committed spend agreements create infrastructure cost certainty but also lock in the relationship. Aligning your hyperscaler commitment term with your SAP contract term — so they renew simultaneously — gives you maximum leverage in both negotiations and prevents a situation where infrastructure lock-in constrains your SAP commercial options.
For broader guidance on using cloud infrastructure decisions as leverage in SAP negotiations, our S/4HANA migration negotiation guide covers the full commercial ecosystem of a migration programme, including how hyperscaler, SAP, and systems integrator commercial terms interact.
AWS and Azure both want your SAP workloads. Use that competition to maximise migration incentives, infrastructure pricing, and SAP subscription terms simultaneously.