Regional Virtual Networks

Overview We are excited to announce that you can now create Virtual Networks (VNet) that span an entire region. While creating a new virtual network, you can refer to the Region instead of an Affinity group. New services deployed into a Regional Virtual Network can use any services/offerings (e.g. A8/A9 sizes, Internal Load balancing, Reserved IPs, Instance level Public IPs) available in the region. Prior to this announcement, VNets were bound to a scale unit, more precisely an Affinity group. An Affinity group is a grouping concept that references to a section of the datacenter or in other words certain number of servers. Since a VNet was bound to an affinity group it was indirectly bound to a set of servers, and hence was not able to place deployments in servers outside of this scale unit. Before: But with Regional Virtual Networks, these restrictions are removed, since the scope of the Virtual Network is the entire region and not just an Affinity group. Now: Key Scenarios Following are the key scenarios enabled by Regional Virtual Networks:

• New VM Sizes like A8 and A9 can be deployed into a virtual network which can also contain other sizes.
• New features like Reserved IPs, Internal load balancing, Instance level Public IPs
• The Virtual Network can scale seamlessly to use the capacity in the entire region, but we still restrict to maximum of 2048 virtual machines in a VNet.
• You are not required to create an affinity group before creating a virtual network.
• Deployments going into a VNet does not have to be in the same affinity group.

Usage Instructions The steps to create a Regional Virtual Network is similar to today, with one difference, when the VNet is defined in the network configuration file, a ‘location’ attribute is used instead of an ‘Affinity group’: Virtual Network definition (old):

<VirtualNetworkSitename="VNetDemo"AffinityGroup="VNetDemoAG">

Virtual Network definition (New):

<VirtualNetworkSitename="VNetUSWest"Location="West US">

  Note: You cannot convert an existing Virtual Network from Affinity group to Location, to obtain a Regional Virtual Network you will have to create a new Virtual Network with Location attribute. See the FAQ section below for more details. Portal Experience: The Regional Virtual Network cannot be created through the portal workflow as of now. This capability will be added in the near future. However, customers can still use the import, export functionality to create a Regional Virtual Network as shown below: 1. Export the current Network configuration file   2. Save the file to the local disk 3. Edit the file to add a new Virtual Network as shown below:

<?xmlversion="1.0"encoding="utf-8"?>

<NetworkConfigurationxmlns:xsd="https://www.w3.org/2001/XMLSchema"xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"xmlns="">

  <VirtualNetworkConfiguration>

   <VirtualNetworkSites>

     <!-- Regional Virtual Network Definition -->

    <VirtualNetworkSitename="VNetUSWest"Location="West US">

      <AddressSpace>

        <AddressPrefix>192.168.50.0/24</AddressPrefix>

        <AddressPrefix>192.168.51.0/24</AddressPrefix>

      </AddressSpace>

      <Subnets>

        <Subnetname="frontendsubnet">

          <AddressPrefix>192.168.50.0/24</AddressPrefix>

        </Subnet>

        <Subnetname="backendsubnet">

          <AddressPrefix>192.168.51.0/28</AddressPrefix>

        </Subnet>

        <Subnetname="gatewaysubnet">

          <AddressPrefix>192.168.51.16/28</AddressPrefix>

        </Subnet>

      </Subnets>

    </VirtualNetworkSite>

   </VirtualNetworkSites>

  </VirtualNetworkConfiguration>

</NetworkConfiguration>

4. Go through the New Virtual Network creation workflow as shown below:   5. Select the edited network configuration file from the local disk 6. Click ‘ok’ and complete the import process. This will create a new Regional Virtual Network. Powershell Experience: Download and install the latest Azure Powershell Steps to create a Regional Virtual Network (Powershell cmd lets): 1. Download the current network configuration file from Azure

                Get-AzureVNetConfig -ExportToFile "C:\Users\narayan\Documents\TechEdDemo\Netcfg.xml"

2. Edit the exported/created file and fill in the Virtual Network details as shown in step 3 in previous section 3. Create the Regional Virtual Network by running the following command:

   Set-AzureVNetConfig -ConfigurationPath "C:\Users\narayan\Documents\TechEdDemo\Netcfg.xml"

4. This creates a Regional Virtual Network. Frequently Asked Questions What are the regions which support Regional Virtual Network? Azure supports Regional Virtual Network in all regions How can my convert my existing Virtual network to Regional Virtual Network? To obtain a Regional Virtual Network, customers have to create a new one as described in this post. To migrate an existing affinity group based Virtual Network to a regional one follow the instructions in https://azure.microsoft.com/blog/2014/11/26/migrating-existing-services-to-regional-scope/ Can my existing VNets connect to a new regional VNet? Yes, using the new VNet-VNet feature your existing VNet can connect to the newly created Regional VNet. For more information refer to this link 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. What does newly announced features (Reserved IP, Internal load balancing and Instance level Public IP) have to do with Regional Virtual Network? The newly announced features mentioned in the question are all managed at a regional level, hence they are only available for deployments going into a Regional Virtual Network. Is there any charge associated with a Regional Virtual Network? No, Regional Virtual Network is an enhancement to the platform, it is not charged.