Azure Virtual Networks and Cloud Services (Part 1)

by Debra and Tom Shinder [Published on 4 Sept. 2014 / Last Updated on 4 Sept. 2014]

This article explains what Microsoft Azure is and how it works.

If you would like to read the other parts in this article series please go to:

 Azure Virtual Networks and Cloud Services (Part 2): Defining a Cloud Service
 Azure Virtual Networks and Cloud Services (Part 3): Communications Scenarios

Introduction

Most IT pros have heard of Microsoft Azure (formerly known as Windows Azure) by now, although many aren’t
exactly sure what it is and how it works. Well, we’re here to help clear up some of the confusion. To put it very simply,
Microsoft Azure is a collection of public cloud services that allow you to do the things you can do in your own
datacenter, but without the hassle of having to manage a number of hardware and software components that you
otherwise would need to.

Microsoft Azure public cloud services include Platform as a Service (PaaS) and Infrastructure as a Service (IaaS).
The IaaS feature set is also known as Azure Infrastructure Services (AIS). It’s important to note that Azure
Infrastructure Services represents a collection of IaaS capabilities that are available in Microsoft Azure; it is not a
specific “thing” or option that you buy from Azure. When you purchase a subscription from Microsoft Azure, you get
everything that Azure has to offer, which includes both the PaaS and IaaS services.

In this article, we’re going to focus on the IaaS service because that’s what will be of most interest to IT pros. PaaS is
generally used by developers. As a quick reminder, Infrastructure as a Service is one of the three cloud service
models defined by the National Institute of Standards and Technology (NIST) documentation; the other two are
Platform as a Service and Software as a Service.

Advertisement

IaaS – What it does for you

The Infrastructure as a Service cloud service model provides you with core infrastructure components such as
compute, storage and networking. Cloud service providers take care of these for you on their premises. You don’t
have to worry about them – that’s one of the advantages of using the cloud. The cloud service provider abstracts the
physical components away from you, the cloud service customer. This enables you to obtain the compute power, the
storage capacity and the networking capabilities you need without the necessity of worrying about how they work,
where they are, and how much of anything is available. The cloud service provider will tell you what you can get and
how much of it you can get (and how much it will cost you).

Azure Infrastructure Services allows you to create virtual machines in Azure. These virtual machines are like the
virtual machines that you can create in your own datacenter, or even on your own desktop or laptop computer. The
only difference is that Microsoft is hosting the storage, networking and compute infrastructure on which you place
those virtual machines. You pick the operating system you want to install, and after the operating system is installed,
you can put any software you want on your virtual machines.
 Microsoft also handles the replication of the virtual machines so that, in the event of an Azure data center failure or
even a disk failure, your virtual machines will be recoverable. That said, you shouldn’t think of this transparent
replication of virtual machines as a backup plan from which you can recover information that might have been lost or
corrupted. The replication is in real time and if you break something on your virtual machine, the “brokenness” will be
replicated to three other disks and even three additional disks in an Azure datacenter at least 400 miles away.

VM network options

When you’re using Microsoft Azure to host your VMs, you need to think about where you want to put your virtual
machine. You have two options:

 Put the virtual machine on a “network” of its own – this is called a “standalone” virtual machine
 Put the virtual machine on a virtual network

If you don’t want or need a virtual machine to be able to communicate with other virtual machines over the Azure
network, then you can create a standalone virtual machine. The standalone virtual machine can still communicate
with other devices by doing so over the Internet. It can communicate with any Internet connected device if you want it
to – and that includes other virtual machines that are located in Azure. However, if you want a standalone virtual
machine to communicate with other virtual machines that are located in Microsoft Azure, those communications will
have to go out to the Internet and then come back into Azure.

If you want virtual machines in Azure to communicate more directly with each other, then a better option is to put
them on the same Azure Virtual Network. Azure Virtual Networks are very much like the networks that you create in
VMware or Hyper-V, where they are defined by all devices connected to the same virtual switch. Keep in mind that
the Azure Virtual Network is similar to these virtual switches, but there are some significant differences between the
two and we’ll talk about some of those later.

