Demystifying Azure Cloud Services: Azure Cloud Services and Azure Virtual Networks – Part 4

  • Article

I have noticed that there is a general sense of mystery around Azure Cloud Service. Some equate it to Cloud Services in general while others get confused with the relation of Azure Cloud Service and Virtual Machines while some one else gets confused about using Azure Web Apps (formerly Websites) with webjobs over Azure Cloud Service. If you have been in a similar dilemma as I have been in the past, I will try and clarify the confusion and get you started on Azure Cloud Service through this tutorial series.

Demystifying Azure Cloud Services – Part 1

Demystifying Azure Cloud Services: Cloud Service or WebApp? – Part 2

Demystifying Azure Cloud Service: Cloud Services and Virtual Machines – Part 3

Azure Cloud Service is actually good place to understand how the roles of a developer and an IT Pro merge. Think of deploying a cloud service to host a webapp or think of virtual machines being hosted in these cloud services. The general idea is that the cloud service acts as a container. Hence the infrastructure guy no longer has to get involved for a developer to host his/her applications. This essentially calls for additional knowledge for the developer to understand how to host his/her applications whether it is on cloud services or virtual machines, hence the merging of both the roles of a dev and an IT Pro.

Protecting the end points that is exposed to the public internet is of key importance and Azure Virtual Networks provides the mechanism to do that. Hence the virtual network adds the additional layer of security to ensure that entities (vms or cloud services) outside the virtual network are not able to connect or search for the entities inside the network unless it is allowed to do so programmatically. Also to extend the concept, virtual networks ensure that the traffic within the virtual network remains within the network but still allows to configure public end points for the entities that need to communicate with the public internet. All this boils down to improving security and traffic performance.

VNETS and Cloud Services in action

Consider the following scenario:

1 virtual network: VNET1

2 Cloud Services: CS1, CS2 – both in VNET1

3 Virtual Machines: VM1, VM2 contained in CS1, VM1 contained in CS2 – note that there are 2 VMs with the same name but contained in different cloud services but everything is in the same VNET1.

Based on the above description of how VNETs work with Cloud Services, note the following:

  • All VMs can communicate with each other directly since all of them are on the same network and need not loop back from the public internet – yes, this is a lot faster
  • Although it may seem that there are 2 virtual machines in a single network with the same name but this is not true, as the fully qualified domain names for each of the virtual machines are VM1.CS1.cloudapp.net and VM1.CS2.cloudapp.net
  • The Cloud Service essentially acts like a load balancer and is assigned the DNS name
  • For VMs within the same cloud service, (since they have the same IP address- that of the cloud service) port redirection is used to accomplish the routing of this traffic. Again this is the example for using the software load balancer of the cloud service

From a conceptual perspective, each VM is associated with at least 2 IPs: a public facing virtual IP (called VIP) and an internal dynamic IP (called DIP). The VIP is not assigned to the VM but is assigned to the Cloud Service. We don't have control over this VIP unless you reserve it from before hand. The DIP is dynamically assigned to the VM with almost an infinite lease period and is used to communicate within the virtual network or cloud service.

The way you get control over the range of IP addresses for your VM, is by assigning the VM to a virtual network with defined subnets or address ranges. One of the most important things to keep in mind is that you have to create a virtual network before you create the cloud service as you cannot migrate a cloud service to a new network that you create, hence you can only define the virtual network during cloud service creation time.

If the above scenario is modified by adding an additional VNET2 and configuring cloud service CS2 to belong to VNET2, then the communication with the VMs across the virtual networks (VNET1 & VNET2) will go through the public internet. Infact VNET to VNET configuration is an important scenario these days and more details can be found here. Keep in mind that a cloud service cannot span across virtual networks,.

Summary

Just to clarify the picture if you are still not entirely certain how it works:

  • Azure Virtual Machines reside in containers called Azure Cloud Services which can be contained in Azure Virtual Networks
  • Communication within the virtual network remains private and does not loop back from the public internet
  • The Virtual IP address is assigned to the Cloud Service through which communication happens across the public network. Dynamic IP is the internal IP that is assigned to the VM and is used within the network to communicate with each other

The intent of this post was not to deep dive into Virtual networks or Cloud service but rather clarify the relationship between virtual networks, virtual machines and cloud services. If you have any further questions around these, please reach out to me @AdarshaDatta.