I recently had some cases where I lost the public IP address which was assigned to a cloud service within Windows Azure. This was not really a desired scenario because these IP addresses were already used and registered in DNS. The use of a CNAME to *.cloudapp.net was not an option because the use of certificates.
The reason why I lost the public IP address on these services was because of the state of the Virtual Machines within the services. Because of the changes of the billing mechanism in Windows Azure (June, 2013), there was a new status introduced for the Virtual Machines. The new status: Stopped (Deallocated) places the VM in a special state which means that the configuration of the VM is not actively being associated with fabric resources. This results in the fact that you are not being billed for the hourly compute time while the VM is in that state. This is of course a very useful feature, however when all of your VM’s in a Cloud Service are put in this state, the public IP address associated with that service will be released. The next time you start a VM in the Cloud Service it will have a new public IP address assigned. How can we prevent this? Just be aware about the way you shutdown your VM’s in a Cloud Service and/or assure that there’s at least one VM running all the time. There are three ways to shutdown/stop a VM within Azure:
- Shutdown VM via Windows Azure Management Portal
When using the Shutdown button within the Azure portal by selecting the VM, it puts the VM in the Stopped (Deallocated) state.
- Shutdown Guest Operating System inside the VM
Using shutdown (via RDP) from within the VM causes it to go into Stopped state.
- Stop VM via Windows PowerShell using Windows Azure PowerShell Module
In the latest version of the Windows Azure PowerShell Module there’s a new StayProvisioned parameter added to the Stop-AzureVM cmdlet. With this parameter you can determine the state that the VM goes in when shutting it down:
– Stop-AzureVM -ServiceName “myservice1” -Name “MyVM”
This causes the VM to go in the Stopped state.
– Stop-AzureVM -ServiceName “myservice1” -Name “MyVM” –StayProvisioned
This causes the VM to go in the Stopped (Deallacated) state.
Summary: just put your VM’s in a Cloud in the correct state (stopped) and/or keep at least one VM running. This way you don’t lose your public IP address.
For more information: http://msdn.microsoft.com/en-us/library/windowsazure/dn133803.aspx
Michel van Vliet - IT Blog 
— The use of a CNAME to *.cloudapp.net was not an option because the use of certificates.
You should still be able to use a certificate with a CNAME since the certificate is associated with a DNS name not an IP address. Indeed, this was the standard way to do things with Windows Azure PaaS cloud services before Microsoft announced that IP addresses would not change unless there was a complete undeployment.
If you want to preserve the IP you can park an extra-small VM in the cloud service, since they are relatively cheap.
@Neil: thanks for your reply.
Let me explain what I meant with my statement “the use of a CNAME…..was not an option”. When, for example, a certificate is configured for “sts.contoso.com” and using a CNAME pointing it to “stscloudsrv.cloudapp.net”, there will be a certificate warning/error.
You wrote: “Indeed, this was the standard way to do things with Windows Azure PaaS cloud services before Microsoft announced that IP addresses would not change unless there was a complete undeployment”. Do you have information that Microsoft is planning change this behavior? For now the situation is as described in my post. See for more info: http://msdn.microsoft.com/en-us/library/windowsazure/dn133803.aspx
The following is documented with respect to using SSL certificates and Windows Azure PaaS cloud services:
— The certificate’s subject name must match the domain used to access the cloud service. You cannot obtain an SSL certificate from a certificate authority (CA) for the cloudapp.net domain. You must acquire a custom domain name to use when access your service. When you request a certificate from a CA the certificate’s subject name must match the custom domain name used to access your application. For example, if your custom domain name is contoso.com you would request a certificate from your CA for *.contoso.com or http://www.contoso.com.
As far as I know there is no difference with respect to IaaS cloud services.