An Azure Virtual Network can be connected to other networks too. You can use site to site VPN connections to
connect an Azure Virtual Network to your on-premises network, or even to another Azure Virtual Network. If you have
network performance requirements that are greater than what a site to site VPN to Azure will handle (which is
approximately 80Mbps), then you can connect your Azure Virtual Network to your on-premises network by using
ExpressRoute, which represents what is essentially a dedicated WAN link between your Azure Virtual Network and
your on-premises network.

Extending the datacenter

Azure Virtual Networks make it possible for you to move some services that you currently have on-premises to the
Azure public cloud. For example, you might be hosting front-end web servers for a multi-tier application in your
corporate DMZ. Instead of hosting them on your own network, why not put them on an Azure Virtual Network? Those
front-end web servers can then connect to their back-end components on the corporate network through the site to
site VPN or ExpressRoute.

What you’re really doing here is extending your datacenter. You might think of it as a sort of branch office in the cloud
(although the branch office analogy falls apart a bit since the type of services you’d typically put on an Azure Virtual
Network aren’t those that you’d host in a branch office. For example, you would put file servers and proxy servers in a
branch office, something you’re not likely going to do in Azure).

Understanding IP addressing in Azure

With all of this as a background, let’s now delve into some of the specifics of Azure Virtual Networks. When you’re
working with Azure Virtual Networks, there are two types of IP addresses that you need to be aware of:
 Virtual IP addresses
 Dynamic IP addresses

The naming conventions that Microsoft decided to use here might be a bit confusing since the names of the different
IP addresses don’t clearly connote the purposes of those addresses. So let’s clear that up.

Virtual IP addresses

A virtual IP address is an address that external clients can use to connect to a virtual machine located on an Azure
Virtual Network. If you configure the virtual machine as an “endpoint” (something we’ll talk about later), then external
devices can connect to the virtual machine over the Internet. The IP address that the external devices will use as the
destination IP address to reach the virtual machine on the Azure Virtual Network will be the virtual IP address.

Virtual IP addresses are therefore public IP addresses (that makes sense, since you can’t connect to private RFC
1918 addresses over the Internet). It seems as if it would have been more logical to call these addresses “Azure
Virtual Machine Public Addresses” or just “Public Addresses,” but it is what it is (at least until Microsoft decides to do
one of their all-too-frequent name changes). At any rate, you need to remember that these are public addresses that
you can use to connect to virtual machines located on an Azure Virtual Network.

Now you’re probably wondering why they called them “virtual” IP addresses. I’m only guessing here, but the most
likely reason for this is that the router in front of the virtual machines on the Azure Virtual Network, which is
responsible for routing connections to those virtual machines, is probably using some kind of load balancing, similar
to Windows Network Load Balancing. In Network Load Balancing, you create a virtual IP address that is assigned to
all members of the NLB array. It’s a “virtual” IP address because it belongs to all the members of the array and not to
any single NIC in the array. Again, that’s not the official story; it’s just a guess, but it does make sense.

Dynamic IP addresses

Dynamic IP addresses are the IP addresses that are assigned to the virtual machines themselves. When you read
the word “dynamic IP address”, what does that make you think of? There’s a good chance that you were thinking of
Dynamic Host Configuration Protocol or DHCP. Virtual machines that are located on an Azure Virtual Network
receive their IP addressing information from a DHCP server. You can see this by doing an ipconfig from the
command prompt. As you can see in the figure below, the DHCP server has assigned an IP address and that IP
address lasts for about 36 years. So, while it’s not exactly a permanent IP address, it’s about as close as you’re going
to get to permanent.

You can also see some other interesting information in the ipconfig print out. You can see the address of the DHCP
server, the DNS server, and the DNS suffix. We’ll talk about DNS later, but at this point it’s worth mentioning that
when you create an Azure Virtual Network, a simple DNS service will be available to you as well. “Simple” is the key
operating principle here, and you’ll learn later that this simple DNS service is going to work for most hybrid networking
scenarios.
Figure 1

