You can use a private IPv4 space that you specify, and different virtual subnets can
be created within the virtual network.
The virtual network can be connected to your on-premises network by using site-
to-site VPN and/or ExpressRoute, and it can also support point-to-site VPN
connections.
You have the ability to use custom DNS, such as an on-premises DNS server, a
DNS server deployed to Microsoft Azure IaaS, or even a public DNS service. This
allows DNS resolution outside just those resources within a cloud service.When you put these capabilities together, your on-premises network can be extended
into Microsoft Azure, bringing seamless connectivity that is not using Internet-facing
public IP addresses and removing the need to use the public IPs for the virtual
machines unless specifically required to publish services out to the Internet, such as
for a web server. Figure 12.15 shows the new connectivity when using a virtual
network.
Figure 12.15 Connectivity when using virtual networks
A virtual network cannot cross regions and exists within an Azure subscription. If you
wish to create services in different regions or different subscriptions, separate Azure
virtual networks will be required. Make sure that all virtual networks use a unique IP
address space. The valid IP address ranges that you can specify to use for a virtual
network are those defined in RFC 1918, which are the private, non-Internet routable
addresses, as follows:
10.0.0.0 to 10.255.255.255 (10/8 prefix)
172.16.0.0 to 172.31.255.255 (172.16/12 prefix)
192.168.0.0 to 192.168.255.255 (192.168/16 prefix)Additionally, you can bring a portion of other ranges, such as from a class B network
your organization acquired in the early days of the Internet. When deciding which IP
network to use in Microsoft Azure, always consider that even if you don’t want to
connect Microsoft Azure to your on-premises network today, you may want to do so in
the future. Therefore, use an IP network that is not used on premises so that