A customer yesterday asked me about why the Affinity Group setting is suddenly no longer required as of a week or so ago to build a private VNET. It turns out that with the new capabilities of Azure VNETs an affinity group is no longer needed. The reason is the VNets can now span data centers within a region. A new VNet ‘type’ – Regional VNET – has been created to overcome some of the old limitations.
This makes perfect sense if you think about it the whole goal of an affinity group is to maximize locality to minimize latency between resources in the VNET. The physical implementation of the logical affinity group entity results in servers within one DC being put as close physically to each other as possible (taking into account fault and upgrade domains). But now that the VNets are no longer constrained to one DE the whole concept of allocating network resources close to optimize access time goes out the window.
Now instead of specifying an affinity group in the network config file you specify a Location (maps to ‘region’ – not sure why they added yet another term!) in the VirtualNetworkSiteName entity.
In an existing VNet you cannot convert an existing affinity group to a locality without recreating the network. However you can join an legacy VNet to a Regiona VNet and it will work fine.
However, an affinity group still is in use for storage and PaaS Cloud Services/IaaS VMs).