Again, I don’t know why the Naming Powers That Be thought the IP addresses that are assigned to virtual machines
should be called “dynamic IP addresses”. Sure, they are dynamic since they’re assigned by DHCP, but for all intents
and purposes they behave like permanent IP addresses. Why not just call them “virtual machine addresses” or
“internal VM addresses”? Oh well, at least we know what they are now.

Assignment of IP addresses to new Azure VMs

 When you create a new virtual machine in Microsoft Azure, a NIC is attached to the virtual machine for you and the
address is automatically assigned to that NIC. Sorry but you can’t assign your own addresses. The only control you
have in-so-far as address assignment is concerned is specifying the Network ID that you want to assign to your Azure
Virtual Network.

For example, you can assign your Azure Virtual Network the network ID 10.0.1.0/24 and all the virtual machines you
create on the network will be assigned addresses in that Network ID, but you can’t choose which addresses are
assigned to which individual virtual machines. If you do try to do this, then the virtual machine will be disconnected
from the Azure Virtual Network and you won’t be able to get back into the virtual machine to configure it to use DHCP
again. You’re locked out forever and your only choice is either to delete that virtual machine and start over, or you
can save the virtual machine as a “disk” in Azure Infrastructure Services and create a new virtual machine from that
disk.

Summary

At this point, you should have an understanding of the most important things you need to know about virtual and
dynamic IP addresses in Azure. We’ll use that understanding to ready ourselves for the next article in this series,
which will be about how these IP addresses work within the context of “cloud services” and how communications take
place between virtual machines, Azure Virtual Networks and cloud services.

 Home

 Articles & Tutorials

 Windows Azure

Azure Virtual Networks and Cloud Services (Part 2):

Defining a Cloud Service
by Debra and Tom Shinder [Published on 18 Sept. 2014 / Last Updated on 18 Sept. 2014]

In this article we'll attempt to clarify some definitions and explain the relationships between virtual public IP
addresses, dynamic IP addresses, cloud services and Azure Virtual Networks in Microsoft Azure, and how
connections to virtual machines are accomplished from over the Internet.

If you would like to read the other parts in this article series please go to:

 Azure Virtual Networks and Cloud Services (Part 1)

 Azure Virtual Networks and Cloud Services (Part 3): Communications Scenarios

Introduction
 In the first article in this series on Azure Virtual Networks and cloud services, we spent most of our time going over
the details of IP addressing for Azure virtual machines. As a quick reminder, there are two types of IP addresses that
are relevant to this discussion:

 Dynamic IP addresses – these are the private IP addresses that are assigned to the virtual machines on the Azure
network.
 Virtual IP addresses – these are public IP addresses assigned to a router type device (we would like to be more
specific, but those details aren’t available outside of Microsoft) that allows inbound connections from the Internet to
the virtual machines located on Azure.

We also talked about how virtual machines communicate with each other and how virtual machines located in Azure
communicate with devices located outside of Azure. Make sure to check out Part 1 of this series for those details.

Advertisement

Understanding Azure IaaS Cloud Services

Let’s pick up the story here with a discussion about what Azure calls a “cloud service”. We’ve found that people get
very confused when trying to figure out what a cloud service does in the context of Azure Infrastructure Services.
That confusion is not surprising, since the terminology was designed for the PaaS component of Azure, not for Azure
Infrastructure Services. But since the PaaS offerings were built before the Azure Infrastructure Services components
were, the Azure Infrastructure Services components inherited some of that previous terminology, much to the
consternation of Azure Infrastructure Services users.

Here’s a definition of an Azure IaaS cloud service that will make it easy for you to understand what it is in the context
of Azure Infrastructure Services:

 A cloud service is a network container where you can place virtual machines.
 All virtual machines in that container can communicate with each other directly through Azure (and therefore don’t
have to go out to the Internet to communicate with each other).
 This container is also assigned a DNS name that is reachable from the Internet.
 A rudimentary DNS server is created and can provide name resolution for all virtual machines within the same cloud
service container (note that name resolution provided by the DNS server is only available to the virtual machines that
are located within the cloud service).
 One or more Virtual IP Addresses (VIPs) are assigned to the container and these IP addresses can be used to allow
inbound connections from the Internet to the virtual machines.

