The Not So Black Box: Azure Cloud Service

You’ve probably been virtualizing things on-premise for a while now and it’s pretty straightforward.  You spin up a VM, connect it to a network much like a physical machine, configure it as you need it and go on your way.  Depending on it’s role you might configure  your perimeter firewall so that it has some ports open on an Internet routable IP address.

And that pretty much sums it up. In Azure, a lot of that is same.  Except for the whole “Cloud Service” thing. A Cloud Service is a key part of the Azure fabric and if you’ve been working with PaaS for a while, it’s likely very familiar.  But if you are coming from the data center, it’s a new idea. Or at least, it was for me.

If you’ve taken one of the free Azure IT Camps or gotten a similar presentation on Azure IaaS you’ve likely seen this graphic:


What this shows is that a cloud service is a container that holds your VM.  This container is the “steward” of several key components that make your server room in the cloud work. A cloud service holds an external IP address and unique DNS name, is tied to a physical location in the Azure global fabric and acts as a firewall boundary.

You can create a cloud service first and add a VM to it, or you can create a VM and a matching cloud service will be made for it.  I prefer making the cloud service first (and I’ll explain why) but first, let’s break those things down:

• Physical Location – When you create a cloud service, it's tied to one of Microsoft’s eight worldwide data centers.  They are grouped in pairs (US – West Coast, US – East Coast, Europe and Asia).  At minimum, you must select the region your cloud service lives in.
• DNS Name – Each cloud service has an external DNS name in the cloudapp.net name space. By default, creating a VM will automatically create a cloud service with a matching external DNS name, if the DNS name is available.  (If not, you’ll be prompted to name it differently.) The DNS name does not have to be the same as the server name.

Up to 50 VMs can live inside a single cloud service, so if you are using a cloud service to host some servers for a website, you might want your external DNS name to be something meaningful for the service those servers provide.


For example, only one cloud service is needed for “mywebsite.cloudapp.net", but inside it contains four servers that are all available to service requests to the same site.

• External IP Address – Once your cloud service is populated with at least one running VM, it will be assigned an external IP address.  This address has a lifetime lease, however I recommend using the DNS name as the best way to reference the service from other systems.
• Firewall Boundary – The cloud service is used as the boundary where all the input endpoints are opened so you can access the VMs within it using the protocols of your choosing.  By default, RDP and Powershell is open for Windows operating systems, but this is all configurable by either using the Azure portal or via Powershell. Depending on what service you’ll be providing, you’ll need to open other ports.

Now, why do I like making an empty cloud service first?

Because it allows me to create the *.cloudapp.net DNS name separate from the machine creation process and think about how I want my VMs and applications to be grouped and accessible BEFORE I get started spinning up machines. Whenever I’m creating a cloud service in conjunction with VM creation, I nearly always end up with a DNS name I don’t like. 

Creating VMs in Azure is an almost trivial task, but the placement of them isn’t, so taking the time to understand cloud services, endpoints and other factors before getting down the business of creating VMs is something I consider a personal best practice. 

Azure doesn’t allow for name and location changes once a cloud service or VM is created, so correcting that requires deleted your work and starting over.  I’m crossing my fingers that some basic edits are built into Azure in the future, but for the moment, I like to “plan twice, create once!”