Managing Azure Availability Sets And Proximity Placement Groups
Azure infrastructure design often involves two different concerns: keeping virtual machines available during platform maintenance and placing them close together for low-latency communication. Availability sets address the first concern, while proximity placement groups support the second. They solve related problems, but they should not be treated as interchangeable features.
For Australian workloads, the decision can affect latency between Sydney and Melbourne, data residency, disaster recovery, and operating costs. A well-designed deployment also needs to account for Azure region capacity, application dependencies, and obligations under the Privacy Act 1988.
Availability Sets And Fault Domains
An availability set distributes virtual machines across fault domains and update domains within a single Azure datacentre. A fault domain represents shared hardware, such as a rack or power source. An update domain groups machines that may be restarted together during planned maintenance.
For example, placing two domain controllers or web servers in the same availability set reduces the chance that both will be unavailable during a host failure or Azure maintenance event. Azure manages the distribution, but the administrator must add the VMs to the availability set when they are created. Moving an existing VM into an availability set generally requires redeployment.
Availability sets are useful for workloads that cannot use Availability Zones, or where the selected VM size is unavailable in a suitable zone. They do not provide regional disaster recovery. If the entire Azure region or application dependency fails, an availability set cannot protect the service.
Proximity Placement Groups And Latency
A proximity placement group is a logical grouping that encourages Azure to place selected VMs physically close together. This can reduce network latency between application tiers, making it valuable for clustered databases, high-performance computing, trading systems, and tightly coupled services.
The placement target is best understood as a scheduling preference rather than an absolute physical guarantee. Capacity changes, VM families, hardware generations, and scale operations can affect placement. A PPG can also create deployment constraints if Azure cannot find suitable capacity in the desired location.
Proximity placement groups are generally associated with a region and resource group. The VMs must use compatible placement settings, and administrators should test the measured latency rather than assume that proximity alone will meet an application’s service-level objective.
Choosing The Right Availability Model
Availability sets and PPGs can sometimes be combined for a tightly coupled group of VMs, but the design needs careful validation. Availability sets spread instances across fault and update domains, while a PPG attempts to keep them close. These goals can compete when capacity is limited.
Availability Zones provide separate physical locations within a region and usually offer stronger protection against datacentre-level failures. However, zonal deployments may introduce additional network latency and may not support every VM size or service configuration. A PPG is not a replacement for zone redundancy, and zone-based VMs have compatibility limitations with proximity placement.
| Design option | Primary benefit | Main limitation | Suitable use |
|---|---|---|---|
| Availability set | Protection from host and maintenance events | Limited to one datacentre | Legacy or zone-incompatible VM workloads |
| Proximity placement group | Lower latency between selected VMs | Capacity and placement constraints | Clustered, latency-sensitive tiers |
| Availability Zone | Datacentre-level resilience | Possible latency and SKU restrictions | Production services requiring higher isolation |
| Virtual machine scale set | Consistent scaling and instance management | Requires application-aware design | Web, API, and worker fleets |
| Region pair and backup | Protection from regional incidents | Higher complexity and recovery time | Business continuity and disaster recovery |
In Australian deployments, Azure Australia East is often selected for Sydney-based services, while Australia Southeast may suit Melbourne-oriented workloads. The best choice depends on user location, paired-region strategy, service availability, and the location of dependent systems.
Designing For Australian Operations
Data residency requirements should be assessed before selecting a region or replication pattern. The Australian Privacy Act 1988 and sector-specific controls may influence where personal information is stored and how backups are transferred. Government and regulated workloads may also need to consider IRAP assessments and the Australian Cyber Security Centre’s Essential Eight guidance.
Local network paths matter as well. A service used by customers in Perth may experience a different round-trip time to Australia East than a service used in Sydney. Measuring latency from representative offices, VPN gateways, and private connectivity circuits is more reliable than testing from a single administrator workstation.
Australian organisations also commonly schedule disruptive work around local business hours, school holidays, and end-of-financial-year processing. A maintenance plan that works for a Sydney office may be inconvenient for Melbourne operations or overnight support teams in Brisbane. Documenting UTC offsets and daylight-saving changes helps prevent avoidable scheduling errors.
For internet-facing systems, placement is only one part of resilience. Layer 7 protection, rate limiting, and monitoring should be reviewed alongside compute placement; for example, HTTPS flood mitigation can address a different failure mode from VM host maintenance.
Implementing And Verifying The Configuration
Create an availability set before deploying the VMs that require coordinated protection. Select the required fault and update domain counts, choose managed disks, and use consistent VM sizes where possible. For a PPG, create the group in the same region as the target VMs and assign it during VM or scale-set deployment.
Azure CLI and PowerShell are practical choices for repeatable builds. The deployment should define the resource group, region, VM SKU, availability set or PPG association, network interfaces, disks, and diagnostic settings. Infrastructure as code also makes it easier to reproduce a tested pattern in Australia Southeast or a recovery region.
Verification should include both Azure configuration checks and application testing. Confirm the VM associations, fault-domain placement, zone settings, and effective network paths. Measure latency between application components, test planned maintenance behaviour, and confirm that a single host, rack, or network dependency does not take down the service.
Avoid assuming that two VMs are genuinely independent because they have different names. Review shared load balancers, storage accounts, key management, domain services, and monitoring paths. A resilient compute layer can still fail if every instance depends on one database, firewall, or private endpoint.
Operational Recommendations For Long-Term Reliability
Capacity and lifecycle changes can alter the effectiveness of a placement design. A VM resize, host hardware refresh, scale-out event, or migration to a new Azure SKU may require a fresh assessment. Keep placement decisions in the same change-management process as networking and storage changes.
Use Azure Monitor, Network Watcher, service health alerts, and platform metrics to detect latency increases or degraded instance health. Keep recovery procedures current, especially where a PPG deployment could become constrained by regional capacity.
Practical operating habits include:
- Use availability sets when fault and update domain separation is the primary requirement.
- Prefer Availability Zones when the workload needs stronger datacentre-level isolation.
- Use proximity placement groups only for measured latency requirements.
- Test VM SKU capacity and redeployment behaviour before production changes.
- Record Australian data residency, privacy, and regulatory requirements in the architecture decision.
- Monitor application latency from Sydney, Melbourne, Brisbane, and Perth where those locations matter.
- Maintain backups and regional recovery plans because placement features do not replace disaster recovery.
A balanced design may use a PPG for a low-latency application cluster, zones or a region pair for broader resilience, and independent backups for recovery. The correct combination depends on workload behaviour, Azure service support, regional capacity, and the cost of downtime.