Tutorial · 2026

Deploy SAP HANA on Azure: VM Sizing, Storage & Configuration Guide

Deploy SAP HANA on Azure VMs: certified M- and E-series SKUs, Premium SSD v2 sizing rules, disk caching, NSG port design and a pre-installation checklist.

intermediate 11 min read Updated Nov 8, 2026

30-second summary

  • Certified SKUs first: M-series for large HANA, E-series for app tiers - check the SAP-supported matrix, not blog posts.
  • Storage design changed: Premium SSD v2 plus Write Accelerator replaces old P30/P40 LUN arithmetic.
  • NSG port table is where HSR silently breaks: 3xx13 backup, 3xx15 persistence, 3xx40-98 replication.
  • Reality check: the 'azure-ha' CLI extension many tutorials cite does not exist.
Contents

This guide is for engineers deploying SAP HANA 2.0 on Azure VMs (not HANA Large Instances, whose SKUs start with S in the hardware directory). You will pick a HANA-certified VM SKU, lay out /hana/data, /hana/log and /hana/shared on storage that passes SAP’s latency KPIs, secure the network with correct NSG rules, and run a pre-installation checklist matching Microsoft’s current guidance. Every figure and command here comes from Microsoft Learn docs updated between October 2025 and August 2026.

Prerequisites

  • An Azure subscription with sufficient compute-disk quotas. Microsoft’s own SAP deployment tooling (Azure Center for SAP solutions) requires at least a 4-core Standard_D4ds_v4 or Standard_E4s_v3 just to run its infrastructure deployment and software installation steps.
  • Register the resource provider before any az workloads usage: az provider register --namespace 'Microsoft.Workloads'.
  • Familiarity installing SAP HANA and SAP NetWeaver on-premises; Microsoft’s install guide assumes this.
  • Access to the SAP Support Portal for the notes cited in the checks below (1928533, 2235581, 2972496, 2777782).
  • A Linux subscription plan: either a gallery “SAP” image (SLES for SAP / RHEL for SAP, support included) or bring-your-own-subscription images, which you must register with your own SUSE SMT or Red Hat Satellite after deployment.
  • A virtual network designed before VM creation — HANA and its application tier must live in the same VNet, with subnets separated per tier.

VM sizing for SAP HANA workloads

Two rules decide everything upstream. First, the source of truth for HANA-certified Azure VMs is the SAP HANA hardware directory — not the NetWeaver list in SAP note 1928533; a VM can be NetWeaver-certified and still not HANA-certified (Microsoft’s own reference tables flag E16v3 and E32v3 as “VM type not HANA certified”). Second, HANA runs on memory-optimized VMs: Microsoft’s certified-size tables list Ev4, Ev5, D6, Ev6 and the M-series (Mv2/Mv3 for large memory).

A second sizing trap is the VM-level storage budget: each SKU has an aggregate disk throughput and IOPS quota, and SAP HANA savepoints can saturate the /hana/data volume almost by themselves. Microsoft warns that if your data volume can push more throughput than the VM allows, savepoint I/O interferes with redo-log writes and application throughput suffers. Size the data disks so their combined throughput stays at or below the VM’s remote-storage throughput limit.

SKU family Certified examples (VM memory) Typical use case
M-series (v1) Standard_M32ts (192 GiB), Standard_M32ls (256 GiB) Dev/test, small production, HA pairs for systems ≤ ~256 GB RAM
E/D-series (v4–v6) Standard_E20ds_v4 (160 GiB), E32ds_v4 (256 GiB), E48ds_v4 (384 GiB); Ev5/Ev6/D6 with equal memory Non-production systems; smaller production where sub-ms storage comes from Premium SSD v2 or Ultra
Mv2 / Mv3 large single-node Standard_M416ms_v2 (11,400 GiB), Standard_M624ds_12_v3 (11,400 GiB), Standard_M832ds_12_v3 (11,400 GiB) Production scale-up with 1–2 TiB+ memory footprint sizing
Mv3 /Ix extreme memory Standard_M832ixs1 (14,902 GiB), Standard_M832ids_16_v3 (15,200 GiB), Standard_M832ixs_v2 (23,088 GiB) Very large single-node HANA; storage designed for 2,000–4,000 MB/s data throughput
Mv3 top-end (request-only) Standard_M896ixds_32_v3 (30,400 GiB), Standard_M1792ixds_32_v3 (30,400 GiB) Max single-VM HANA deployments; not available by default — you must contact your Microsoft account team

