Further information and images found here: https://cloud.vmware.com/community/2017/08/28/vmware-cloud-aws-now-available/
History Lesson
Public Cloud
I’ve been working in public cloud now for years. I’ve followed as it grew from its humble beginnings, to the destination of choice for datacenter exits, to the application and data analytics powerhouse it has become.
Two to four years ago it was all about the “compelling event”. The datacenter exit, the hardware refresh, etc. It was all about where companies housed their servers.
For the last couple of years the public cloud vendors have been expanding and accelerating their cloud-native services. Everything has been fast becoming about the app and the development team or product owners. Everything has been moving away from servers towards PaaS, serverless, AI/ML, augmented reality, IoT and data analytics. Servers are old, monolithic, expensive, tech.
VMware
VMware was the first company to virtualise servers on an x86 hyper-visor. This was extremely significant as the majority of servers ran on x86 hardware, thus unlocking a huge market for VMware. Begin the server virtualisation revolution and VMware’s meteoric rise to hyper-visor supremacy.
In 2008 I attended a VMware summit in Manchester, England. At that event one of the speakers talked to us about what they do with their profits. 50% of profit was set aside and re-invested back in the business every year. This is one of the methods they employed to stay ahead of their competitors. AWS was a young, niche, fledgling service at the time.
By this time Microsoft had recognised the danger and had already produced their first true hyper-visor (Hyper-V), as had Citrix (Xenserver) and Redhat. It wasn’t until Windows Server 2012 R2 that Microsoft started to seriously eat into VMware’s market share, but by this time Microsoft had recognised the threat represented by a rising AWS and Google Cloud and had already launched Azure public cloud.
It could be argued that their supremacy blinded them to the rise of public cloud. But just as Microsoft took chunks out of their on-premesis hyper-visor market share they compounded it alongside AWS, GC, and Alibaba with public cloud dominance. Now there are a number of mainstream and niche public cloud vendors.
Over the subsequent years, VMware has faded fast and seemingly been unable to respond, until…
Old Kid on the Block
Enter stage left VMC on AWS. Much like Microsoft did a deal with Citrix for Citrix on Azure, AWS did a deal with VMware though with some remarkable thinking.
Now you can extend your VMware Software Defined Data Center (SDDC) into AWS. You are literally running your VMware workloads, on VMware in AWS!
When faced with public cloud one of the concerns and investments any infrastructure manager has is “what is the cost of retraining”. This is where I think VMware and AWS had a brilliant stroke of genius. Yes your VMware SDDC runs on an AWS VPC, but you don’t manage the AWS part, VMware do. This means that companies heavily invested in VMware but wanting to embrace public cloud have a half-way house. They can get to public cloud and start leveraging the economies of scale without having to retrain everyone.
Much like you don’t have to worry about hardware, patching or security of the hyper-visor on AWS, you don’t have to worry about figuring out the detailed architecture and maintenance of AWS to support VMware. VMware runs your AWS VPC environment so you don’t have to.
How Does it Work
You create a separate AWS VPC through the AWS portal. You create and manage your VMC subscription (AWS VPC) through the VMC Console. During creation you must specify a billing method which can be:
- Pay as you go (cancel at any time)
- 1 year commit (discounts)
- 3 year commit (further discounts)
You must connect your subscription to your AWS VPC (client account). This can be delayed two weeks if you choose to deploy a single host. AWS are not going to want you to deploy VMC without opening your own account with AWS.
The following illustration describes the high level architecture:

Connecting the Components
NSX-T
NSX is effectively network virtualisation (like ESX / ESXi are to server virtualisation) and is what allows VMware to create SDDCs abstracted from servers, switches and routers. NSX-T is the component that enables virtualisation on platforms other than VMware – in this case AWS.
Gateways
Management Gateways are exactly what they say on the tin. They are NSX firewalls that handle management traffic. E.G. vCenter. This is created when you first create the VMC and is mostly pre-configured bar access management and rules.
Compute Gateways are NSX firewalls that handle VM traffic. E.G. the customers accessing and using their apps located on servers in the VMC. Compute Gateways are created when the VMC is first created and when new network segments are created.
Network Design
A typical deployment is depicted in the following diagram:

Further info can be found here.
Capabilities
Use Cases
So why should I consider stretching VMware out into AWS instead of investing further in my private cloud? Here are the primary use cases:
- Hardware refresh – Anyone that manages physical tin understands the pain and expense of the hardware refresh. It’s significantly expensive to design, plan, execute, deliver, onboard, migrate, and obviously purchase. It’s also coming straight out of the CapEx budget which isn’t a budget that can handle surges in resource usage. Lastly, the engineering skills necessary to maintain tin are expensive.
- Data Centre evacuation – Your data centre contract is coming to an end, or maybe you manage your own and it’s become to expensive to maintain. The renewal will lock you in for maybe another 2-3 years and is extremely expensive. Maybe you’re dissatisfied with the service.
- Significant skills investment – You’ve been using and expanding your VMware environment for years. You’ve invested in the training and certifications and maybe bought in staff with the right skills. You’re operations team really understand your infrastructure deeply. You want to take advantage of public cloud but the expense of retraining or buying in skills is daunting.
- DR Site – You have data centres covering data centres, but a whole dedicated DR data centre is perhaps too big an expense.
Benefits
Here are the key benefits:
- Economies of scale – With public cloud and their buying power you can take advantage of their enormous economies of scale meaning the relative cost of hosting global apps, or provisioning in minutes, or dynamic elastication of resources is beyond your data centre reach.
- Global coverage – Public cloud vendors are global. Within a few minutes you can provision resources in multiple regions. So global availability is no longer out of reach or prohibitively expensive.
- Elasticity – Scaling up or scaling out can be achieved in minutes rather than hours, days, weeks or months. It can also be easily automated based on performance triggers.
- CDN – With a global content deliver network you can always ensure your consumers are served from their local regions resources.
- Accelerated Cloud Migration – So long as you have a Direct Connect in place from VMC back to your VMware data centre you can vMotion your servers removing much of the pain of a server migration to AWS.
Old World Meets New World
So here’s the rub… In my experience most companies that evacuate a data centre into public cloud don’t continue to invest in public cloud. Instead, after spending a considerable sum of money and effort on migrating servers to public cloud, they continue to operate their servers as they always have.
With this model you’ve got to public cloud and you’ve swapped one data centre for another. The bonus? The new data centre comes with incredible power to leverage. Yes you can take advantage of the economies of scale and easy elastication. However, now is the time to really accelerate your digital transformation and be competitive. You can speed up your batch jobs and reduce them down from hours or days to minutes, or you can reduce your web management overhead using elastic beanstalk, or simplify your order processing with Lambda.
The point is, while spending money to get to AWS you’ve saved time and money by extending your VMware estate into AWS and avoiding significant consultancy fees and retraining costs. Re-invest those savings into your digital transformation to modernise your apps and operations.