“VMware Cloud on AWS” Vs. “Azure Stack”


VMware, Amazon Web Services and Microsoft are in the middle of some interesting technology and services roll out that have the potential of moving the needle in cloud adoption (spoiler alert: whatever cloud means). VMware is coming from a very strong (almost exclusive) marketshare in the on-prem data center virtualization space. AWS is the 800-pounds cloud gorilla and Microsoft is one of the biggest contenders in the same public cloud space.

VMware just made available “VMC on AWS” (aka VMWonAWS, aka the possibility to run the entire VMware SDDC stack on the AWS infrastructure).

Microsoft is making available “Azure Stack” (aka an on-prem instantiation of the services available on the Azure public cloud).

These two announcements will generate (and are already generating) lots of interest in the respective communities. In this post, I would like to make a comparison between the different approaches VMware, AWS and Microsoft are taking when it comes to hybridity (again, whatever hybridity means).


The cloud industry has been poised in the last 10+ years by the fact that, when AWS pioneered it, it changed two very different paradigms at the very same time:

  • it changed the economic paradigm with a PAYGO/OPEX model (Vs. the traditional on-prem/CAPEX model).
  • it also shifted the application architectural paradigm with a cloud-native/Cattle application model (Vs. the traditional enterprise/Pet application model).

I won’t bore you more with this because I have already ranted about it a couple of years ago in my “What do Cloud Native Applications have to do with Cloud?” blog post. It would be beneficial to scan through it if the topic is of your interest.

The picture below is intended to summarize visually this multi-dimensional aspect I have alluded to in the blog post linked above:

As you can see, AWS introduced both a new economic and delivery model (X axis) as well as a new application architectural paradigm (Y axis).

In the last few years the industry has witnessed a number of attempts to bridge these two worlds and dimensions. “VMC on AWS” and “Azure Stack” are two such examples of that (albeit the respective approaches couldn’t be more different).

Let’s explore them.


When VMware and AWS teamed up, it’s clear that they focused on tackling the economic and delivery model of the traditional Enterprise data center stack dimension (X axis).

The idea is to keep the VMware software stack “constant” (and hence compatible and consistent with what the majority of the Enterprise customers are running on-prem) and make it available “as-a-Service” on the AWS infrastructure. That is to say you can consume one (or more) instances of vSphere/vSAN/NSX clusters as a service, on-demand, in the public cloud.

This picture should visually convey this concept:

In other words, the strategy here is as simple as “bringing the existing data center stack into a cloud with a cloud delivery model”.  AWS gets an additional workload capability (a huge one with an enormous total addressable market) while VMware (and its customers) get access to a different “infrastructure economic and delivery model” option.

Azure Stack

When Microsoft looked at the hybridity challenge they took a completely different approach. Instead of focusing on the economic and delivery model aspect of “the cloud”, they rather looked at it from the application architecture and the stack required to run pure cloud-native applications (Y axis).

The idea here is to keep the on-prem delivery model (somewhat) “constant” and focus on making available (in your own data center) services and technologies that usually are only available in “the cloud” (that is, the public cloud).

This picture should, ideally, convey this approach:

Note how the traditional on-prem “data center virtualization” stack from Microsoft HAVE to give way to the new “Azure Stack” stack (no pun intended). Azure Stack isn’t meant to run on a traditional data center stack nor is it meant to run traditional “pets” workloads.

In other words, the strategy here is about “bringing the cloud services required to build and run cloud-native applications into an on-prem data center”.


In conclusions, discussing and comparing “VMC on AWS” and “Azure Stack” doesn’t even make much sense given they are meant to solve completely different problems in the hybridity space. Because of this, they both have complementary holes in their respective value proposition.

“VMC on AWS” shines if you are a happy vSphere customer, you have to support “pet workloads” but you would like to do so with a different economic and delivery model (i.e. if you want to get out of the business of managing VMware clusters, if you want zero-effort global reach, if you want a “pay-per-use” infrastructure opex billing… all without touching your application stack). On the other hand, this solution doesn’t address how to run cloud-native applications on-prem (at least in a way that is compatible with the AWS services – VMware and Pivotal have their own solutions for that but this is out of scope for this blog).

