Azure virtual network is the networking service that lets everyone create and manage virtual private networks in Microsoft Azure and securely link them to other virtual networks or their own on-premises networking infrastructure. Fundamental principles of Azure networking match those applicable to traditional, on-premises networks. However, there are also several unique networking characteristics specific to Azure that you must take into account when planning and deploying virtual networks in Azure. You also have to consider that a number of networking features depend on the deployment model that you used to provision the underlying network resources.
When you deploy computers in your on-premises environment, you typically connect them to a network to allow them to communicate directly with each other. Azure virtual networks serve the same basic purpose, although every Azure virtual machine (VM) that you create by using the Azure Resource Manager deployment model must reside on a virtual network. By placing a virtual machine on the same virtual network as other virtual machines, you effectively provide direct IP connectivity among them. You also have the option of connecting different virtual networks together, if your intention is to provide direct IP connectivity after you deploy virtual machines into them. It is also possible to connect virtual networks in Azure to your on-premises networks, effectively making Azure an extension of your own datacenter.
An Azure virtual network constitutes a logical boundary defined by a private IP address space that you designate. You divide this IP address space into one or more subnets. This makes the Azure virtual network functionally equivalent to your on-premises networks. However, in this case, you do not have to manage the underlying infrastructure. Instead, the networking features—such as routing between subnets on the same virtual network—are automatically available. Similarly, by default every virtual machine can access the Internet, which also includes support for outbound connections and Domain Name System (DNS) name resolution.
Note: You can alter the default routing and DNS name resolution functionality within Azure virtual networks by implementing user-defined routes and your own, custom DNS services. You can also use Network Security Groups (NSGs) to allow or block specific types of network traffic based on criteria such as the source IP address, the target IP address, the source port, the target port, and the protocol. NSGs are discussed later in this lesson.
IP addressing in virtual networks
When you create an Azure virtual network, you need to specify its IPv4 address space. The IPv4 address space can contain private and public address ranges. You can use a public IPv4 address range that you own or any of the following RFC 1918 compliant private IPv4 address ranges:
- 10.0.0.0/8 – including all addresses from 10.0.0.1 to 10.0.0.255
- 172.16.0.0/12 – including all addresses from 172.16.0.1 to 172.31.255.255
- 192.168.0.0/16 – including all addresses from 192.168.0.1 to 192.168.255.255
The majority of Azure virtual networks and on-premises networks use the private IPv4 address ranges listed above.
Note: Assigning a public IPv4 address range to an Azure virtual network does not make it publicly routable.
Best Practice: Always plan to use an IP address space that is not in use in your organization, whether it is on-premises or in other virtual networks. Even if you initially plan for a virtual network to be only in the cloud, you might need to establish connectivity to it later. If there is any overlap in address spaces, you will have to recreate the virtual network.
Note: Although Azure supports IPv6 connectivity within its virtual networks, at the present time, its network-related resources—such as load balancers, user defined routes, or network security groups—are not IPv6 capable. For this reason, any subsequent references to IP imply the use of IPv4, unless explicitly stated otherwise.
The Azure platform allocates IP addresses from these ranges by using natively managed Dynamic Host Configuration Protocol (DHCP) service. Each IP address lease has an infinite duration but is released if you deallocate (stop) the virtual machine to which the IP address is assigned. If you want to avoid IP address changes regardless of the state of the virtual machine, you have the option of configuring a static private IP address from the range of IPv4 addresses associated with the virtual network.
Note: A static private IP address in Azure corresponds to a DHCP reservation in the on-premises nomenclature. In on-premises scenarios, assigning a static IP address implies modifying configuration of the network interface within the operating system. You must not use this method with Azure virtual machines, because it will result in dropped connections and connectivity failures. Instead, you need to modify the properties of the network interface attached to the virtual machine via the Azure management interface. To do so, use the Azure portal or the Windows PowerShell cmdlet New-AzureRmNetworkInterface with the PrivateIPAddress switch.
For a virtual machine that must be directly accessible from the Internet, you can assign a public IP address. You can also assign a public IP address to an Internet-facing load balancer. That way, the load balancer distributes inbound traffic from the Internet across all virtual machines in the back-end pool. Alternatively, you can configure network address translation (NAT) on the load balancer, which redirects incoming traffic to individual virtual machines behind it. This way you can share the same IP address across multiple virtual machines and restrict traffic to individual ports on the load balancer level at the same time.
Every virtual network in Azure and most networks on premises consist of one or more subnets. Subnets facilitate segmentation of networks, providing a means of controlling communication between network resources. Each subnet contains a range of IP addresses that constitute a subset of the virtual network address space.
In Azure, within each subnet, the first four IP addresses and the last IP address are reserved, and you cannot use them for virtual machines or cloud services. Effectively, the smallest subnet that you can implement in Azure has the 29-bit subnet mask, which leaves you with three usable IP addresses. IP addresses within a subnet are allocated sequentially in the order of provisioning or bringing online virtual machines on that subnet. For example, the first virtual machine deployed into the subnet 192.168.0.0/24 would, by default, have the IP address of 192.168.0.4. As discussed earlier, you can change this behavior by assigning a static IP address to that virtual machine.
Note: It is relatively easy to move Azure virtual machines across subnets within the same virtual network. However, a move like this is not possible across subnets on different virtual networks. Such a restriction does not apply in on-premises environments. If you must relocate a virtual machine to another virtual network, you have to delete it while preserving its disks and then redeploy it to the target network using the existing disks.
Names of resources created in Azure can be resolved by using Azure-provided name resolution or by using a customer-provided DNS server. For example, the client DNS resolver on an Azure virtual machine can use the Azure-provided DNS to resolve the Internet-based names. The same mechanism allows for automatic name resolution between virtual machines that reside on the same virtual network and those that you deploy by using Azure Resource Manager. This is because virtual machines deployed this way share the same DNS suffix. When using the classic deployment model, the same DNS suffix applies to virtual machines within the cloud service only. Effectively, if you want to be able to resolve names of virtual machines that belong to different cloud services in the same virtual network, you must reference them by using their fully qualified domain names (FQDNs).
There are, however, situations in which you have to implement a custom DNS server. This is most evident when implementing hybrid connectivity between an Azure virtual network and an on-premises network. Another common scenario involves deploying your own Active Directory domain environment in Azure. In both cases, you need to point Azure virtual machines to your own DNS server. You can accomplish this by modifying the properties of the Azure virtual network. However, for the Azure virtual machines to recognize the new DNS settings, you have to restart them first. This is another difference that distinguishes Azure-based network operations from their equivalent on-premises activities where these changes take place dynamically following the renewal of DHCP leases.