Comparison of Inter-VNET, VNET-to-VNET VPN and VNET Peering speeds in Microsoft Azure

    In August, we already discussed the public preview of the new Microsoft Azure functionality - VNET Peering. Since then, VNET Peering has entered GA and it's time to take a closer look. Indeed, it would be interesting to know how different the data transfer speed in Azure virtual networks is, with different ways of organizing them.

    For example, is the speed different within the same subnet and between different subnets in the same VNET? Does the transition to another VNET through Peer slow down speed? And through VNET-to-VNET VPN?



    I conducted a small experiment on this topic to test the usefulness and effectiveness of VNET Peering and I invite you to familiarize yourself with its results.

    To begin with, we will determine what exactly we will compare. I put together the following test environment:



    This allowed me to compare several types of communication that may exist between servers in Azure:

    • Servers on the same subnet
    • Servers on different subnets of the same VNET
    • Servers in different Peered VNET
    • Servers in different VNET connected VPNs via Virtual network Gateway

    For the last scenario, I was also interested in looking at the difference between the different SKUs available for the Virtual Network Gateway , so I consistently recreated this connection with Basic SKU, Standard SKU and High-Performance SKU. Microsoft claims 100 Mbps bandwidth for the first two and 200 Mbps for High-Performance SKU.

    I chose a rather trivial and simple test, or rather two tests (in no way claim their 100% objectivity) - copying files with a total volume of 5GB. In the first test, these are 5 files of 1 GB, in the second - 500 files of 10 MB. File Contents - ZIP archive with standard compression of random data. Each operation was carried out 10 times with time measurement and cleaning of server RAM between attempts.

    As test servers, DS2_V2 with 2 CPUs, 7GB RAM and disks on Premium Storage were chosen so that the read / write speed to the disk had minimal impact on the speed of copying files.

    Below is the result of measuring the copy speed in Mbps. For each of the 6 networking options, the best, average, and worst results are shown for several large and many small files.



    I will give my thoughts, but you can draw your own conclusions based on this data.

    It is clear that the test, in no way, claims to be a full-fledged study. This is evidenced by at least the difference between the best and worst measurement results reaching 25%, which means that a test of only 10 repetitions will not give a good approximation for the average value. On the other hand, these results still allow us to assess the big picture:

    - VNET Peering is an excellent functionality that allows you to create reliable high-speed communication between virtual networks in Azure.

    - The difference between Basic / Standard and High Performance SKU for Virtual Gateway turned out to be significantly less than I expected. It is especially pleasant that this is achieved due to the fact that the Basic / Standard options show bandwidth that is higher than stated, and not vice versa.

    How much are these options? It is clear that for servers on the same subnet and on different subnets of the same VNET, you do not pay anything. But for the remaining options, you have to pay.

    The cost of VNET Peering after its release in GA is € 0.0084 per GB of incoming and outgoing traffic. As I understand it, you will pay twice for each GB (once, if the receiving or outgoing party is not in your subscription, then its owner will pay half).

    Virtual Gateway pricing varies by region. I will give here the cost for Northern Europe, since it was there that I was setting up my laboratory.

    • Basic SKU - € 0.0304 per hour
    • Standard SKU - € 0.1602 per hour
    • High Performance SKU - € 0.4132 per hour

    In addition, you will pay from € 0.0295 to € 0.1349 for each GB of incoming traffic depending on the region from which the traffic comes (only traffic between two VNETs in different Azure regions is considered).

    In general, the choice of the best option depends on your requirements and goals. Personally, I would prefer VNET Peering to connect two VNETs if:

    • I plan monthly traffic volumes below 2TB per month (the choice is obvious, because VNET Peering will be faster and cheaper)
    • maximum bandwidth is important to me

    VNET-to-VNET VPN would be preferable if:

    • I plan to connect VNET in different Azure regions (here I have no choice at all, since VNET Peering works only within one region )
    • I plan monthly traffic volumes above 30TB per month

    For monthly traffic volumes between 2 and 30 TB, price and bandwidth requirements will be important. It will be very important to calculate what the minimum allowable SKU Vitrual Gateway is in order to understand which solution will be optimal for the price.

    I really liked the functionality of VNET Peering and the additional features that it gives when designing solutions based on Microsoft Azure. For test labs with low traffic, this is generally an ideal solution. For the main work environment, VNET Peering with its speed and ability to conveniently and transparently configure the rules for traffic transit and mutual use of Gateway in Peered networks is also a very, very interesting option.

    Also popular now: