As you might guess, there was a lot of interest in this topic as the session was filled to capacity. At a high-level, VMware on AWS architecture was reviewed along with how to use native AWS services with VMware Software-Defined Data Center (SDDC) workloads with the goal that those attending would walk away with practical guidance to help customers with their VMware on AWS journey.
The high-level architecture, shown below, is pretty straightforward and likely very common to many of you:
VMware manages all aspects of the VMware infrastructure running on AWS removing that administrative overhead from the customer. An Elastic Network Interface (ENI) enables the AWS hosted vSphere environment to use native AWS services and the on-prem vCenter server is connected to the hosted vCenter server using Hybrid linked-mode to provide a “single pane of glass” for management.
To support VMware on AWS, two accounts are required:
- VMware Cloud SDDC Account
- This is an AWS account to run SDDC resources that is owned and operated by VMware. The customer will have no access to this account
- AWS Account owned by the Customer
- This AWS account is owned by the customer that enables connectivity to VMware on AWS as well as native AWS services
The slide below focuses on the VMware side of the architecture, what’s truly remarkable is that for VMware on AWS VMware will manage all of those components outlined in orange. The customer will manage the VMs and VMware will manage everything else and still provide those VMware features we have all come to know and love: HA, DRS, vMotion, etc.
For this session, 3 primary use cases/drivers for VMware on AWS were discussed:
- Disaster Recovery
Increasingly, customers want to utilize the cloud to move away from dedicated DR datacenters in order to avoid the operational burden thus for existing VMware customers, VMware on AWS may make a lot of sense as the DR datacenter. In this instance, VMware Site Recovery Manager (SRM) is deployed to establish connectivity between the on-prem vCenter server and the AWS vCenter server. According to the presenter, this method provides simple recovery and failback. I hope that’s the case, but I’d like to see it.
- Database Migrations
Many customers are looking to on-prem databases to VMware for AWS, not necessarily because performance on-prem is poor, but to take advantage of the native AWS services like Redshift, Quicksight, Elastic Beanstalk, etc. Once the database is in VMware for AWS, the customer may find it beneficial to use the Database Migration Service to migrate their databases to Aurora to save on costs as they relate to Oracle or SQL.
- Secure Web Content
AWS provides so many beneficial services for web servers, such as load balancers, CloudFront, Web Application Firewall, and AWS Shield to name a few that help protect your site for DDoS attacks among others, thus customers are moving their web servers to VMware on AWS to take advantage of these features.
Though it wasn’t listed as a specific “use case”, it was stated that many customers are using VMware on AWS to integrate a cloud repository into an existing backup program. So with the on-prem and AWS VMware environments connected, you could create a Veeam or Commvault (the examples given during the session) in the VMware on AWS account thus allowing you to backup on-prem instances and restore them in the cloud environment if so desired.
It was stressed once again that VMware on AWS is not a “nested” virtualization solution, but that ESXi is installed “bare-metal” as one would do within their on-prem datacenter. Based on demos shown during this session, connecting VMware on-prem with the AWS infrastructure as well as the configuration of SRM is pretty easy and straightforward. If you’re looking for a way to facilitate a migration to the cloud while also taking advantage of your organizations extensive VMware expertise, give VMware on AWS a look.