Instead of eyeballing these tables, ask Azure’s own sizing service (from the 2026-04 Azure CLI quickstart):

az workloads sap-sizing-recommendation \
  --app-location "eastus" --database-type "HANA" \
  --db-memory 1024 --deployment-type "ThreeTier" \
  --environment "Prod" --high-availability-type "AvailabilitySet" \
  --sap-product "S4HANA" --saps 75000 \
  --location "eastus2" --db-scale-method ScaleUp

You feed it SAPS for the application tier and HANA memory (here 1,024 GB) and it returns recommended SKUs. The same quickstart deploys the full HA infrastructure with az workloads sap-virtual-instance create -g <RG> -n <VIS> --environment NonProd --sap-product s4hana --configuration <payload.json> --identity "{type:UserAssigned,...}".

Storage configuration: volumes for SAP on Azure

SAP-certified storage for HANA on Azure VMs is limited to four types: Premium SSD (v1), Premium SSD v2, Ultra Disk, and Azure NetApp Files (ANF) NFS v4.1 volumes. It is mandatory that /hana/data and /hana/log run on one of them. The minimum SAP KPIs you must engineer against: 250 MB/s read and 250 MB/s write on /hana/log (1 MB I/O size), ≥400 MB/s read and ≥250 MB/s write on /hana/data (16/64 MB I/O size). All Azure managed disks already store three copies (LRS), so never add software RAID for redundancy — striping is only for aggregating IOPS and throughput. New deployments must use managed disks for the OS VHD and any disk holding SAP database files.

Premium SSD v2 sizing (production starting point). Data = 1.2 × VM RAM; log = 0.5 × VM RAM, capped at 500 GiB above 1 TiB RAM; shared = 1 × RAM, capped at 1 TiB. Per-filesystem throughput/IOPS targets from the Microsoft table: 425 MB/s + 3,000 IOPS for data below 1 TiB RAM; 1,200 MB/s + 20,000 IOPS for 4–8 TiB; 1,300 MB/s + 40,000 IOPS on M624/M832ds_12_v3; 4,000 MB/s + 60,000 IOPS on M832ids_16_v3. A single Premium SSD v2 disk maxes at 1,200 MB/s and 80,000 IOPS, so large systems need multiple striped disks — each disk ships with 3,000 IOPS and 125 MB/s included, and provisioned IOPS/throughput can be changed 4 times in any 24-hour window. Sector size 512 or 4,096 bytes is configurable (default 4,096).

Premium SSD v1 caching rules — memorize these, they are the most-mistaken settings:

Volume Caching setting
/hana/data None or read-only
/hana/log None + Write Accelerator (Write Accelerator is mandatory for M-series/Mv2/Mv3 with Premium SSD v1 and works only on those families)
/hana/shared Read-only caching
OS disk Leave Azure’s default unchanged

If you combine data and log on one volume (non-production), no disk in the stripe may have read or read/write caching. On M32ts/M32ls, read-cached tests are capped by a 400 MB/s host-cache quota — test with caching off. Premium SSD v2 and Ultra Disk offer no caching options at all, and pass HANA latency KPIs without Write Accelerator, which makes them the simpler, more uniform choice.

Striping and partitioning. With LVM/mdadm use stripe sizes of 256 KB for /hana/data and 64 KB for /hana/log (revised from the old 64/128 KB and 32 KB guidance), and keep /hana/data, /hana/log, /hana/shared in separate volume groups — never the root VG. From SAP HANA 2.0 SPS03 you can instead let the indexserver stripe across multiple data files on separate disks (SAP notes 2400005 / 2700123), avoiding volume managers entirely; this also works across NFS shares.

