If you would like to read the other parts in this article series please go to:
- Hybrid Network Infrastructure in Microsoft Azure (Part 1)
- Hybrid Network Infrastructure in Microsoft Azure (Part 2)
- Hybrid Network Infrastructure in Microsoft Azure (Part 3)
- Hybrid Network Infrastructure in Microsoft Azure (Part 5)
- Hybrid Network Infrastructure in Microsoft Azure (Part 6)
- Hybrid Network Infrastructure in Microsoft Azure (Part 7)
- Hybrid Network Infrastructure in Microsoft Azure (Part 8)
- Hybrid Network Infrastructure in Microsoft Azure (Part 9)
- Hybrid Network Infrastructure in Microsoft Azure (Part 10)
- Hybrid Network Infrastructure in Microsoft Azure (Part 11)
Introduction
In part 1 of this series, Deb began the discussion about hybrid network infrastructure with some thoughts about what hybrid clouds are about, and then talked about some of the networking functionality that you get when you adopt Azure Infrastructure Services. There was also an introduction to the Datacenter Extension Reference Architecture Diagram that Tom put together with Jim Dial and several other people at Microsoft. In part 2 of the series, Tom joined in as co-author and we went over site to site VPNs and point to site VPNs. In part 3 we took a look at the Azure dedicated WAN link service, which goes by the name of ExpressRoute, and also discussed the Azure Virtual Gateway, which is located on the edge of your Azure Virtual Network and enables you to connect your on-premises network to an Azure Virtual Network.
We’ll continue the discussion by working our way through our list of network capabilities that are available in Azure at the time this article was written:
- Site to site VPNs
- Point to Site VPNs
- Dedicated WAN links
- Virtual network gateways
- Azure Virtual Networks
- Inter-virtual Network connectivity
- External load balancers
- Internal load balancers
- Network Security Groups
- Virtual machine ACLs
- Third party proxy firewalls
- Dual-homed
- Dedicated public IP addresses
- Static IP addresses on virtual machines
- Public addresses on virtual machines
- DNS
Next stop – Azure Virtual Networks.
Azure Virtual Networks
We’ve referenced Azure Virtual Networks frequently in the first three parts of this article series but we haven’t really given it a proper introduction, so we’ll start by remedying that. An Azure Virtual Network is very similar to the networks you create using Hyper-V or any other virtualization platform. For example, when you create a virtual switch in Hyper-V, you’re essentially creating a virtual network. It works pretty much the same (from a functional perspective) with Azure Virtual Networks.
To this point I’ve assumed for purposes of the articles that you will have an Azure Virtual Network because we have been talking about hybrid scenarios, such as that described in the Datacenter Extension Reference Architecture Diagram. At least one Azure Virtual Network is required if you’re going to connect your on-premises datacenter to Azure resources, whether those resources are based on infrastructure as a service (IaaS) or platform as a service (PaaS). Note that you can create a “hybrid” connection to Office 365 using ExpressRoute, but it’s unclear in the documentation whether or not that requires a Azure Virtual Network. We weren’t able to find out details on this, but for the purposes of our current discussion, it doesn’t matter since we’re talking about hybrid datacenter extension networking into Azure.
Standalone VMs
With all that said, you don’t have to create an Azure Virtual Network to run virtual machines in Azure Infrastructure Services. You can create what are sometimes called “standalone” virtual machines. These are virtual machines that do not exist on an Azure Virtual Network. They exist on the Azure network fabric, but not on an Azure Virtual Network.
If you create a virtual machine in Azure Infrastructure Services and do not connect it to an Azure Virtual Network, then it will only be able to communicate with other devices by going out through the Internet. That is to say, the only network connection this standalone virtual machine will have is an Internet connection. In this scenario, if you have a second standalone virtual machine in Azure Infrastructure Services, the only way these two virtual machines could communicate with each other is by connecting to each other over the Internet. They essentially “loop back” through the Internet to reach each other instead of communicating directly over the Azure network fabric.
Advantage of creating an Azure Virtual Network
In a datacenter extension scenario like the one we’re concerned with here, standalone virtual machines aren’t of much use. We want to extend our datacenter, which means placing a lot of virtual machines into Azure. We want those virtual machines to be able to communicate with each other over the Azure network fabric, and we want those virtual machines (at least some of them) to be able to communicate with resources on the on-premises network.
That is going to require an Azure Virtual Network. With an Azure Virtual Network we can:
- Create a connection between the on-premises network and the Azure Virtual Network using either site to site VPN or ExpressRoute.
- Enable direct communications between virtual machines that are located on the same Azure Virtual Network, without requiring them to connect to one another over the Internet.
- Benefit from the built-in DNS services that come with the Azure Virtual Network, so that virtual machines can access one another by name.
- Connect multiple Azure Virtual Networks to each other using site to site VPNs that traverse the Azure network fabric instead of going over the Internet.
- Isolate virtual machines from other virtual machines that are hosted in Azure, and also isolate them from the Internet.
- Allow inbound access from the Internet to selected virtual machines.
- Configure forced tunneling on virtual machines within the Azure Virtual Network, so that they are not able to initiate outbound connections to the Internet.
- Load balance connections to virtual machines that are located on the Azure Virtual Network; inbound connections from the Internet can be load balanced, as well as connections from other virtual machines on the Azure Virtual Network. In addition, connections from the on-premises network to virtual machines on the Azure Virtual Network can be load balanced.
- Enforce network access controls on either a subnet (I’ll talk about this in a bit) or virtual machine basis.
- Take advantage of dynamic (DHCP) addressing of virtual machines or static IP addressing (including support for using public IP addresses on an Azure Virtual Network).
- Insert multi-homed network devices that can perform a variety of duties, such as a firewall, IDS/IPS, and proxy.
- And a lot more!
Keep in mind that Microsoft Azure is growing quickly, and that this feature set will definitely expand over time, with changes and additions coming frequently. Thus you should make sure that you check this link on a periodic basis so as to find out when new features and capabilities are being added to Azure Virtual Networks.
How Azure Virtual Networks work
Azure Virtual Networks communicate with the Azure network fabric in a manner that is similar to the way that the virtual networks you use in Hyper-V communicate with your on-premises network fabric. There is a minor difference, however. When you create virtual switches in Hyper-V, you typically consider all of the machines that are connected to that virtual switch to be on the same collision domain, and therefore, all of the machines are going to be on the same subnet (as defined by their network ID).
On an Azure Virtual Network, there is no concept of virtual switch exposed to you. The reason for this is that you’re a consumer of the cloud service, and therefore the details of how the infrastructure serves up the capabilities you require shouldn’t be your concern That is, in fact, at the very heart of cloud computing: the infrastructure should be transparent to the customer/user. You might think of each Azure Virtual Network you create (and you can create as many as you like) as being comparable to separate Hyper-V switches. All of the machines that are on the same Azure Virtual Network can communicate with one another (if you want them to), and all of the machines that are connected to the same Hyper-V switch can also communicate with one another.
When you create a new Azure Virtual Network, you will be asked for an RFC 1918 (private address) range from which IP addresses can be assigned. You will also be asked to create subnets within one of the Class A, B or C networks (although you can and should use CIDR networking) that are available to you. You can create as many subnets as you like.
Addressing is handled for you automatically, and gateway addresses are assigned to virtual machines on each subnet automatically. Azure handles the routing table entries for all of the subnets that are on your Azure Virtual Network. Of course, if you want to use static IP addressing, you’ll need to check the routing table information either on a virtual machine that is using DHCP or by querying the system.
These routing table entries weren’t very flexible in the past, but recent updates make it possible for you to create customized user defined routes that will support running virtual appliances situated between subnets.
Summary
In this. Part 4 of this multi-part article, we focused on Azure Virtual Networks and went over some of the benefits that you get when you create an Azure Virtual Network as well as what happens when you don’t create an Azure Virtual Network. In the next installment, Part 5, we’ll go into a little more detail about Azure Virtual Networks and then move on to the next topic on our list. See you then!
If you would like to read the other parts in this article series please go to:
- Hybrid Network Infrastructure in Microsoft Azure (Part 1)
- Hybrid Network Infrastructure in Microsoft Azure (Part 2)
- Hybrid Network Infrastructure in Microsoft Azure (Part 3)
- Hybrid Network Infrastructure in Microsoft Azure (Part 5)
- Hybrid Network Infrastructure in Microsoft Azure (Part 6)
- Hybrid Network Infrastructure in Microsoft Azure (Part 7)
- Hybrid Network Infrastructure in Microsoft Azure (Part 8)
- Hybrid Network Infrastructure in Microsoft Azure (Part 9)
- Hybrid Network Infrastructure in Microsoft Azure (Part 10)
- Hybrid Network Infrastructure in Microsoft Azure (Part 11)
