SAP HANA On Azure

Microsoft’s definitive platform for this enterprise workload is SAP HANA on Azure. In this comprehensive article, I will break down the certified compute topologies, dissect the critical block storage fabrics, analyze high-availability clustering matrices, and lay out an authoritative infrastructure deployment pattern for your enterprise.

SAP HANA On Azure

Architectural Blueprint: Certified Compute Topologies

An enterprise SAP migration will instantly stall if you select the wrong underlying hardware profile. SAP enforces strict performance guidelines through its official SAP Certified and Supported SAP HANA Hardware Directory. Microsoft provides two highly optimized infrastructure runways that meet these standards perfectly:

Azure Virtual Machines (VMs)

For the vast majority of scale-up transactional (OLTP) and analytical (OLAP) processing footprints, Azure’s specialized virtualized compute tiers deliver immense scalability.

• The E-Series (Edsv4 / Edsv5): The ideal baseline for small-to-medium target environments, starting at 160 GiB of RAM.
• The M-Series (M-series / Mv2 / Mv3): The premier cloud engine for massive memory requirements. The M-Series family scales gracefully from 1 TB all the way to 30 TiB of RAM on a single virtual node, completely backed by pay-as-you-go flexibility or deep cost optimizations like Azure Reserved Instances.

Azure Large Instances (BareMetal Portfolio)

When an enterprise footprint exceeds standard virtualized limits—such as massive global conglomerates running ERP instances that cross the 30 TB line—traditional hypervisors can introduce structural resource constraints.

Microsoft addresses this via Azure Large Instances: purpose-built, dedicated bare-metal blade servers located within the same regional data centers as your standard virtual network. This specialized bare-metal tier expands single-node capacities up to 24 TB and supports multi-node scale-out frameworks reaching 60 TB to 120 TB for big-data warehouses.

Structural Deep Dive: Storage Architectures and Throughput Minimums

Because SAP HANA processes its working datasets entirely in-memory, it loads its whole active state into RAM on startup. However, it still requires persistent disk storage to handle regular database savepoints, commit active transaction logs, and write long-term backups.

If your storage layer cannot deliver sub-millisecond write latencies, the engine will halt processing to prevent unaligned state corruption.

SAP enforces strict minimum baseline throughput metrics across your storage channels:

• The /hana/log Volume: Must achieve at least 250 MB/sec sequential read/write throughput with a 1 MB I/O payload size.
• The /hana/data Volume: Requires a minimum read capability of 400 MB/sec and write performance of 250 MB/sec using 16 MB and 64 MB sequential blocks.

To meet these intensive parameters, your architectural plan should leverage the following certified block and file storage choices:

Data Volume Partitioning

Historically, storage administrators had to configure complex Linux Logical Volume Manager (LVM) stripes or mdadm arrays across multiple physical Azure disks to aggregate enough speed to pass SAP’s verification checks.

In modern installations, you can bypass this operating system complexity by leveraging native SAP HANA Data Volume Partitioning (introduced in HANA 2.0). The indexserver can distribute its active I/O processing operations across separate data files stored on independent Azure managed disks natively, eliminating the need to maintain complicated software-based RAID configurations at the Linux OS level.

High Availability and Zone Resiliency Matrices

When your entire enterprise depends on a single database layer, downtime is not an option. A hardware fault in an Azure data center cannot be allowed to bring your business operations to a halt. Azure addresses this by providing native clustering frameworks engineered around Availability Zones.

For maximum reliability, your deployment should feature an automated failover architecture spanning two independent Availability Zones:

• HANA System Replication (HSR): The primary node in Zone 1 processes all active read/write application traffic. It continually pipes a synchronous stream of data updates across a private, low-latency network path to a secondary standby instance waiting in Zone 2.
• The Pacemaker Linux Cluster: A high-availability management framework (such as SLES for SAP Applications or RHEL for SAP Solutions) monitors both nodes continuously.
• The Azure Fence Agent: If the primary node experiences a sudden hardware failure, the Pacemaker cluster utilizes the official Azure Fence Agent (STONITH – Shoot The Other Node In The Head) via secure Azure API calls to cleanly isolate the failed VM. It instantly promotes the standby instance in Zone 2 to primary active status, updating your network routing paths in seconds without manual intervention.

Operational Ingestion to Database Layer Topology

To help your network engineering teams visualize how these moving parts interact securely within your corporate network infrastructure, let’s explore the system layout below:

As illustrated above, your infrastructure should always isolate the database layer into its own secure subnet within a hub-and-spoke virtual network topology. All cross-site connectivity should pass through an encrypted Azure ExpressRoute circuit rather than the public internet to protect your corporate telemetry.

Enterprise Security and Data Governance

When handling sensitive enterprise data estates—such as personal employee data or proprietary manufacturing plans—enforcing robust data security perimeters is mandatory.

• Network Isolation Perimeters: You must configure distinct Network Security Groups (NSGs) and Application Security Groups (ASGs) to restrict communication. The database subnet should only accept incoming traffic from verified application servers on explicit SAP communication ports (such as 30015 or 30017), blocking all other external lateral network movement by default.
• Identity and Access Governance: Eliminate raw, long-lived access keys from your administration tools. All management operations—including backing up your database straight to an Azure Storage account via the Azure Backup plugin—should run under a passwordless User-Assigned Managed Identity validated through Microsoft Entra ID.
• Encryption at Every Layer: Data inside the database should use SAP HANA native internal encryption for all data blocks and transaction log sequences. At the cloud infrastructure layer, Azure managed disks utilize automatic Server-Side Encryption (SSE). For maximum compliance, you can activate Customer-Managed Keys (CMK) hosted inside an isolated Azure Key Vault to retain total control over your cryptographic keys.

Provisioning an SAP HANA Infrastructure Sandbox

To configure a secure, certified infrastructure environment for a new cloud sandbox, follow this sequence to ensure proper network isolation and performance alignment from day one:

1. Establish the Spoke Virtual Network and Subnet Infrastructure.

Log in to your enterprise subscription, navigate to your target region, and create a dedicated Spoke Virtual Network. Carve out a distinct, isolated subnet specifically for your database layer, and assign an explicit Network Security Group (NSG) configured to allow traffic only from your trusted application segments.

2. Deploy a Certified M-Series Virtual Machine Instance.

Launch an official M-Series Virtual Machine size (such as an M64ls or M128ms instance) backed by a certified enterprise Linux distribution image (like SUSE Linux Enterprise Server for SAP Applications). Set the storage profile to use Premium SSD v2 or Ultra Disks to meet SAP’s rigorous read/write performance minimums.

3. Execute Target Operating System Optimizations and SAP Tuning Notes.

Connect to your freshly deployed Linux instance via a secure shell wrapper. Register your operating system subscription to download the latest security patches, then activate the automated saptune or sapconf execution profile to modify your OS kernel settings, virtual memory boundaries, and network socket allocations according to official SAP Support Notes.

Summary and Strategic Cloud Guidance

Migrating your SAP HANA workloads to Azure provides your business with an incredibly robust, agile, and high-performance core data platform.

By deliberately aligning your memory requirements with the correct M-Series or BareMetal tier, enforcing strict layout splits using Premium SSD v2 or Ultra storage, utilizing automated Pacemaker fencing loops across independent Availability Zones, and ensuring that no public internet paths touch your database layer, you establish a resilient foundation for your enterprise apps.

This disciplined architecture ensures your most critical business processes run smoothly, securely, and at a global scale.

You may also like the following articles:

• Azure Storage Account Tutorial
• How to Learn Azure from Scratch
• Azure Fundamentals
• Azure Subscription Types

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.