The primary ramification is that the security of your private SSL/TLS key is ultimately out of your control.
Technically, you could use a wildcard certificate, or a multiple domain certificate (Subject Alternative Name, or SAN, certificate).
However; if you use a wildcard or SAN certificate, then the security of all of your servers is tied to the security of that private key (which is ultimately out of your control).
If some of those protected servers are on your own private/office network (meaning you are using the same SSL/TLS key on both your Azure-hosted server[s] and your server[s] at your office), then the security of your office is tied to the security of that private key (which is ultimately out of your control).
Ultimately, that private key is out of your control once you hand it over to Azure. They may do a very good job of securing it in a general sense, but keep in mind that you'll also need to upload an unencrypted version of that private key to Azure (no password on the key file), or else you will have to type a password every time any of your servers restart, which is really untenable. No system is 100% immune from hackers or government information requests. So it is within the realm of possibility that an unprotected copy of your server's private key could end up in other hands, without you even knowing about it, which would expose your system to MIM (man in the middle) exploits, which isn't necessarily fair to your users if it happens.
On the bright side, as long as your Azure service is configured to support perfect forward secrecy, the exposure of your private key would not automatically expose HTTPS sessions that took place prior to the exposure of the key.