Ultra Disk and ANF. Ultra Disk cannot be an OS disk — pair it with Premium SSD for the base VHD; a common production pattern is data on Premium SSD v1/v2 and log on Ultra for the lowest latency. Mixing storage types between /hana/data and /hana/log is supported, but HANA System Replication requires the same storage type for data on every replica and the same type for log on every replica. ANF volumes require NFS v4.1 for data and log (v3 is unsupported there); volume throughput scales with size and service level (1 TiB yields 16 MB/s Standard, 64 MB/s Premium, 128 MB/s Ultra), and a single Linux session tops out at 1.2–1.4 GB/s writes — use the nconnect mount option or HANA data volume partitioning beyond that. The ANF storage endpoint is injected into a delegated subnet, giving you private connectivity by design; keep VM and volume co-located and use a proximity placement group when tight latency is required. Size /hana/shared as Min(1 TB, 1 × RAM) for scale-up, or 1 × worker-node RAM per four worker nodes for scale-out — undersized shared volumes cause Pacemaker resource-agent timeouts and false failovers.

Network and security

Create NICs with Accelerated Networking and attach them at VM creation — for HANA it is a must-check item, and it is now a required feature on general-purpose v5+ sizes:

az network nic create \
  --resource-group sap-hana-rg --name nic-hana01 \
  --vnet-name sap-vnet --subnet hana-subnet \
  --accelerated-networking true

az vm create \
  --resource-group sap-hana-rg --name hana01 \
  --image <SLES-or-RHEL-for-SAP gallery image> \
  --size Standard_M32ls \
  --admin-azureuser --generate-ssh-keys \
  --nics nic-hana01 --public-ip ""

Security design points verified in Microsoft’s HANA operations and ACSS network docs: NSGs (optionally with Application Security Groups) sit on the HANA subnet and the management subnet and are the sanctioned way to steer SAP traffic; network virtual appliances in the path between the SAP application layer and the DBMS layer are unsupported — they can double latency and break Pacemaker-to-SBD communication, while NSG/ASG rules that allow direct traffic are fine. There are no per-vNIC throughput quotas, so multi-NIC designs (SAP recommends separating client-facing and HANA node traffic across two vNICs/subnets) exist for security, not bandwidth QoS. Shield HANA VMs from the public internet: create them with no public IP, manage via Azure Bastion, and use a forward proxy where internet egress is needed.

Open these ports in your NSGs (replace xx with the instance number, e.g. instance 01 → 3201-style substitution): SQL communication 3xx13, 3xx15 and 3xx40–3xx98 (tenant/application SQL, including ABAP/JAVA subnets), SAP Host Agent 1128/1129, HANA XS engine 43xx and 80xx, HTTP/S servers 5xx00/5xx01. Where supporting PaaS services offer private endpoints, use them instead of public access.

OS & HANA installation checklist (azure-ha extension reality and supported-storage checks)