That’s all there is to it. Well, maybe not all there is – but that’s the basic definition of a cloud service within the context
of virtual machines in Azure Infrastructure Services.

For those who are visually oriented, let’s look at a simple graphic illustration to get a better idea of how this works.
Figure 1

In the figure above, we see a virtual machine cloud service. That cloud service is assigned virtual IP address
137.135.88.69. External users can access the virtual machines within the cloud service by connecting to that IP
address. There are two virtual machines contained within this cloud service – VM1 and VM2. These virtual machines
are assigned IP addresses 10.0.0.10 and 10.0.0.25 respectively, and they can communicate with each other using
these IP addresses. These IP addresses and virtual machine names are also registered in the DNS service that was
created for this cloud service.

The first question you might ask is “where did these IP addresses come from? Do I have any control over this?” The
answers to these questions depend on which IP address you’re talking about and whether or not you put these virtual
machines into an Azure Virtual Network.

VIPs and DIPs

First, let’s talk about the virtual public IP addresses (VIPs). You don’t have any control over which VIP is assigned to
your cloud service. This shouldn’t be a problem, since you don’t have that kind of control anywhere else, either. Sure,
if you’re assigned a block from your ISP, you can choose which IP addresses to use within that block, but you don’t
control which IP address blocks you can have; that’s because you don’t own the IP addresses, the provider does.

Well, then, what about the Dynamic IP addresses (DIPs)? If you don’t put the virtual machines into an Azure Virtual
Network, then your IP addresses will be automatically assigned IP addresses from any RFC 1918 network ID. You
don’t have control over what these IP addresses will be, and you can’t manually change the IP addresses assigned to
the virtual machines. If you do that, the virtual machine will become “disconnected” from Azure and you won’t be able
to access that virtual machine over the network, and the only way you’ll be able to recover from the disaster is to
create a new virtual machine using the VHD file used by the disconnected virtual machine. It would be great if Azure
provided console access over the VMbus like Windows Server 2012 Hyper-V does, but it doesn’t

Getting connected

Now wait a minute – if you don’t have control over the individual IP addresses, or even the IP address ranges from
which IP addresses are assigned to the virtual machines, then how are you going to connect your on-premises
network to your virtual machine network? You must have some level of control, so that you can create your routing
table entries.

The solution to this problem is to put your virtual machines into an Azure Virtual Network. When you create an Azure
Virtual Network, one of the things you must do is define the range of IP addresses that comprise that Azure Virtual
Network. For example, if you need addresses in the 10.0.1.0/24 range, you just create an Azure Virtual Network that
will use this network ID. When new virtual machines are created and placed onto that Azure Virtual Network, they will
be automatically assigned addresses within that range. Of course, you still don’t have control over the specific IP
address that will be assigned to a particular virtual machine, but at least now you can reliably predict the network ID
from which IP addresses will be derived.

The cloud service (container) and endpoints

Okay, now let’s get back to talking about the cloud service container itself. Refer to the figure below as we talk about
cloud service assignment. When you create a new virtual machine, it will be placed into a cloud service. You can
create a new cloud service, and the new virtual machine will be placed into that cloud service. Or, you can place that
virtual machine on to an Azure Virtual Network. In almost all cases, you’ll want to put the virtual machine into an
Azure Virtual Network because this makes the address space easier to manage, and it also gives you many more
options in terms of allowing virtual machines to connect over secure connections to other Azure Virtual Networks and
to your on-premises networks.

Note:
It’s important to be aware that even when you place a virtual machine into an Azure Virtual Network, that virtual
machine will still be placed into a cloud service. As you’ll see later, there is an association between Azure Virtual
Networks and cloud services.

At the bottom of the figure below there is an option to configure “endpoints” (see, we told you in part 1 of this article
that we would get around to discussing endpoints). When you configure a virtual machine to be an endpoint, what
you’ve done is make it possible for a device located anywhere on the Internet to connect to that endpoint (virtual
machine) using the IP address assigned to cloud service’s VIP. Notice that there are two default endpoint definitions
defined: one for RDP and one for remote PowerShell. You can create new ones, and you can also remove the default
endpoint definitions if you don’t want them. The RDP endpoint allows you to connect directly to the virtual machine
over the Internet using the Remote Desktop Protocol.
Figure 2

