VMware Cloud on AWS runs a managed vSphere enviroment on AWS’s bare-metal Infrastructure
Few months ago AWS give access to its bare-metal infrastructure so VMware created SDDC, that’s a VMware solution using AWS Infrastructure to offer this service. Bare metal I3 instances have been in production since August of 2017, powering the VMware Cloud on AWS service that launched after 18 months of joint development and testing effort between VMware and AWS. Today in september 2018 the solution engineered between VMware and Amazon is unique and it’s not the same as launching a nested ESXi in Microsoft Azure. In the near future I am sure there will be the possibility to have the same solution on Azure, that’s because as you can read on some posts and public statements VMware has always been Any Cloud, Any App, Any device agenda.
On September 25th 2018 Massimo Re Ferrè Principal Solutions Architect @ AWS (former VMware) made a 1 hour Webinar about this topic. In this article I will try to explain using all the resource I came across about this topic as blog posts, webinar, youtube video and vmware hands on labs in order to have a clear concept about what it is VMware Cloud on AWS. Thanks to the VMware hands on labs I will create a CLOUDNATIVES.IT SDDC presenting all the steps necessary.
So if you are interested in this topic let’s begin.
VMWARE CLOUD ON AWS
We now cover a high-level overview of the VMware Cloud on AWS service and its architecture. Note that this solution is running bare metal on AWS infrastructure, this in September 2018 as I said it is not possible with their major Amazon AWS competitor as Microsoft Azure and Google GCP. Most of the slides are from Vmware and Amazon.
VMware Cloud on AWS™ can provide data center capacity without the need to build a physical presence in different geographic zones.
VMware Cloud on AWS is newly available in the AWS Europe (Frankfurt) Region, in addition to AWS Europe (London), AWS US East (N. Virginia) and AWS US West (Oregon) Regions. VMware Cloud on AWS is GDPR ready and have many industry certifications.
VMware has also introduced rich capabilities that allow customers to enhance enterprise readiness, accelerate cloud migration and simplify hybrid cloud deployments. Extend on-premises data centers to the cloud with a consistent operational model, retaining your familiar VMware tools, policies, and management as well as investments in third-party tools. Leverage AWS services to extend the value of enterprise applications over their life-cycle.
Powerful Use Cases
- Cloud Migrations – Rapidly and easily migrate vSphere-based workloads to the cloud with VMware Cloud on AWS. Reduce the risk and cost of cloud migrations compared to alternatives that require conversions or re-architecture (refactoring). Leverage familiar VMware tools and skill sets to accelerate cloud migrations. Once in the cloud, leverage VMware and AWS services to modernize your applications at your pace.
- Application Migration – Extend on-premises data centers and easily migrate targeted application workloads to VMware Cloud on AWS without conversions. Obtain bi-directional workload portability between on-premises and VMware Cloud on AWS. Modernize your applications through optimized access to native AWS services.
- Footprint Expansion – Easily extend your footprint into the cloud and get VMware-consistent, enterprise-grade environments in the AWS cloud in a fast and cost-effective way with VMware Cloud on AWS.
- On-demand Capacity – Get VMware SDDC capacity in the AWS Cloud in minutes whenever your business needs to meet temporary, seasonal, or unplanned demand. Take advantage of elastic capacity and usage-based economics of VMware Cloud on AWS by seamlessly moving your live applications into an environment that is operationally consistent with your VMware data center.
- New Application Development and Test – Deliver VMware SDDC-consistent dev/test environments that can integrate with modern CI/CD automation tools. Access native AWS services seamlessly for new app development.
- Disaster Recovery as a Service with VMware Site Recovery – Easily deliver business continuity with VMware Site Recovery: on-demand disaster recovery as a service, optimized for VMware Cloud on AWS. Accelerate time-to-protection, simplify disaster recovery operations, and reduce secondary site costs with cloud economics, while providing a secondary site that is operationally consistent with your VMware data center.
This jointly engineered solution between VMware and Amazon Web Services provides global scale and allows customers to leverage their existing skills and tools while maintaining compatibility with their existing applications with no re-platforming required. Through the power of NSX customers can architect networking and security to suit the needs of their applications. VMware Cloud on AWS™ is a software defined enterprise solution that enables customers to keep up consistent SLA’s across private, public and hybrid cloud infrastructures.
VMware Cloud on AWS is powered by VMware Cloud Foundation, a unified Software Defined Datacenter (SDDC) platform that integrates VMware vSphere, VMware Virtual SAN and VMware NSX virtualization technologies. VMware Cloud on AWS will give access to the broad range of native AWS services, together with the functionality, elasticity, and security customers have come to expect from the AWS Cloud.
- All-Flash vSAN acts as the storage platform and consumes host-local NVMe flash devices.
- NSX is used for all network functionality and it connects the ESXi hosts to the AWS network and exposes logical networks for virtual machine networking.
An in-cloud SDDC can be used on its own, but most customers have a hybrid cloud strategy. With vCenter Hybrid Linked Mode (a new feature for VMware Cloud on AWS), customers can connect the two vCenters to create a single pane of glass for hybrid cloud management.
Most customers run a vRealize product on-premises such as vRealize Operations, or vRealize Automation. The in-cloud vCenter is just another end-point so customers can continue using their existing on-premises vRealize products. This way, customers can manage both their on-premises SDDC and the VMware Cloud on AWS SDDC in a single pane of glass for operations and provisioning.
VMware Cloud on AWS provides access to a broad range of native AWS services. This helps with data gravity because customers are now able to place the application closer to the AWS services acting as a data source. Instead of network traffic flow from the DC firewalls to AWS and viceversa, they are now connected to the same network as the underlying AWS services. This enables you to build and operate new application architectures with minimal latency, network overhead and reduced AWS network outbound costs.
Flexible Consumption Models
VMware Cloud on AWS leverages cloud economics aligned for capacity and demand with one point of contact:
- Single bill for VMware software + AWS infrastructure
- Consume elastically scalable SDDC clusters
- On-demand or reserved instance model
- Leverage global AWS footprint
Billing is by VMware and it is about esxi used per hours, but if you plan to use that hardware for 3 years for example you can have a discount using a reservation.
- Jointly engineered, VMware Cloud on AWS provides customers a one-stop shop for native AWS services from within their SDDC
- All components of the solution are delivered, operated and supported by VMware Global Support Services (GSS)
- VMware fully certifies and supports all software components of the service
- VMware removes the burden of managing software patches, updates or upgrades for users. When operating as a cloud service VMware takes the responsibility of ensuring the service is always up to date
You will have a single inventory pane between on-premises and VMware Cloud on AWS using vCenter Hybrid Linked Mode. Enhanced single logical view and hybrid management of resources by extending Hybrid Linked Mode to connect a VMware Cloud on AWS environment with multiple linked on-premises vCenter Server instances (external PSC topology). Failed hosts in a VMware SDDC are automatically detected by VMware and replaced with healthy hosts.
Stretched Clusters for VMware Cloud on AWS
Zero RPO high availability for enterprise applications virtualized on vSphere across AWS Availability Zones (AZ), leveraging multi-AZ stretched clustering. Stretched clusters enable developers to focus on core application requirements and capabilities, instead of infrastructure availability.
– Significantly improve your application’s availability without needing to architect it into your application – the VMware Cloud on AWS infrastructure delivers protection against failures of AWS AZs at an infrastructure level.
– Stretching an SDDC cluster across two AWS AZs within a region means if an AZ goes down, it is simply treated as a vSphere HA event and the virtual machine is restarted in the other AZ.
The Stretched Clusters feature requires an AWS VPC with two subnets, one subnet per availability zone. The subnets determine an ESXi host placement between the two availability zones. As an SDDC is deploying, it provisions three hosts in each AWS availability zone and creates a vSAN stretch cluster across the two availability zones. The vSAN stretched cluster allows synchronous writes across the two availability zones. A vSAN witness node appliance, which looks like an ESXi host, will automatically be provisioned. It resides outside the SDDC cluster and in a third AWS availability zone. The vSAN witness node appliance is required in case network communication is lost, assisting to avoid split brain for virtual machines across AWS availability zones. Logical networks are also extended using NSX to support workload mobility across the two AWS availability zones.
After that, the workload in the Cloud SDDC is protected for AZ outages. If something happens, HA detects the failed VMs and restarts them on different physical servers in the remaining AZ without manual human involvement.
The ability to stretch your vSphere cluster across AZs allows you to easily provide resiliency to your workload within the AWS infrastructure without the Herculean effort of refactoring all your applications.
VMware Hybrid Cloud Extension
- Enables large-scale, flexible, bi-directional workload portability between on-premises and VMware Cloud on AWS with VMware Hybrid Cloud Extension.
- Migrations can be done live and in bulk (warm and cold) between various vSphere versions on-premises and VMware Cloud on AWS.
- Enables multisite interconnect between various vSphere versions on-premises and VMware Cloud on AWS.
- Create high-performance, secure, WAN-optimized interconnects that stretches networks, without having to change IP addresses.
- Includes policy-based traffic engineering, intelligent routing and automated VPN set up.
- VMware Hybrid Cloud Extension (HCX) is a SaaS service that provides application migration and infrastructure hybridity without application downtime or infrastructure retrofit.
- The VMware HCX service offers bi-directional application landscape mobility and datacenter extension capabilities between any vSphere version.
- HCX includes patent-pending capabilities to support VMware vSphere vMotion, Bulk Migration, High Throughput Network Extension, WAN optimization, traffic engineering, automated VPN with Strong Encryption (Suite B) and secured datacenter interconnectivity with built-in vSphere protocol proxies.
- VMware HCX enables cloud on-boarding without retrofitting source infrastructure supporting migration from vSphere 5.0+ to VMware Cloud on AWS without introducing application risk and complex migration assessments.
VMware Site Recovery
The service protects workloads between on-premises datacenters and VMware Cloud on AWS, as well as between different instances of VMware Cloud on AWS.
Horizon 7 on VMware Cloud on AWS
- Flexible deployment – Horizon 7 can be deployed either on-premises, on VMware Cloud on AWS, or both
- Build your hybrid cloud by straddling Horizon 7 CPA (Cloud Pod Architecture) across on-premises and VMware Cloud on AWS
- As easy as deploying one of the pods on AWS for federated management
- Same admin management experience on-premises and in the cloud
- CPA pods can also be deployed in multiple AWS locations
- Simplified vSphere deployment with the flexibility and elasticity with VMware Cloud on AWS, and option of hourly billing
Introduction to Deploying a SDDC Through The User Interface
Deploying a Software Defined Data Center (SDDC) is the first step in making use of the VMware Cloud on AWS service.
After logging in VMware Cloud Services select the service VMware Cloud on AWS.
1. Click the Create SDDC button
When you deploy an SDDC on VMware Cloud on AWS, it is created within an AWS VPC dedicated to your organization. VMware creates and manages this VPC, and you have no direct access to it.
As this is a lab/demo environment, we will not be connecting an AWS account. Click Next
Configure Management Network
The final step before deploying your SDDC is to define the CIDR range for the management network.
Enter an IP address range for the management network as a CIDR block (i.e 10.2.0.0/16) or leave the text box blank to use the default. Consider the following when choosing the management subnet:
- Specify a private subnet range (RFC 1918) to be used for vCenter Server, NSX Manager, and ESXi hosts.
- Choose a range that will not conflict with other networks you will connect to this SDDC.
- Minimum CIDR sizes: /23 for up to 27 hosts, /20 for up to 251 hosts, /16 for up to 4091 hosts
Click Deploy SDDC. The SDDC will take a few moments to deploy
If your have problems calculating bits or did not take a Cisco CCNA class you can always rely on http://www.subnet-calculator.com/
Be careful to assign IP addresses inside the Host Address network range. In this case we have used the default 10.2.0.0/16 that means you can use ip starting from 10.2.0.1 to 10.2.255.254
As you can see the SDDC CLOUDNATIVES.IT has been created you can also click on the bell icon to see other notifications:
To access the information specific to the SDDC that was just created:
- Click View Details on the SDDC
Key areas to understand about your VMware Cloud on AWS Console:
- Summary – this is the default management page for your SDDC. View CPU, Memory and Storage metrics, Network configuration, Connection Info and Support as well as Actions that control your SDDC. You can also directly open your vCenters from your VMware Cloud on AWS console for ease of management, VM Migrations, Content migration and more.
- Network – Provides a full diagram of the Management and Compute Gateways. This is where you can view which VPNs are configured and Firewall Rules. We will cover this in more detail later.
- Add Ons – Here you will find Add On services for your VMware Cloud on AWS environment, like Hybrid Cloud Extension and Site Recovery.
- Troubleshooting – Allows you to run network connectivity tests to ensure all necessary access is available to perform select use cases.
- Settings – gives you access to your vSphere Client (HTML5), vCenter Server API, PowerCLI Connect, vCenter Server and reviews your Authentication information.
- Support – you can contact Support with your SDDC ID, Org ID, vCenter Private and Public IPs and the date of your SDDC Deployment.
- Actions Menu – This will contain any actions available for your SDDC including deletion of the environment.
- Open vCenter – you can directly access your Private SDDC through this option. Before you can login to your vCenter, you must open network access to vCenter through the management gateway. Choose an option for opening network access by creating a Firewall Rule and setting up your VPN access.
Note: Because this is a demonstration environment, you will not have access to a vCenter server. Let’s assume we have an access.
To connect to vCenter Server and manage your new SDDC, you must either configure a VPN connection to the management gateway or configure a firewall rule to allow access to vCenter Server.
After login to the vCenter the SDDC will appear as a single logic datacenter with two fault domains. The ESXi hosts in the cluster span the two AWS availability zones. Customers can view which availability zone each host resides in from its summary tab. The fault domains listed correlate to the given AWS availability zone name. For a single view of all the ESXi hosts in a cluster and their fault domain, select the cluster and go to the Hosts tab. Within the Hosts tab, add the fault domain column.
When provisioning virtual machines, customers have more options when deploying to an availability zone. The first option is an auto placement. This occurs at the cluster level, where DRS will handle the placement of the workload. A more granular option is selecting a host in an availability zone to deploy virtual machines to. DRS will honor the virtual machine availability zone placement as a sticky rule. It will only move the virtual machine in case of a failure. vSphere HA will attempt to honor this placement decision if possible. An availability zone failure will have the same behavior as a vSphere HA event. All virtual machines in the failed availability zone will get restarted in another availability zone. vSphere HA restart priority is also taken into account:
- vCenter Server has the highest restart priority. Other management virtual machines have a high restart priority
- Virtual machines migrated (cold or live) from on-premises will keep their restart priority
- New Virtual Machines created on a stretched cluster will restart after other higher priority virtual machines
Customers now have full resiliency for their mission-critical applications across AWS availability zones with zero RPO due to synchronous replication built in natively in their Cloud SDDC.
We will discuss the Management Gateway Firewall Rules, Management Gateway DNS and creating a Management VPN for vCenter connectivity in another post. Let’s have a look at some info in the Network page.
In the VMware Cloud on AWS Console, you can view the Networking diagram of your Hybrid cloud. You will configure your network configuration to complete your VMware Cloud AWS connection to your private cloud.
In the VMware Cloud on AWS Console, you can configure firewall rules, configure an IPsec VPN, and configure DNS for the management gateway. To connect your Private Cloud to VMware Cloud on AWS, you need to configure a Management Gateway.
We will review how to configure the following networking components to setup your Management Gateway.
- Configure Management Gateway Firewall Rules
- Configure Management Gateway DNS
- Create a Management VPN
Once your Management Gateway is configured, the Compute Gateway needs to be configured to complete the networking connectivity for your VMware Cloud on AWS environment. The reason there are two gateways is to isolate the management network from the compute network through separate VPN connections.
The Compute Gateway handles network traffic for your workload VMs. You will review the following components to setup a Compute Gateway:
- Set Compute Gateway Firewall Rules
- Configure network address translation(NAT) rules to your workload virtual machines
- Create a Compute VPN back to the on-premises network
- Set Compute Gateway DNS
- Request Public IP Addresses
Note: This is a simulated lab and we will NOT be able to create any VPN to your private cloud with VMware Cloud on AWS during this lab. The steps that require connectivity to your private cloud will be noted. The steps are provided for demonstration purposes only.
Create a Management VPN
Creating a management VPN allows you to securely access the vCenter Server system and Content Library deployed in your SDDC. Configure an IPsec VPN between your on-premises data center and cloud SDDC to allow easier and more secure communication. You don’t have to set up a VPN connection, but transferring virtual machine templates and disk images into your SDDC in the cloud is easier and more secure if the connectivity is complete.
Configuring a management VPN requires the following steps:
- An on-premises router or firewall capable of terminating an IPsec VPN, such as Cisco ISR, Cisco ASA, CheckPoint Firewall, Juniper SRX, NSX Edge, or any other device capable of IPsec tunneling.
- The router or firewall should be configured with cryptography settings as described in Recommended Cryptography Settings in the VMware Cloud on AWS documentation.
If your on-premises gateway is behind another firewall, allow IPsec VPN traffic to pass through the firewall to reach your device by doing the following:
- Open UDP port 500 to allow Internet Security Association and Key Management Protocol (ISAKMP) traffic to be forwarded through the firewall.
- Set UDP port 4500 for Internet Key Exchange (IKE) (required only if NAT is used) to the list of firewall ports
- Set IP protocol ID 50 to allow IPsec Encapsulating Security Protocol (ESP) traffic to be forwarded through the firewall.
- Set IP protocol ID 51 to allow Authentication Header (AH) traffic to be forwarded through the firewall.
Configure the Management Gateway side of the tunnel.
To add a VPN we need to go under
- Click the arrow next to IPsec VPNs under Management Gateway
- Click ADD VPN
- It is the name for the VPN
- Click Remote Gateway Public IP and enter the IP address of your on-premises gateway, this is just an example, use your IP addresses.
- Click Remote Gateway Private IP and enter the Private IP address of your on-premises gateway
- Click Remote Networksand enter internal address for the address of your on-premises management network
- There are 3 types of Encryption available in VMware Cloud on AWS (AES, AES 256, and AES GCM)
- Perfect Forward Secrecy select
- Diffie Hellman select your choice that are compatible with your firewall.
- You can increase the security changing IKE version to 2
- You can increase the security using SHA_256
- Remember PSK Pre-shared key should never be a password shared key but “passphrase shared key” in fact you can use 128 characters, limiting brute-force attacks.
- Click Save , you will see a message of VPN successfully created.
Verifying the VPN Connection
Note: Because this is a simulated environment, the connection will remain disconnected or in unknown state. Please ignore any errors and move on to the next step.
In a real scenario you would need to configure the on-premises side of the tunnel. Configuration of the gateway device in your on-premises data center might need to be performed by a member of your networking team. Consult the VMware Cloud on AWS documentation for your gateway or firewall device to learn how to configure it to match the on-prem VPN settings.
When the VPN tunnel is configured in the private cloud, you should be able to verify connectivity in both the VMware Cloud on AWS Console and by accessing the vCenter Server deployed in your environment with a Web browser
After you have saved the configuration, the VPN should now show as connected in the console diagram and the VPN settings.
VMware Cloud on AWS Management Gateway Firewall Rules
By default, the firewall for the management gateway is set to deny all inbound and outbound traffic. You may add additional firewall rules to allow traffic as needed.
In the browser session previously opened perform the following task:
- Select the Network tab and scroll the page down to the Management Gateway
- Click the arrow next to Management Gateway Firewall Rules
- Click Add Rule (May Not Look As Shown)
- For the Rule Name, enter vCenter Access
- For the Source, enter 10.66.0.0/16 which is the CIDR block for the Remote (On-Premise) internal management networks. Once the VPN connection is established, this network will be able to communicate with vCenter
- Click the drop down below Destination and select vCenter to identify the vCenter server for VMware Cloud on AWS
- Click the drop down below Service and select HTTPS (TCP 443) to enable SSL access
- Click Save to save the firewall rule
Firewall Rule Accelerator
After creating the VPN the Firewall Rule Accelerator is enabled. The Firewall Rule Accelerator can be used to automatically create firewall rules for things like vCenter Access, Hybrid Linked Mode, and Site Recovery.
- Click the arrow next to Management Gateway Firewall Rule Accelerator
- Click Create Firewall Rules
- The firewall rules in the table will be automatically created and once successful will have a green check box to the left of each rule. You will also see the rules in the table added to the Firewall Rules section. You will notice the green check mark next to the Firewall Rule we created manually.
The steps required to connect to the customer private cloud would be as follows:
- Click on Network
- Click the arrow next to DNS
- Click Edit on the far right-hand side under DNS
- Enter 10.66.1.4 and 10.66.1.8 (it’s an example) for DNS Server 1 and 2 (In your deployment these would be the private IP addresses for your internal DNS servers)
- Click Save to save the configuration
This completes the configuration of the management gateway.
Viewing Compute Logical Networks
Since you are unable to create logical networks, you can utilize the default logical network created during the SDDC build for the remainder of this networking section.
From now you will see different step icon colors because I will follow VMware HOL Labs graphics.
Since you are unable to create logical networks, you can utilize the default logical network created during the SDDC build for the remainder of this networking section of the manual.
To find the logical network information, follow these steps:
- Click the Arrow next to Logical Networks under the Compute Gateway
- You can see the default logical network has a CIDR block of 10.0.0.0/24 and has DHCP enabled
Setup Compute Gateway Firewall Rules
By default, the firewall for the compute gateway is set to deny all inbound and outbound traffic. You may add additional firewall rules to allow traffic as needed.
In the browser session previously opened perform the following task:
- Scroll down the network page to the network settings for the compute gateway (not management)
- Click the arrow next to Firewall Rules
- Click Add Rule (Not Shown)
- For the Rule Name, enter Web Access
- Under Action, select Allow in the drop down
- For the Source, type Any which will allow any computer on the internet to connect to this web server
- For Destination, type 10.0.0.10. This is the IP address of the virtual machine that was deployed
- Click the drop down below Service and select HTTP (TCP 80) to enable HTTP access
- Click Save to save the firewall rule
Proceed to request a public IP address
Request a Public IP Address
Before you can configure a Network Address Translation (NAT) rule, you must request a public IP address.
In the browser session previously opened perform the following task:
- Scroll down the network page to the network settings for the compute gateway
- Click the arrow next Public IPs
- Click Request Public IP (Not Shown)
- Below Notes, type Web Server Public IP
- Click Request to get a public IP address
After you click Request, you will see the new Public IP address associated with the SDDC now.
Set Inbound NAT Settings
Inbound Network Address Translation (NAT) allows you to map internet traffic to a public-facing IP address and port to a private IP address and port inside your SDDC’s compute network.
- Scroll down the Network page to the Network settings for the Compute Gateway
- Under Compute Gateway, click the arrow next to NAT
- Click Add NAT Rule (Not Shown)
- Type Rainpole Web NAT under Description
- Select the drop down under Public IP and select the IP Address you requested in the Request a Public IP lesson
- For Service, select HTTP (TCP 80) to allow inbound web traffic
- Under Public Ports leave the default of 80
- For Internal IP specify our Web Server IP address of 10.0.0.10
- Click Save to activate the rule.
After completing this configuration, the web server would be available via the internet through the public IP address on port 80.
You can now configure the Compute VPN and Compute DNS following the same steps that were completed on the Management Gateway explained in this article. You will need to replace the SDDC IP ranges on the VPN with the IP range for the logical switch on the Compute Gateway.
This concludes the configuration steps needed to connect your private cloud to VMware Cloud on AWS. You have completed setting up the VMware Cloud on AWS Management and Compute Gateways.
Getting Information About Your vCenter
The VMware Cloud on AWS portal provides connectivity information for the vCenter server associated with the environment. This information includes URLs to access the vCenter server, authentication credentials and PowerCLI connection information.
vCenter connectivity information is highlighted in the screenshot:
- Click Settings in the details for the SDDC you provisioned in previous steps
- Expand the section Default vCenter User Account to see the Authentication credentials in order to login to the vCenter Server. You can Click the boxes next to the credentials to copy them to the clipboard
- Expand the section vSphere Client HTML5 to view the URL for the vCenter HTML5 Client
- Expand the section vCenter Server API Explorer to view the URL for the API Explorer
- Expand the section PowerCLI Connect to view an example string to access the vCenter server using PowerCLI
- Expand the section vCenter FQDN to view additional details about the vCenter Server
Getting Support with VMware Cloud on AWS
VMware Cloud on AWS allows customers to have one point of contact for Support. You have a number of options for getting help for your VMware Cloud on AWS environment.
Before you contact VMware for support, have the support information for your SDDC ready. Click Support in the details view for the SDDC you provisioned earlier in this module.
Select a method for getting help or support:
- Chat – Click the Chat icon and Click New Conversation. Type your message in the chat window. You can include images by dragging them into the chat window.
- File a support request on My VMware – Click the help icon and click Support Center. You are taken directly to a form for filing a support request after you log into the My VMware portal.
- When contacting support, please have your Org ID and SDDC ID available to expedite the support process.
It is also important to remember that traditional phone and web support are included as part of the product.
VMware Cloud on AWS – August ’18 release highlights Vmware roadmap tell us that the innovation is every 3 monts instead of every 1 year we used to wait when using only the ESXi stack.
Recaps (credits to Massimo Re Ferré):
VMware Cloud SDDC account Account runs a new AWS account to run SDDC resources, it is owned, operated and paid directly by VMware as single tenant for all SDDC resources. Customers are billed by Vmware. VMware and AWS both configured routes pairing hosts inside VMware Cloud AWS SDDC Account to VPC inside the AWS Customer account.
AWS customer owned account: is owned, operated, and paid directly by the customer, private connectivity to VMware cloud SDDC , full access to the native AWS services (Cloudtrail, Cloud Front, WAF etc.). Have a look here for a good demo in action https://www.youtube.com/watch?v=Ol7rNfkZT2c
Provisioning: Automated account creation and enviroment provisioning by using the API. Automated interconnection created btw AWS and VMware SDDC. Commercial solution and billing to VMWARE, this is a VMware service managed and billed only by VMware if you drop using vRealize Log Insight and switch over to Cloud Trail you will pay Amazon Aws.
Operationssupport provided by vmware, AWS infrastrutcute for VMC support managed by VMware, ongoing infrastructure monitoring.
Maintenance: no root access to esxi, it’s a vsphere as a service managed by vmware, ongoing stack maintanance managed directly by vmware, upgrade implementation and execution, the final customers just consume the service, configure l2 virtual networks it’s a one of the resason why NSX is used.
Hybrid connectivity: AWS Direct connect use private circuit MPLS and it is used from mature customers, because it is faster and more secure. There is another solution using using VPN on internet instead of MPLS. Have a look to this video for the prerequisites and architecture review for VMware Cloud on
Many thanks to VMware for their Hands-on Labs, youtube videos and also thanks to Amazon for their youtube video and their webinar. Follow always the official documentation for having up-to-date and corrected information.