I've been using Microsoft Azure for around eight months now and have passed both the 70-533 and 70-534 exams. In that time I've had a chance to figure out some of the 'peculiarities' shall we say, compared to Amazon Web Services which I have used for the past three years.
First of all, there are two portals. portal.azure.com, which is called the "Azure Portal" and manage.windowsazure.com which is known as the "Azure Management Console". Recently Microsoft announced the availability of all services in the Azure Portal, featuring deep links to the previous console. This makes management of Azure resources a pain as the previous portal does not feature RBAC (Role Based Account Control) which means co-administrators of the 'subscription' (a way to manage your resources and spend) have full access to the whole subscription and can do anything they want, rather than a more granular approach to permissions as seen in AWS' IAM (Identity and Access Management) service. Some Azure services do not support the new portal (as of 12/01/2016) such as Service Bus which means third parties must have full administrative access to your Azure account which you won't want.
There are two ways of managing resources in Microsoft Azure. Azure Resource Manager (ARM) and Azure Service Management (ASM). The former is more aligned with the RBAC experience of the Azure Portal while the latter is related to the older Management Console, or 'Classic' deployment model. Microsoft need to make the Portal the only place to manage all resources (including Classic resources), but I'm not sure if or when that will arrive.
Another example of a peculiarity is restoring a VM backup. It is impossible to remove an OS disk, for example to roll back an OS drive to a previous version. The VM must be deleted and a new one created in its place, which won't have the same private IP. Frankly this is a crazy design choice as you can happily make this change in Hyper-V, which Azure runs on. You have to either get creative with scripts, or use Azure Backup (and that deserves its own blog post entirely!)
A golden rule I kept telling myself throughout my Azure training was: "Azure is not AWS". Although I have been comparing the two during this post, the best way to learn it is to apply the usual Cloud concepts: scaling out not up, designing and preparing for failure but at the same time treating Azure as a completely new concept. For example, Azure does not have the idea of AWS' Availability Zones, instead you have Availability Sets. This is a way of separating VMs within a single datacenter and ensuring they do not reside on the same physical host, network segment or power supply, thus ensuring your machine will not be taken down during physical host maintenance or an outage (in theory). Availability Zones in AWS are at the datacenter level, so you can deploy instances to multiple physical locations connected by low latency interconnects and have high availability that way. Neither is the right way, they are just different ways of looking at the same problem. Azure does not have a VPC, it refers to a VNet which works differently - NAT is built in and there is no 'private' subnet by default, any VM can access the internet even if it does not have an external IP. These subtle changes can trip you up if you constantly compare it to AWS.
In summary, Azure is a capable platform which many companies are using with no problems. However, it's not as polished as AWS and has many annoying peculiarities as discussed in this post. I still recommend Azure, but you have to keep these differences in mind and weigh up the advantages and disadvantages of either Cloud Platform before deciding which one to use or even a combination of both!
I'd love any feedback on this article, thanks for reading.