The figure below shows a cloud service with the Fully Qualified Domain Name
(FQDN)strawberryletter23.cloudapp.net. Where did that name come from? The name is derived from two sources.
The first source is the name of the first virtual machine you created and placed into that cloud service. Look at the
figure above. Do you see where you have the option to create a “new cloud service”? The new cloud service you
create will take on the name that you assign to the virtual machine. The virtual machine name also becomes
the host name component of the FQDN of your cloud service. The domain name of the cloud service
is cloudapp.net. All cloud service DNS names in Microsoft Azure will have the same domain name as part of their
FQDN, which will always be cloudapp.net

Keep in mind that the cloud service DNS name provides access to all the virtual machines inside the same cloud
service. If so, then how do we connect to the different virtual machines within the cloud service? In most cases we will
have only one VIP assigned to the cloud service (at this point, we’re not going to talk about Reserved IP Addresses.
We’ll get to those later)?
Port redirection to the rescue

The way we handle this in Azure is to take advantage of port redirection. For example, suppose we want to provide
RDP access from the Internet to the two virtual machines in the figure below. The virtual machines themselves listen
on TCP port 3389 for the RDP connection. We could open up TCP port 3389 on the Azure router at the edge of our
cloud service , but since we only have one IP address, we can only do that for a single virtual machine. We have
TWO virtual machines. That’s why we use port redirection.

In the figure below, you can see that VM1 is listening on TCP port 55736 and VM2 is listening on TCP port 52539. If
you want to connect to VM2 from your on-premises network, you could open an RDP client and set the address to
connect to strawberryletter23.cloudapp.net:52539 and it will connect to the VIP – 137.135.88.69 on TCP port
52539. The cloud service edge router will then redirect the connection to the VM address, 192.168.1.15 and to TCP
port 3389 on that virtual machine. Port redirection allows you to have many virtual machines in a cloud service and
make them all available from the Internet with a single public IP address.

Note:
The router at the edge of the cloud service is also referred to as a “software load balancer”. This makes sense given
that the public address is referred to as virtual IP address. Incoming connections are load balanced so that if one of
the edge routers becomes unavailable, another one can take its place. This is similar to how we used to configure
ISA firewall NLB arrays. We prefer the term “edge router” because the role of the load balancer is secondary to the
discussion.

Figure 3

Summary

In this, Part 2 of our discussion of Azure virtual networks and cloud services, we attempted to clarify some definitions
and explain the relationships between virtual public IP addresses, dynamic IP addresses, cloud services and Azure
Virtual Networks in Microsoft Azure, and how connections to virtual machines are accomplished from over the
Internet. Join us for Part 3, where we’ll delve more deeply into all of this and look more closely at how Azure Virtual
Networks and cloud services work together.
 If you would like to read the other parts in this article series please go to:

 Azure Virtual Networks and Cloud Services (Part 1)

 Azure Virtual Networks and Cloud Services (Part 3): Communications Scenarios

Azure Virtual Networks and Cloud Services (Part 3):

Communications Scenarios
by Debra and Tom Shinder [Published on 2 Oct. 2014 / Last Updated on 2 Oct. 2014]

In part two of this series, we talked about what a cloud service was and how cloud services related to networking
concepts within Microsoft Azure. In this, part 3 of the series, we'll expand upon what we learned in the previous article
and examine some communications scenarios between virtual machines that are located within different cloud
services and different Azure Virtual Networks.

If you would like to be notified of when Debra and Tom Shinder release the next part in this article series please sign
up to our CloudComputingAdmin.com Real Time Article Update newsletter.

If you would like to read the other parts in this article series please go to:

 Azure Virtual Networks and Cloud Services (Part 1)

 Azure Virtual Networks and Cloud Services (Part 2): Defining a Cloud Service

Introduction

In part 2 of our article series on virtual networks and cloud services, we began to look at how communications are
made from external locations to a virtual machine that lives within a cloud service. With that knowledge in place, we
can look at various scenarios where virtual machines need to communicate with one another.