“Azure Stack” shines if you are re-architecting your applications using the 12-factor application methodology (“cattle workloads”) but, for various reasons, you want to run them on-prem in your data center (i.e. you want to leverage advanced cloud services such as Azure Functions, Object Storage, CosmoDB… all without having to move your applications to the public cloud). On the other hand, this solution doesn’t address how to run traditional applications (“pets”) with a cloud(-ish) economic and delivery model.

If you have clear what your challenges are and what you need for your own organization, you have already picked the right solution for you without any further comparison.

In the end, both solutions remain spectacular projects and I am sure they will be successful in their own respective domains. There are gigantic engineering efforts that most people do not even appreciate to make these things happen.

Super kudos to the teams at AWS, Microsoft and VMware for the astonishing work.

Interesting times ahead!



11 comments to “VMware Cloud on AWS” Vs. “Azure Stack”

  • NT

    Good overview of these different offerings but I don’t think its true they are completely different. Once a customer has moved to VMC on AWS I believe they can access all the AWS services like S3, Lambda etc so VMC is also about adding new Cloud Services just like Azure Stack is about adding new cloud services on-prem.

    I think a customer just has to decide if they want to go AWS or Azure with their new cloud services.
    Personally i find the AWS offering more compelling but if customers want to stick with their existing VMWare investments with their own hardware they may find azure stack more compelling.

  • Tushar Karande

    Days of VM infrastructure are gone now its an opportunity to architect solutions around application containers like dockers .How about replacing Hyper-visors on x-axis with Application containers!? . IT managers are more concerned about workload management than virtual infrastructure management

    • Massimo

      Thanks Tushar. I think what you are saying is (academically) correct but (practically) dis-joined from reality (for now). To move an elephant it takes more than a will (or a wind blow).

  • Maxwell

    I do see a use case for doing this but it just looks like an extension of the legacy virtualization model. To Tushar’s point, containers do seem like a better way of getting apps to the cloud and providing a layer of abstraction. On top of that, with containers and Kubernetes (products like Red Hat OpenShift) allow for companies to containerize stateful apps without refactoring them to be 12-factor.

    • Massimo

      I am not in denial of advancement in technologies, new patterns and methodologies. Your approach is fine and dandy for a startup or small org with a handful of applications but big Enterprise customers that have hundreds of hosts and many thousands VMs (running in critical production) have an incredible inertia (assuming they will all want or need to move to containers). Look at this from another perspective: the native AWS service could support what you are suggesting (and actually they have many more options than those you listed). Yet Amazon opted to partner with VMware to bring this to market.

  • Carlos Cavalleiro

    We can see that each company have different strategy for the market, but using what they have better, AWS bring on-premises data center for its cloud, were its have a great know-how, and MS bring a software solution for the user, as it does since the beginning.

  • Lovely diagram, but somewhat loaded. I can place an addition slice above the virtualisation layer and beneath the PaaS layer – a combination of an orchestration engine (which gives me automated deployment, update and retraction) combined with a container runtime. Put these two things together and I drive down VM costs and overheads. Factor in Kubernetes container orchestration and you arrive at a disruptive moment, where the virtualisation players and the PaaS players are facing a game changing reality. Tushar Karande’s assertion is correct.

  • […] VMware Integrated OpenStack 4.0 this past Tuesday. Also trending is an interesting article on “VMware Cloud on AWS” Vs. “Azure Stack” by Massimo. Thanks to William Lam for posting the Top 20 VMworld Sessions by Views: […]

  • Stuart Hardman

    I think the idea that organizations will just jump over to containers and go all in on that operating model is easy proved wrong by the fact that so many organization despite the 13 years of capability in virtualization still have physical boxes in their data centers. I have even visited an all physical customer recently!!

    People will still be talking about staring to use containers or expanding the use of containers in 13 years time.. This model Massimo describe at least offer organization a step forward and opportunity to leverage maximum ROI from their current investments with out being like Cortez and having to burned his ships on arrival in the new world.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>