Here's a couple of ideas:
1. Linux support. If you look in Azure documentation they never say they support any Linux distro - they "endorse" a couple. Amazon provides their own for of Centos with all the conveniences like having the AWS CLI pre-installed. Incidentally Azure is the only cloud platform where I've had machines kernel panic randomly.
2. A consistent interface. The Azure portal has been under development for over 2 years now but you still need to use the "classic" interface for some settings.
3. Database support. Other then MS SQL Server. MySQL is supposed to be in beta. It's been in AWS since 2009. Also Amazon is developing AuroraDB which is, supposedly, optimised to work in AWS.
4. Availability zones. Again in preview in Azure but have been in AWS since 2008. What's also interesting is, up until now MS marketed "Availabilty sets" as the Azure version of AZ. One is a guarantee that a box will be spun up on a different rack within the same datacenter, the other guarantees the box in a separate DC.
5. A consistent API. And I don't mean the definitions being immutable - that's actually handled with schema versioning. I mean getting the correct responses. Although unchanging API would be nice as well.
Here's an example: https://drive.google.com/open?id=0Bz59vPCFY-fham1qN1E1MnZBcl... (3mb video).
What basically happened was, I would deploy my environment, run Ansible against it and get errors/unconfigured nodes.
So what happens in the video is: I run 'for i in 1 2 3; do azure vm list; done' and get three different responses: a list of VMs, an error message saying I have insufficient access rights to list the VMs and an empty list. All are incorrect. The first one is the closest to the truth but it's still missing one box. I get eventual consistency is a thing, but this was >30min after the boxes had been provisioned.
So to answer your question as to what is needed for Azure to become a viable alternative to AWS: I would say about 10 years.