Building VMware on Public Cloud or using Cloud Native?

This is an interesting topic, looking into what VMware is building when it comes to public cloud offerings.
This blog post will look into the VMware offerings that the different public cloud vendors have in terms of IaaS based delivery

  • VMware on AWS – This is a service that is built together by VMware and AWS
  • Cloudsimple on Azure and Google Cloud – This is a service that is built by a VMware Partner called Cloudsimple (Which has then been aquired by Google Cloud)Now both these offerings are based upon the VMware SDDC stack, consisting of VSAN, NSX-T and ESXi.

Cloudsimple on Azure

The Cloudsimple solution is essentially a VMware Cloud Foundation deployment within either Google Cloud or Microsoft Azure. From an Azure perspective is it essentially setting up an Expressroute connection to Azure between the VMware Cloud Foundation.

Azure ExpressRoute Connection to virtual network

It is still interesting to see how the CloudSimple offering will mature since Google aquired the company last year. And looking into the integration that Azure VMware Solution by Cloudsimple has with Microsoft Azure, it is pretty limited.

The Cloudsimple solution in Azure runs on dedicated nodes (dedicated and isolated bare-metal hardware) as part of vCloud Foundation, and is consumed by users through native VMware tools that include vCenter and NSX Manager. Dedicated nodes are deployed in Azure locations and are managed by Azure. Here you can use either Pay-as-you-go nodes or Reserved, dedicated nodes. To create a VMware cluster in Azure there is minimum number of 3 nodes to create a cluster, but you can have up til 16 nodes.

Minimum number of nodes to create a private cloud 3
Maximum number of nodes in a cluster on a private cloud 16
Maximum number of nodes in a private cloud 64


One of the cool things that Cloudsimple has built as part of their resource provider, is an gateway between Azure ARM and the vSphere API’s which allows people to deploy ARM templates directly to Azure which in turn will provision virtual machines directly in vSphere.

Is it however important to understand that since the VMware Cloudsimple solution is a dedicated solution running inside Azure and that the integration is based upon an resource provider and networking based upon ExpressRoute, this means that many of the Azure Services will not work with CloudSimple, now services which operate at regular networking layer will work (This means load balancing, application gateway, azure netapp files for instance), but there is no built-in support for services such as

  • Azure Backup – Requires you to have another backup solution to handle the virtual machines on the platform
  • Azure Migrate – Should look at HCX Enterprise as an alternative (Azure Migrate does not work with VMware as a target)
  • Azure Monitor (all audit logs will be generated within the CloudSimple service portal)

So it is important to look at the CloudSimple solution is basically a Site-to-Site connected solution directly to Azure with some custom resource providers. You will still need to manage it as a regular VMware cluster and all parts that come with it, such as backup, monitoring and such.

Also you should remember that unlike virtual machines that you can setup in Azure using AS or Availabilty Zones, the Private Cloud solution is maintained within a single AZ and therefore cannot provide the same level of SLA like regular IaaS in Azure, the guaranteed SLA is 99.9 percent.

VMware on AWS

VMware Cloud on AWS uses NSX-T to create and manage internal SDDC networks, and is directly integrated with the Amazon VPC in contrast to VMware on Azure architecture.

So when we setup a SDDC in AWS, it will connect the ENI of the VPC owned by the AWS account you specify to the NSX Edge Appliance in the SDDC. That VPC becomes the Connected VPC, and the connection supports network traffic between SDDC VMs and AWS instances and native services in the Connected VPC.

Comparison between VMware on AWS compared Cloudsimple

So looking at the two offerings, they are quite similiar when it comes to pricing but again there are other cost components that come up such as networking, bandwidth and such. However from an integration perspective VMware on AWS is much more integrated and provides higher SLA and therefore easier to provide DR offerings across multiple availability zones.

Of course all these services can be integrated with traditional solutions for backup, monitoring and such which you might have been using for some time on existing on-premises.


So what is the use-case for these VMware on Public Cloud offering?
Essentially I see it for the main use-cases for VMware Public Cloud offering

  • Datacenter replace  – If we need to migrate our workload from our existing datacenter.
  • Extending capacity – If we need more IaaS based capacity to extend our existing Private Cloud solution
  • Landing zone for legacy workloads – We can either use native IaaS feature in Public Cloud, or if we have a certain set of workloads we can migrate these legacy applications to Public Cloud on VMware using HCX to a VMware based landing zone.
  • Disaster Recovery – (Instead of Public Cloud native DR is that using DR with VMware we can get dedicated hardware for use for DR)

It is important to understand that both vendors provide maintance and upgrades of the infrastructure based upon maintance windows.

Compared to Cloud Native IaaS

Now if we compare both these VMware offerings compared to the cloud native IaaS offerings. There are a couple of considerations

  • Cloud Native offerings can provide more different hardware options (GPU, RDMA, other specialised hardware)
  • Cloud Native offerings can provide more supporting tools (monitoring, automation, security tooling) which are more integrated compared to VMware
  • Cloud Native benefit from the cloud economic model where you pay per second for VM capacity unlike VMware where you still have the same economic model.
  • Cloud Native provides more richer automation directly as a native solution
  • It is also important to understand that do a migration from an on-premises enviroment (running VMware) to a public cloud native IaaS requires a lot of changes to networking configuration, agents (VMware agent tools) and such compared to migrating from VMware to VMware.


When it comes to public cloud workloads, it is important to understand that these VMware offerings cannot be directly integrated with the cloud native offerings. Let us look at an example Microsoft has an Azure Backup solution which works directly with Azure Native IaaS, so therefore for VMware solution in Azure we would need another tool to do provide backup for that workloads that is running there. So it is important to understand that these services that the cloud providers are building are always going to be directly integrated with the cloud native IaaS but not with VMware offering on top.


Leave a Reply

Scroll to Top