Azure Virtual Network Overview

A virtual network is a network overlay that you can configure in Azure. VMs and services that are part of the same virtual network can access each other. However, services outside the virtual network have no way to identify or connect to services hosted within virtual networks unless you decide to configure that specific type of connection, as in the case of VNet to VNet configurations. This provides an added layer of isolation to your services. Azure Virtual Network also lets you extend your network into Azure and treat deployments as a natural extension to your on-premises network.

Whether you need a virtual network depends entirely on what you are trying to do. There are no one-size-fits-all virtual network designs. However, you’ll find that every solution falls into one of 3 basic configuration categories: No VNet, Cloud-Only VNet, or Cross-Premises VNet (which includes Hybrid solutions). Once you know which basic category your project falls under, you can then build on it to create a network design that supports the solution that you want to create.

It’s best to know if you need a virtual network before you deploy your VMs and cloud services. VMs and cloud services acquire their network settings during deployment. This means you can’t simply move something into a VNet if it is already deployed. However, you can redeploy your VMs and cloud services. It’s a relatively straight forward process, but can result in some minor downtime for the VMs or services while you redeploy.

Do I need a virtual network?

The graphic below will help you decide. Keep in mind that this is just a basic decision model to get you started. For more details, see Are there other considerations?, Cloud-Only virtual network configurations, Cross-Premises virtual network connectivity, and Where can I find more information?.

Are there other considerations?

When deciding if you need a virtual network, there are a few other things to consider. You may also want to create a virtual network for the following reasons:

• Name resolution: If you want to connect to your VMs and cloud services by hostname or SRV records, rather than using the IP address and/or port number, you’ll need name resolution. When you deploy VMs and cloud services to a virtual network you can use Azure-provided name resolution or your own DNS solution, depending on your name resolution requirements. For information about name resolution options, see Name Resolution (DNS).
  
• Enhanced security and isolation: Since each virtual network is run as an overlay, only virtual machines and services that are part of the same network can access each other. Services outside the virtual network have no way to identify or connect to services hosted within virtual networks. This provides an added layer of isolation to your services.
  
• Extended trust and security boundary: The virtual network extends the trust boundary from a single service to the virtual network boundary. You can create several cloud services and virtual machines within a single virtual network and have them communicate with each other without having to go through the internet. You can also setup services that use a common backend database tier or use a shared management service.
  
• Extend your on-premises network to the cloud: You can join VMs in Azure to your domain running on-premises. You can access and leverage all on-premises investments around monitoring and identity for your services hosted in Azure.
  
• Use persistent private IP addresses: Virtual machines within a VNet will have a stable private IP address. We assign an IP address from the address range you specify and offer an infinite DHCP lease on it. You can also choose to configure your virtual machine with a specific private IP address from the address range when you create it. This ensures that your virtual machine retains its private IP address even when Stop/Deallocated. SeeConfigure a static internal IP address for a VM.
  

Cloud-Only virtual network configurations

Cloud-Only virtual network configurations are VNets that don’t use a virtual network gateway to connect back to your on-premises network or directly to other Azure VNets. They aren’t really a different type of VNet, but rather, they are a way to configure a VNet without configuring cross-premises connectivity. You connect to the VMs and cloud services from the endpoints, rather than through a VPN connection.

Cloud-Only configurations are very easy to create. This is because you don’t need to coordinate your IP address ranges with the ranges on your local network or with the ranges of other VNets. You also don’t need to configure a VPN device. If you create a VNet and find later that you want to add cross-premises connectivity, it can be somewhat more complicated than to simply add a gateway to your VNet. This is because the IP address ranges that you select can’t overlap with the ranges that are on your local on-premises network or with other VNets that you may want to connect to. In that case, it may make sense to create a new VNet with the required settings for a cross-premises connection, and then redeploy your cloud services and VMs to the new VNet.

For Cloud-Only configurations, see Configure a Cloud-Only Virtual Network in the Management Portal.

Cross-Premises virtual network connectivity

Cross-Premises connections offer an enormous amount of flexibility. You can create multi-site configurations, VNet to VNet configurations, ExpressRoute connections, and combinations of multiple configuration types. If you are extending your on-premises network to the cloud, this is the way to do it. Most cross-premises connections involve using a VPN device to create a secure connection to your Azure virtual network. Or, if you prefer, you can even create an ExpressRoute direct connection to Azure through your network service provider or exchange provider and bypass the public internet altogether.

Cross-Premises and Hybrid solutions can be somewhat more complex to plan than a Cloud-Only virtual network configuration. Often, these types of connections require collaboration with your network engineer because they involve coordinating network routing as well as configuring VPN devices.