One correction up front: there is no public Azure CLI extension named azure-ha. If a runbook tells you to az extension add --name azure-ha, it is stale or wrong. The real HA enablement pieces are: the az workloads SAP command group (Azure Center for SAP solutions, resource provider Microsoft.Workloads), the az hana command module from the Azure/azure-hanaonazure-cli-extension repository, and on the guest side fence-agents-azure-arm plus SBD/Pacemaker (installed with sudo zypper -n install fence-agents-azure-arm). Run this checklist before executing hdblcm:

  1. Confirm your topology is listed in Microsoft’s “SAP workload on Azure VMs — supported configurations”; if it isn’t listed, treat it as untested and unsupported.
  2. Verify the VM SKU in the SAP HANA hardware directory (exclude S* units — those are HANA Large Instances).
  3. Check the OS release and minimum kernel per SKU (SAP notes 2814271 for backup checksum failures, 2753418 timer fallback, 2791572 Hyper-V VDSO).
  4. Validate HANA release ↔ OS support via SAP note 2235581, then the product in SAP’s PAM.
  5. Deploy a gallery SLES-for-SAP/RHEL-for-SAP image; register BYOS images with your subscription for patches.
  6. Apply all OS patches before install.
  7. Apply HANA OS tuning: SAP notes 2694118 (RHEL HA add-on), 2578899/1984787 (SLES), 2772999/2777782 (RHEL 8+), 2382421 (network). Expect saptune power-management commands to error on Azure — host hardware state is not manipulable.
  8. Supported-storage checks: every data/log volume on Premium SSD v1/v2, Ultra or ANF v4.1; caching set per the table above; Write Accelerator enabled on /hana/log for M-series with Premium SSD v1; filesystem supported for your OS per SAP note 2972496; /hana/shared sized Min(1 TB, 1 × RAM).
  9. Confirm I/O scheduler is noop/none for data volumes unless your SLES saptune profile already set it (leave RHEL tune profiles alone).
  10. Verify Accelerated Networking is enabled on every NIC.
  11. Install the SAP enhanced monitoring extension data path (notes 2191498, 2178632; SAPOSCOL per note 1102124).
  12. For HA: configure SBD + fence-agents-azure-arm, or model the system as a Virtual Instance for SAP solutions instead of hand-rolling.
  13. Run SAP HCMT/HWCCT storage tests — and remember Premium SSD bursting credits will be exhausted by sequential test suites before all tests “fail”.
  14. Only now install SAP HANA per SAP’s instructions; for scale-out with Premium/Ultra direct-attached disks, follow the scale-out section of Microsoft’s HANA operations guide.

Common pitfalls

  • Sizing from the NetWeaver list. E16v3/E32v3 appear in Microsoft’s reference tables explicitly marked “VM type not HANA certified”; such pairings silently fail HANA latency KPIs until storage moves to Premium SSD v2 or Ultra.
  • Oversized data volumes on a small-VM quota. Savepoint throughput above the VM’s disk cap starves redo writes; keep data disks ≤ VM throughput limits.
  • Mixed HSR replica storage. Premium SSD v1 data on primary, Ultra data on replica is unsupported; identical types per volume role across replicas.
  • ANF with NFS v3 for /hana/data or /hana/log — only v4.1 is supported.
  • Read cache expectations on M-series. M-series v3 types can be slower with read-cached Premium SSD v1 than with caching off; M32ts/M32ls hit the 400 MB/s host-cache quota.
  • Treating “/hana/shared” as an afterthought. An undersized shared volume produces false HSR failovers through cluster resource-agent timeouts.

FAQ

Can I use Premium SSD v2 for /hana/log without Write Accelerator?

Yes. Premium SSD v2 delivers sub-millisecond latency on its own and passes SAP HANA certification without Write Accelerator or any cache — unlike Premium SSD v1, where Write Accelerator on /hana/log is mandatory for M-series. Note Premium SSD v2 (and Ultra) cannot host the OS disk; the VHD stays on Premium SSD.

How do I size storage for a 1,024 GB RAM M-series system?

Start from the 1.2 × RAM data rule (≈1.22 TiB), 0.5 × RAM log (512 GiB → use the 500 GiB cap logic only above 1 TiB RAM), 1 × RAM shared. Targets: 600 MB/s data throughput with 5,000 IOPS and 300 MB/s / 4,000 IOPS on log for the 1–2 TiB band; split across multiple Premium SSD v2 disks (each includes 3,000 IOPS + 125 MB/s) and stripe, or buy provisioned performance on fewer disks.

Is there an azure-ha Azure CLI extension I should add?

No. Nothing by that name exists in the Azure CLI extension index. Use az workloads (Azure Center for SAP solutions) or az hana, and inside the guest use fence-agents-azure-arm with SBD/Pacemaker. Beware of AI-generated runbooks that invent this extension.

What are the exact SQL ports for NSGs?

With instance number xx: 3xx13, 3xx15, 3xx40–3xx98 for SQL/MDBC communication, 1128/1129 for the SAP Host Agent, 43xx/80xx for XS advanced/web content, 5xx00/5xx01 for HTTP/S servers. Microsoft’s ACSS network guide allows either opening these selectively or permitting all intra-VNet traffic between SAP subnets.

References

Where docs disagreed, this guide follows the most recently updated Learn page and cites its “last updated” date.

Next steps