Proximity Placement and Availability Options
Configure proximity placement groups for sub-millisecond SAP latency, choose between availability sets and availability zones, understand flexible scale sets, and test inter-zone latency with niping.
The latency vs. resilience trade-off
☁️ Mei draws two diagrams side by side. “Raj, here is the tension at the heart of SAP infrastructure design. We want the database and application servers as physically close as possible for performance. But for resilience, we want them spread across separate fault domains or even separate buildings. We cannot have both at the maximum level — so we need to find the sweet spot.”
🏗️ Raj frowns. “Can we measure how much latency we are actually dealing with?”
☁️ Mei nods. “Yes — SAP provides a tool called niping that measures network round-trip time. We use it to test latency between availability zones so we know if zones are close enough for SAP or if we need proximity placement groups.”
Think of it like choosing desks in a shared office.
Availability sets give your team desks in different sections of the same building — if one section loses power, the other keeps working. Availability zones put your team in separate buildings across town — even if one building has a fire, the other is unaffected. Proximity placement groups are a request to put desks side by side — fast communication, but if that section has a problem, both are affected. The trick is finding the right balance between “fast talking” and “safe from disasters.”
Availability sets vs. availability zones
| Feature | Availability Sets | Availability Zones |
|---|---|---|
| Protection level | Rack-level (fault domains within one datacenter) | Datacenter-level (separate physical buildings) |
| SLA | 99.95% | 99.99% |
| Network latency between VMs | Sub-millisecond (same datacenter) | Typically less than 2 ms (between zones) |
| SAP recommendation | Acceptable for existing deployments | Preferred for new deployments |
| PPG support | Can combine with PPGs | PPGs work within a zone but not across zones |
| Storage redundancy | LRS or ZRS | LRS or ZRS (storage redundancy does not replace SAP HA — SAP HA is driven by database and application replication such as HSR and ENSA2, not storage redundancy) |
| Exam relevance | Know the concept and SLA | Primary focus — preferred for new SAP |
🏗️ Raj asks. “So for PrecisionSteel, we should go with availability zones?”
☁️ Mei confirms. “Yes. Zones give you 99.99% SLA and protection against entire datacenter failures. We put the primary HANA VM in Zone 1 and the HA replica in Zone 2. The application servers are distributed across zones too.”
Exam tip: Zones are the modern answer
When the exam asks about availability for new SAP deployments, availability zones is almost always the correct answer. Availability sets are the legacy approach. The key exception is when the question specifically mentions a region that does not support availability zones — then availability sets with PPGs is the fallback.
Proximity placement groups (PPGs) deep dive
PPGs ensure VMs are co-located as close as possible within a datacenter. However, since November 2021, Microsoft has moved PPGs to a “previously recommended” status for SAP. The current recommendation is to use availability zones WITHOUT PPGs for most SAP deployments, and only add PPGs if inter-zone latency testing with niping shows unacceptable results.
- Current guidance: Availability zones without PPGs is the default recommendation for new deployments
- When to use: Only when inter-zone latency exceeds SAP requirements (typically greater than 1-2 ms) and cannot be resolved by zone selection alone
- How they work: You assign VMs to a PPG, and Azure places them in the same datacenter rack cluster
- Limitation: PPGs are constrained to a single datacenter, which means you cannot use them across availability zones
- Best practice: If PPGs are needed, anchor with the database VM first, then add application server VMs
Zone mapping is subscription-specific
A critical Azure concept: availability zone numbers (Zone 1, 2, 3) map to different physical datacenters for each subscription. Zone 1 in your subscription might be a different physical building than Zone 1 in another subscription. This means latency testing results are not transferable between subscriptions.
Exam tip: Zone mapping surprise
The exam may test whether you know that zone numbers are subscription-specific. If a colleague says “Zone 1 has great latency in our subscription,” that result does not apply to your subscription. Always test latency in your own subscription using niping before making placement decisions.
⚠️ Recently changed — exam alert
Microsoft’s guidance on Proximity Placement Groups changed significantly in November 2021. PPGs were moved from ‘recommended’ to ‘previously recommended deployment options.’ The current best practice is availability zones WITHOUT PPGs for most new SAP deployments. Only use PPGs when inter-zone latency testing (using niping or SAP Network Check) shows unacceptable results. If an exam question asks about the recommended deployment approach for new SAP systems, availability zones alone is typically the correct answer.
Flexible virtual machine scale sets
Flexible VM scale sets are the modern replacement for availability sets. They allow you to:
- Mix different VM sizes within the same scale set
- Spread VMs across fault domains and availability zones
- Use PPGs within the scale set for co-location
- Manage VMs individually (unlike uniform scale sets)
For SAP, flexible scale sets provide the fault domain distribution of availability sets with the flexibility to manage each VM independently. They are the recommended approach when availability zones are used but you still want fault domain control within a zone.
Testing latency with niping
niping is a SAP-provided network diagnostic tool that measures TCP round-trip time between two hosts. For Azure SAP deployments:
- Install niping on both the application server VM and the database VM
- Run the server on the DB VM:
niping -s(starts listening) - Run the client on the app VM:
niping -c -H db-ip-address -B 10000 -L 100 - Check the average round-trip time — SAP requires sub-millisecond for app-to-DB communication
Use niping to validate that your zone placement or PPG configuration delivers acceptable latency before going live.
Knowledge check
PrecisionSteel is deploying a new SAP system in an Azure region that supports availability zones. What should Mei recommend for the HANA HA deployment?
After deploying SAP in availability zones, Raj notices that inter-zone latency is 1.8 ms. What should Mei do?
Mei needs to verify network latency between the HANA VM in Zone 1 and the application server in Zone 2. Which tool should she use?
Summary
You now understand how to balance performance and resilience for SAP on Azure: availability zones without PPGs for most new deployments (99.99% SLA), proximity placement groups only when inter-zone latency testing shows unacceptable results, flexible scale sets as the modern alternative to availability sets, and niping for validating network latency. Remember that zone numbers are subscription-specific — always test in your own environment.
Next, we explore Azure Center for SAP solutions — Microsoft’s unified management plane for deploying and managing SAP systems on Azure.
🎬 Video coming soon