As we mentioned in the previous article, virtual machines that are located in the same cloud service will be able to
communicate with each other. Connections can be made either by using the IP address or the name of the computer
located on the same cloud service. You can use the names of the virtual machines that are located on the same
cloud service because Azure includes a simple DNS server that provides some basic name resolution for all virtual
machines located in the same cloud service.

Advertisement

The role of the virtual network

Now let’s look at the concept of a virtual network and see how it is related to cloud services. An Azure Virtual Network
allows you to define a set of IP addresses that will be used by all the machines located on the same Azure Virtual
Network. In addition, when you put virtual machines onto an Azure Virtual Network, you can connect the Azure Virtual
Network to an on-premises network.
 This connection between an Azure Virtual Network and an on-premises network is sometimes referred to as “hybrid
networking”. It’s called hybrid because you’re connecting networks that are located within the constructs of two
different cloud models; the Azure Virtual Network is located on a public cloud, and the on-premises network is located
on a “private cloud”. That said, very few organizations at this point have a true private cloud in place. Therefore, for
the sake of accuracy, we will note here that most hybrid networking scenarios really represent hybrid IT infrastructure,
rather than hybrid “cloud” infrastructures. It’s a small distinction but an important one.

Take a look at the figure below. You can see that we have the following components:

 Cloud service AP1.CLOUDAPP.NET

 Cloud service AP2.CLOUDAPP.NET
 Two virtual machines contained within AP1.CLOUDAPP.NET named:
o VM1 – IP address: 192.168.1.7
o VM2 – IP address: 192.168.1.15

 One virtual machine contained within AP2.CLOUDAPP.NET named:

o VM1 – IP address: 192.168.1.18

 Both cloud services are located on the same Azure Virtual Network – Virtual Network

Figure 1

Because all of the virtual machines are located on the same Azure Virtual Network, these virtual machines can
communicate directly with each other. They do not need to loop back through the Internet to connect to one another.
This greatly improves network performance for these machines that need to communicate with each other, since data
transfer rates between computers on the same local network are always faster than the Internet connection.

Note that it appears from the diagram that all of the virtual machines are located on the same network ID (in fact they
are, but the subnet mask isn’t noted on the figure, so from the figure you can’t tell with absolute certainty). The
network ID for all of the virtual machines on the Azure Virtual Network (named Virtual Network in the figure) is
192.168.1.0/24. That’s because when you create the Azure Virtual Network, you need to define an address range for
the virtual network. After you do that, virtual machines will be assigned an IP address within that range from a DHCP
server.
 Virtual machine names

Did you notice that two of our virtual machines in this scenario have the same name? On cloud
serviceAP1.CLOUDAPP.NET there is a virtual machine with the name VM1. On cloud
service AP2.CLOUDAPP.NET there is a virtual machine with the name VM1. This seems as if that would be a big
setup for a name collision, doesn’t it? Well, it would be if we were using NetBIOS and WINS, but we’re not.

Just as you can have two co-workers named John who are distinguished by their different last names, our VMs don’t
really have the same full name at all. The virtual machine names are actually FQDNs, and that means name
resolution is managed through DNS. Therefore, the actual names of the virtual machines as they’re seen by the
network and other machines are:

 VM1.AP1.CLOUDAPP.NET
 VM1.AP2.CLOUDAPP.NET

This brings up an important “gotcha,” though. If you want to connect to either of these virtual machines using its
name, you can’t just use the host name portion of the FQDN; instead you need to use the entire FQDN. This is the
way we disambiguate the names. Of course, this isn’t anything new, but if you’re not a DNS junkie, you might not
have thought about this. Now you know.

Connecting external users

Let’s see if you remember what we talked about in part 2 of this article series. Imagine that you want an external user
to connect to the virtual machines VM2.AP1.CLOUDAPP.NET and VM1.AP2.CLOUDAPP.NET. When an external
user connects to these virtual machines, will they need to connect to the same public IP address in front of the virtual
machines, or will they need to connect to two different IP addresses, one for each virtual machine?

