Now there's the new Azure Regional Virtual Networks feature that spans a region, is there a performance benefit of using affinity groups? In the FAQ part of the linked blog post there reads
Do I incur any performance degradation for services running inside a Regional Virtual Network?
Virtual network is only a logical boundary, it does not dictate where the deployments in the VNet actually go to. If for some reason, you need services to be in the same Affinity group, you can still do that inside a regional virtual network. During deployment you will have to specify the Affinity group to which the hosted service should be bound to. The only restriction would be, that the Affinity groups should belong to the same region as the Regional Virtual network.
If you do not bind your hosted service to an Affinity group, and deploy services directly to the Regional Virtual Network, your deployments will be placed in a scale unit inside the region the Virtual Network is bound to.
I get a feeling the recommendation is not to use affinity groups at all anymore (based on this and some other posts, maybe it's my Azure and/or English comprehension, though), but would the services and data be co-located in the data center then?
<edit: Of course just after writing this I discovered a MSDN article About Regional VNets and Affinity Groups for Virtual Network which states
Previously, when creating a virtual network (VNet) you were required to associate the VNet with an affinity group, which was in turn, associated with a Region. This requirement has changed. Now VNets are associated directly with a Region (Location) in the Management Portal. This allows you more freedom when creating your VNets. You can still associate your cloud services with affinity groups when appropriate, but you are not required to do so.
The Region represents where the Virtual Network overlay will be. Anything you deploy to the virtual network will be physically located in the Region. If you want to further designate that you want your resources in close proximity physically to each other within the same region, you can specify an affinity group for those particular resources. That would mean that not only are those resources in the same physical location, they are very close to each other in the datacenter.
So, I suppose there is a performance benefit to be had when using affinity groups.
<edit: The most definitive source for the little performance edge and use cases for affinity groups I can find is to be found at Convective blog post Affinity Groups in Azure.
An affinity group serves two purposes:
- colocation of cloud service and storage account
- host for an affinity group VNET
The second of these is now deprecated. The first is still possible but has not been emphasized as the latency optimization it was prior to the upgrade of the Azure network in 2012. In fact the standard way to deploy a VM in the Azure Portal does not support the simultaneous creation of a cloud service in an affinity group and a regional VNET. This confuses people who try to satisfy the modern best practice of using a regional VNET for deployments and the historic best practice of creating a cloud service in an affinity group.
At this point there seems to be little reason to deploy a cloud service into an affinity group. However, as with other deployment choices it might be wise for people to test this out for their specific workloads.
