Why Clydesdale?
Clydesdale Software Logo

Follow Us: Twitter RSS

Go Back

PaaS Faceoff - Azure vs AWS

This post will cover the differences laid out as pros/cons between Azure and AWS as a PaaS, while touching just a bit on IaaS.


Why PaaS? Focus on software not virtual machines and networks. A PaaS should prescribe guidance on how to build for it, easily using all the building blocks available in the PaaS. For some this is not their cup of tea though I will take delivering in a fraction of the time, and start getting product feedback, any day over building the perceived perfect technical environment.


I will focus on web services and websites using IIS and the .NET framework. I will also briefly touch on some of the other pieces in a PaaS.



The main piece of Azure I will focus on is Cloud Services (aka Hosted Services). Microsoft has thought through the Cloud Services implementation as it provides guidance just by its existance.


  • Having the Azure Cloud Services being a separate project in Visual Studio that references the service project is really helpful as the service projects are not necessarily specific to Azure.
  • Separation of the service configuration and the application package is really key as it allows one package to be created and apply a configuration for different environments.
  • Configuration is at the deployment level and the Azure configuration manager makes it very easy to work with. The Azure configuration manager first checks the Azure configuration then checks the local configuration appSettings; very useful if a key/value is forgotten to be transferred to the Azure configuration if you are moving to Azure.
  • Production and Staging slots for Cloud Services is so nice to see. Many years ago I did this with symlinks so there could be quick action taken if a deployment went wrong and any priming that needed to be done could be done. For test environments I tend to use the staging environment as the url is something that people cannot guess.
  • Microsoft provides emulators for compute, table storage, queues and blob storage which is very handy when developing locally.
  • Azure In-Role Caching is so easy to use and provides a fast place to put session state if needed.
  • Really good developer experience.
  • .NET Api’s are clean and easy to use
  • Azure .NET SDK has transient fault handling built in for storage components (blob, queue, table) and for service bus the enterprise library transient fault handling block can be used.
  • EF 6 now has SQL Azure transient fault handling
  • Worker Roles for none web oriented processing (or open up a port and you can host in them if iis is not needed)
  • Per minute pricing!


  • Cannot have a non-public Cloud Service which is load balanced and autoscaled.


  • I would love to see a Cloud Service which could only have other Azure Cloud Services talk to it and was still load balanced, much the same way SQL Server does with a firewall rule. Yes there are virtual networks though you lose load balancing and honestly this is a bit overkill for the intended use. All I want is to not have the public world script kiddies be able to hit the service endpoint.
  • Bring the PaaS and IaaS together with something similar to AWS Cloud Formation.



The main pieces of AWS I will focus on in Elastic Beanstalk. Elastic Beanstalk is the closest component of AWS to comparison to Azure PaaS though using Cloud Formation you can assemble a template which is close.


  • SNS notification hooks
  • Can be used in conjunction with Cloud Formation. Yes this is a bit outside of a PaaS though IaaS and PaaS have a fairly large intersection in today’s enterprise.
  • Can create Elastic Beanstalk applications inside a virtual private cloud.


  • Configuration is part of the Web Deploy package which means you cannot have the scenario outlined above with Azure. Instead a package per environment would have to be created though some customization to the packing process would need to happen to get the correct configuration file. More can be found here - http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/customize-containers.html.
  • NOTE FOR ABOVE: Using Cloud Formation you can create different configurations for different environments though now this is outside the AWS PaaS solution to achieve something similar to what Azure can do out of the box.
  • NOTE NOTE FOR ABOVE: OpsWorks is another widget in AWS which can do much of what the above two approaches can do though a bit differently.  Honestly, this looks really cool though I do not see windows as an option and I would not call it a PaaS but really cool none the less.
  • No production and staging slots where a virtual ip could be flipped and provide a quick back out to a deployment gone wrong or to do any priming before putting into production.
  • Api’s could be cleaner. After moving a product from AWS to Azure I was impressed how much easier the Azure .NET Api’s were to use.
  • Pricing is per hour.


Pretty simple, do the stuff in the pros list of Azure.


Final Thoughts

Both Azure and AWS are great though I have found Azure to be more purposefully built. By purposely built I mean to solve a specific problem which is what a PaaS should do. AWS feels like a bucket of widgets, which is why AWS is considered more of an IaaS.


There is of course the intersection of PaaS and IaaS. A good PaaS is a much harder nut to crack, too loose it becomes nothing more than a template on top of an IaaS, not really solving a specific problem. To tight and it becomes inflexible and does not fit the bill for use with a majority of software. AWS does a better job of handling this intersection than Azure though there is room for improvement, both in the AWS PaaS and how it works with the IaaS. I’m excited to see where Azure decides to take it.


At the end of the day I prefer Azure for a PaaS as it streamlines and guides the process of delivering software better than AWS while still giving flexibility.

Facebook Twitter DZone It! Digg It! StumbleUpon Technorati Del.icio.us NewsVine Reddit Blinklist Add diigo bookmark