We run SAP AI Lab — two of us, one in ML systems, the other in enterprise information systems. We're independent and not affiliated with SAP or Microsoft, which is exactly why we rebuild deployment runbooks from primary sources instead of trusting them: a blog post is a snapshot, and this area moves. Our findings below trace to Microsoft Learn pages last updated between October 2025 and August 2026, verified as of 2026-11-08. Last month we nearly got burned anyway.

az extension add --name azure-ha will fail, and it should

While checking a SAP HANA high-availability runbook line by line against Microsoft Learn, we searched the Azure CLI extension index for azure-ha — the extension several tutorials, blog posts, and (increasingly) AI-generated runbooks tell you to install. It does not exist. Nothing by that name ships in the index. If a runbook says otherwise, it is stale or hallucinated.

What the real HA enablement actually consists of, per Microsoft's current docs (all pages we cite were updated between October 2025 and August 2026):

  • the az workloads command group — Azure Center for SAP solutions, backed by the Microsoft.Workloads resource provider you must register first;
  • the az hana module from the Azure/azure-hanaonazure-cli-extension repository;
  • inside the guest, fence-agents-azure-arm plus SBD/Pacemaker (sudo zypper -n install fence-agents-azure-arm on SLES).

None of it is named azure-ha. The lesson generalizes: verify every CLI incantation against the official index before it reaches a production runbook, because confident-sounding fiction propagates fast.

The second silent failure: certification lists

The other trap that cost us a full afternoon of re-reading: NetWeaver-certified is not HANA-certified. The source of truth for HANA on Azure VMs is the SAP HANA hardware directory, not the older NetWeaver VM list in SAP note 1928533. Microsoft's own reference tables mark E16v3 and E32v3 as "VM type not HANA certified" — and a system on those SKUs sails along until it silently misses HANA's storage latency KPIs (250 MB/s read and write on /hana/log at 1 MB I/O, ≥400 MB/s read on /hana/data).

What storage design looks like now

If your mental model is P30/P40 LUN arithmetic, most of it is obsolete. The pattern today is Premium SSD v2 with rules you can memorize in one sitting: size /hana/data at 1.2× VM RAM, /hana/log at 0.5× RAM (capped at 500 GiB above 1 TiB), /hana/shared at 1× RAM. A single v2 disk tops out at 1,200 MB/s and 80,000 IOPS, so the big M-series machines need striped sets.

And caching, the most-mistaken setting on Premium SSD v1: /hana/data gets None or read-only; /hana/log gets None plus Write Accelerator — mandatory on M-series with v1 disks, and it only works on those families; /hana/shared gets read-only. Premium SSD v2 and Ultra Disk simplify all of this by offering no caching options at all and meeting the latency KPIs without Write Accelerator.

Two gotchas we'd rather hand you than watch you find: every VM SKU has an aggregate storage throughput budget, and an oversized /hana/data volume whose savepoints saturate it will starve redo-log writes — throughput at or below the VM's limit, deliberately. And HANA System Replication requires the same storage type on every replica for data, and likewise for log; mixing Premium SSD on the primary with Ultra on the replica is unsupported, however tempting the benchmark looked.

One networking note worth stealing before you build: attach NICs with Accelerated Networking at VM creation, give the HANA VMs no public IP and manage them through Azure Bastion, and keep virtual network appliances out of the path between the app layer and the database — Microsoft marks that unsupported because it can double latency and break Pacemaker-to-SBD heartbeats, which turns a stretchy dev box into a very confident false failover.

The full walkthrough with all the pricing sources and checklists is on our site: Deploy SAP HANA on Azure: VM Sizing, Storage & Configuration Guide — including the 14-point pre-hdblcm checklist and the NSG port table where HSR silently breaks (3xx13, 3xx15, 3xx40–3xx98). If you're closer to the invoice than to the OS disk, the cost side of these SKUs, meter by meter, is in our RISE cost breakdown, and the subscription layout that makes these rules enforceable is in our Azure landing zone guide.