I usually try to not compare PaaS/IaaS providers directly, because they serve different audiences and all have their strengths and weaknesses. That said, Azure’s love of ceremonious ordeals and enigmatic rituals, coupled with poor UX and general lack of sensible design, are sometimes just infuriating. The frustration becomes especially intense when I remind myself just how easily some of these goals are accomplished in AWS (and, I assume, Google cloud as well to some degree - I don’t yet have sufficient expertise in it to draw informed conclusions).
Allow me to illustrate.
Today we have a (seemingly) simple task at hand. We’d like to offload TLS termination for our app to the cloud provider’s load balancer, and go about our lives. Will it work? Let’s find out!
This is how the two platforms stack up in helping you protect your HTTP services with TLS in this year 2018:
|You may request and issue up to 100 of SSL certs for free to use with AWS services, via the web console. You may then reference them with Terraform / boto / aws cli. Certs are signed by AWS’s CA.||There’s no free cert option. Azure have partnered with GoDaddy to bring encryption to the masses (at a notable discount of 0%), because clearly running a CA for their customers is just too fucking much to ask of the Redmond giant.|
|Such a cert is usable anywhere in AWS, including the application load balancers.||The cert that you can buy in Azure is only deployable on Azure app services, i.e. the Web Apps - the Azure PaaS product. The Compute suite of products, such as Load balancers of any kind, are not included. You do have the ability to export the cert for use with other services (after all, you paid for it). The process is complicated and requires PowerShell. If you’re on a Mac or Linux, sucks to be you (no it doesn’t). Also, as part of the process you have to create a Key Vault, for no good reason whatsoever.|
|The cert, once provisioned, is immediately available in EC2. Once again, console / Terraform /boto / aws cli / whatever else tickles your fancy.||So you either bought a cert from a registrar of your choice, or signed one on your own CA for private use. Either way, the cert, once provisioned, is just that - provisioned. Now you need to upload it to Azure. Yes, even if you bought it from Azure.|
|To use it with a load balancer, you get its id and pass it to your scripts. If automation ain’t your thing (it should be), you may pick the cert from a list when setting up a load balancer or another service.||You’d expect Azure to have something like Certificate Manager, yes? Well, you’re in luck - Key Vault to the rescue! Remember, you made one earlier? Yes, you do have to create an actual “key vault” resource via either Portal or CLI to store your certs. It’s not just a platform service offered by Azure. It’s an object you have to create and maintain, because you love micromanaging this shit. (Worry not, one vault can hold many keys - thanks,
|You’re done. In fact, you were done after the 2nd step. This was the entirety of setup required to terminate SSL on an AWS load balancer. Feel free to move on to more interesting work.||We still want to use the cert with a load balancer^H^H^H^H^H App Gateway, right? Guess what. That’s like the only fucking Azure service that CAN NOT get your cert from the goddamned Key Vault.|
|you’re done, remember?||Yes, you guessed correctly. You need to upload a cert to each App Gateway separately. Yes, we love manual work SO MUCH that will happily do this in Azure and thank them after, even though we pay them good money to have a platform that doesn’t suck balls.|
Do you think I’m doing it wrong on Azure? Please share your perspective.
P.S. I haven’t touched on end-to-end SSL here, just for the sake of wrapping up this rant or we’ll be here all night. Suffice to say, it’s super easy in AWS and a huge fucking pain in the ass in Azure. Are you surprised?
 Few conversations can get as confusing as those where you keep saying "load balancer", but really mean "app gateway".