Networking for SAP on Azure
Design hub-spoke network topologies for SAP, configure ExpressRoute vs VPN connectivity, accelerated networking, Azure Load Balancer with floating IP for HA, proximity placement groups, and network security controls.
The SAP network blueprint
☁️ Mei draws a hub-spoke diagram on the whiteboard. “Networking is where SAP on Azure gets real. SAP systems are chatty — the application tier talks to the database tier thousands of times per second. If the network adds even a few milliseconds of latency, your users feel it.”
🏗️ Raj nods. “On-premises we had everything on the same switch. In the cloud, I imagine it is more complex.”
☁️ Mei smiles. “More complex, but also more controllable. We design a hub-spoke topology where shared services live in the hub and SAP workloads sit in spokes. The key is keeping SAP components close together and the traffic paths predictable.”
Think of it like an office building.
The hub is the reception area and mailroom — all external visitors and packages arrive there. Each spoke is a department floor with its own rooms. The SAP floor has the database team and the application team sitting right next to each other (low latency). When they need to call headquarters (on-premises), they use the building’s dedicated phone line (ExpressRoute) rather than shouting across the parking lot (public internet).
📐 Architecture diagram: Open the SAP Hub-Spoke Network Topology diagram in Excalidraw to see the full hub-spoke layout with ExpressRoute, spoke VNets, and SAP subnets.
Hybrid connectivity: ExpressRoute vs VPN
SAP systems rarely live in isolation — they need to reach on-premises ERPs during migration, communicate with partner systems, and connect to SAP transport directories. Hybrid connectivity is essential.
| Feature | ExpressRoute | Site-to-Site VPN |
|---|---|---|
| Connection type | Private dedicated circuit via connectivity provider | Encrypted tunnel over public internet |
| Bandwidth | 50 Mbps to 100 Gbps | Up to ~1.25 Gbps per tunnel (aggregate with multiple tunnels) |
| Latency | Predictable, low latency | Variable, depends on internet path |
| SLA | 99.95% (standard) or 99.99% (ExpressRoute Direct) | 99.95% for active-active gateway |
| SAP recommendation | Recommended for production SAP workloads | Acceptable for dev/test or as a backup path |
| Cost | Circuit fee + provider fee + gateway | Gateway SKU cost only |
| Exam relevance | Primary choice for production SAP connectivity | Know it exists as failover or non-prod option |
Exam tip: ExpressRoute is the default answer for SAP production
When the exam describes a production SAP scenario needing hybrid connectivity, ExpressRoute is almost always the correct answer. VPN is the fallback for non-production or as a secondary path. Some architectures use both — ExpressRoute as primary and VPN as failover.
Accelerated networking — mandatory for SAP
Accelerated networking bypasses the host’s virtual switch and sends traffic directly to the NIC via SR-IOV (Single Root I/O Virtualization). This reduces latency and jitter significantly.
For SAP on Azure, accelerated networking is mandatory on all VMs:
- SAP Note 2015553 explicitly requires it
- Without it, network latency between application and database tiers can cause transaction timeouts
- Most SAP-certified VM sizes support it
- Enable it at VM creation or by deallocating and reconfiguring an existing VM
🏗️ Raj checks his notes. “So this is not optional?”
☁️ Mei shakes her head firmly. “Non-negotiable. If SAP Support sees you running without accelerated networking, that is the first thing they will flag.”
Azure Load Balancer for SAP HA
Azure Load Balancer (Standard, internal) is a critical component for SAP high availability. It directs traffic to the active node in a cluster. Key configuration details for SAP:
- Standard SKU — basic SKU is not supported for SAP HA
- Internal — SAP cluster IPs are private, never internet-facing
- Floating IP enabled — this is essential; it makes the backend VM receive traffic destined for the frontend IP, which is how the virtual cluster IP works
- Health probes — custom TCP probes on specific ports (e.g., 62000 for ASCS, 62001 for ERS) detect which node is active
- HA ports rule — forwards all ports through a single rule instead of defining each SAP port individually
Floating IP is the key concept
Floating IP (also called Direct Server Return) means the Load Balancer does not perform NAT — the packet arrives at the backend VM with the original destination IP intact. The active cluster node binds to this IP, and the passive node does not. This is how SAP’s virtual hostname mechanism works on Azure. If the exam asks about Load Balancer configuration for SAP clusters, floating IP enabled is always required.
Proximity placement groups
Proximity placement groups (PPGs) ensure VMs are deployed physically close to each other in the same datacenter. For SAP, this minimizes network latency between the application tier and the database tier.
- Group the HANA VM and application server VMs into the same PPG
- PPGs constrain placement to a single datacenter — this limits availability zone flexibility
- Use PPGs when sub-millisecond latency between app and DB is critical
- For availability zones deployments, inter-zone latency testing with niping helps determine if PPGs are still needed
Network security controls
SAP has well-defined communication ports. Use these Azure controls to lock down traffic:
- NSGs (Network Security Groups) — filter traffic by IP, port, and protocol at the subnet or NIC level
- ASGs (Application Security Groups) — group VMs by role (e.g., SAP-DB, SAP-App) and write NSG rules against the group
- Azure Firewall — centralized firewall in the hub VNet for egress control and logging
- Private endpoints — access Azure PaaS services (Storage, Key Vault) without traversing the public internet
- Service endpoints — an alternative to private endpoints that routes traffic to Azure PaaS over the Microsoft backbone while keeping public IPs. Less secure than private endpoints (traffic still uses public IPs) but simpler to configure. For SAP, private endpoints are preferred for Storage and Key Vault access; service endpoints can be used where private endpoints are not feasible
- DNS private zones — resolve Azure private endpoint FQDNs within the VNet
- UDRs (User Defined Routes) — force traffic through Azure Firewall or network virtual appliances
Key SAP ports to know: 32xx (dispatcher), 33xx (gateway), 36xx (message server), 3xx13 (HANA nameserver), 3xx15 (HANA indexserver), 3xx17 (HANA XS engine), 8443 (Web Dispatcher HTTPS), where xx is the SAP or HANA instance number (e.g., 30015 for HANA instance 00).
Knowledge check
PrecisionSteel is deploying production SAP on Azure. They need reliable, low-latency connectivity back to their on-premises datacenter for the coexistence period. What should Mei recommend as the primary connection?
Mei is configuring Azure Load Balancer for the ASCS cluster. Which setting is mandatory for the SAP virtual IP to work correctly?
Mei is reviewing PrecisionSteel's SAP VM configurations for compliance. Which Azure networking feature must be enabled on every SAP VM according to SAP Note 2015553?
PrecisionSteel wants to minimize network latency between their HANA database VM and SAP application server VMs. What Azure feature helps achieve this?
Summary
You now have the network blueprint for SAP on Azure: hub-spoke topology, ExpressRoute for production hybrid connectivity, mandatory accelerated networking, Azure Load Balancer with floating IP for HA clusters, proximity placement groups for low latency, and layered security with NSGs, ASGs, and Azure Firewall.
Next, we dive into HANA architecture — how to design the database layer itself, from single-node scale-up to multi-node scale-out.
🎬 Video coming soon