The answer is that they will need to connect to two different public IP addresses, one for each of the virtual machines.
The reason for this is that these two virtual machines are located on two different cloud services. Remember, each
cloud service has a single external IP address that can be used to allow inbound access into the virtual machines that
are contained within the cloud service. So, even though these machines can connect directly to each other because
they are on the same Azure Virtual Network, inbound access from the Internet to these virtual machines will still have
to take place over two different public IP addresses.

In addition, for outbound access from each of the cloud services, the source IP address of outbound communications
will show two different source IP addresses – one for each of the cloud services.

In other words, you should think of each of the cloud services located on the same Azure Virtual Network as having
its own inbound and outbound gateway. This would be very similar to a scenario where you have virtual machines on-
premises that are located on the same virtual switch, but you have configured them to use two different gateways.

VMs on different cloud services and different Azure Virtual Networks

Now let’s take a look at another, slightly more complex example. This time we have two Azure Virtual Networks
namedVNet1 and VNet2. In the figure below you can see the following:

 Cloud service AP1.CLOUDAPP.NET

 Cloud service AP2.CLOUDAPP.NET
 Virtual machines contained in AP1.CLOUDAPP.NET:
o VM1
o VM2

 Virtual machines contained in AP2.CLOUDAPP.NET:

o VM1

 Azure Virtual Network VNet1

 Azure Virtual Network VNet2
 Azure Virtual Network VNet1 contains
o Cloud service AP1.CLOUDAPP.NET

 Azure Virtual Network VNet2 contains

o Cloud service AP2.CLOUDAPP.NET

Figure 2

Overall, this scenario includes virtual machines that are located on two different cloud services and two different
cloud services that are contained within two different Azure Virtual Networks.

What is the communications path between vm1.ap1.cloudapp.net and vm1.ap2.cloudapp.net? Will these two
virtual machines be able to communicate directly with one another over Azure or will they need to loop back through
the Internet?

The answer is that in this case, they will need to communicate over the Internet. If vm1.ap1.cloudapp.net initiates a
connection to vm1.ap2.cloudapp.net, it will need to resolve the FQDN of vm1.ap2.cloudapp.net to the public IP
address that is in front of the AP2.CLOUDAPP.NET cloud service, and then send the communications request to that
address. The Azure router (often referred to a “software load balancer”) will then reverse NAT the inbound connection
to vm1.ap2.cloudapp.net.

The reason for this is that these two virtual machines are:

 Not located in the same cloud service

 Not located on the same Azure Virtual Network

Without one of these two conditions being met, the virtual machines cannot communicate directly and instead they
must loop back through the Internet to communicate with each other.
Or, that’s how it used to be. Now there is a way that the machines can communicate directly, but it requires jumping
through a lot of hoops. You might or might not want to do that, but at least you now have the option.

This came about because, as you can imagine, people who were interested in using Microsoft Azure weren’t overly
thrilled about having to loop back through the Internet to allow virtual machine communications between two Azure
Virtual Networks. For one, there are security concerns since there could be a lot of proprietary information going
through those channels, and there’s also the performance hit that you take by doing that. They begged for an
alternative – and now they have it.

Recently Microsoft announced VNet to VNet connectivity over the Azure networking fabric. This allows you to create
a site to site VPN connection between two Azure Virtual Network. There are a few caveats that you’ll need to be
aware of, such as the necessity to make sure you are using two different address spaces between the two different
Azure Virtual Networks, but performance and security should be a lot better with this configuration. We’ll talk more
about VNet to VNet communications in a future article.

Summary

In part two of this series, we talked about what a cloud service was and how cloud services related to networking
concepts within Microsoft Azure. In this, part 3 of the series, we expanded upon what we learned in the previous
article and examined some communications scenarios between virtual machines that are located within different
cloud services and different Azure Virtual Networks. In the next article in this series, we’ll finish up on the virtual
machine communication paths between Azure Virtual Network and cloud services and then go into some more
detailed coverage of name resolution in Azure Infrastructure Services. See you then! –Tom and Deb.

If you would like to be notified of when Debra and Tom Shinder release the next part in this article series please sign
up to our CloudComputingAdmin.com Real Time Article Update newsletter.