VMC on AWS
In Switzerland where VMware has a lot of smaller to medium sized companies, the demand for a cloud solution is increasing. The customers are not yet ready to put all their servers and data into to the cloud, so they go for a hybrid cloud strategy.
And now it makes even more sense and got easier since VMware’s offering VMware Cloud on AWS (VMC on AWS) exists. This service, powered by VMware Cloud Foundation (VCF), brings VMware’s SDDC stack to the AWS cloud and runs the compute, storage and network products (vSphere, vSAN, NSX) on dedicated bare-metal AWS hardware.
If you would like to try this offering you have the option for a Single Host SDDC which is the time-bound starter configuration and comes with the limitation of 30 days. After 30 days your Single Host SDDC will be deleted and all data will be lost as well. If you plan to scale up into a 3-host SDDC you retain all your data and you SDDC is not time bound anymore.
This pretty new service is already available in 13 global regions and already had 200+ released features since its launch. VMC on AWS is available almost everywhere – in US and Asia Pacific for example – and in Europe you find the service hosted in Frankfurt, London, Paris and Ireland.
It’s not hard to guess what the use cases are for a service like this. If you are building up a new IT infrastructure, don’t want to have your own data center and purchase any server, then you might want to consider VMC on AWS. Another project could be to expand your market into a new geography and extend your footprint into the cloud based on a VMware-consistent and enterprise-grade environment in the AWS cloud.
A few customers are also finding a new way to easily deliver business continuity with VMware Site Recovery and take advantage of VMC on AWS which delivers a robust Disaster Recovery as a Service (DRaaS) possibility.
Another reason could be that your on-premises data center is in danger because of bad weather and you want to migrate all your workloads to another region.
Or you just want to quickly build a dev/test environment or do a PoC of a specific solution or application (e.g. VMware Horizon).
In my opinion EDRS is one of best reasons to go for VMC on AWS. EDRS allows you to get the capacity you need in minutes to meet temporary or unplanned demand. You have the possibility to scale-out and scale-in depending on the generated recommendation.
A scale-out recommendation is generated when any of CPU, memory, or storage utilization remains consistently above thresholds. For example, if storage utilization goes above 75% but memory and CPU utilization remain below their respective thresholds, a scale-out recommendation is generated.
A scale-in recommendation is generated when CPU, memory, and storage utilization all remain consistently below thresholds.
This is interesting if your dekstop pool is creating more instant clones and the defined value of RAM for example is above the threshold. But there is also a safety check included in the algorithm, which runs every 5 minutes, to provide time to the cluster to cool off with changes.
If you check the EDRS settings you have the option for the “Best Performance” or “Lowest Cost” policy. More information can be found here.
Horizon on VMC on AWS
For customers who are already familiar with a Horizon 7 on-premises deployment, Horizon on VMC on AWS lets you leverage the same architecture and the familiar tools. The only difference now is the vSphere outsourcing.
Horizon can be deployed on VMware Cloud on AWS for different scenarios. You could have the same reasons like before – data center expansion or to have a disaster recovery site in the cloud. But the most reason why a customer goes for Horizon on VMC on AWS is flexibility combined with application locality.
There are customers who were operating an on-premises infrastructure for years and suddenly they are open to a cloud infrastructure. Because the SDDC stack in the cloud is the same like in the private cloud the migration can be done very easily. You can even use the same management tools like before.
Minimum SDDC Size
The minimum number of hosts required per SDDC on VMware Cloud on AWS for production use is 3 nodes (hosts). For testing purpose, a 1-node SDDC is also available. However, since a single node does not support HA, it’s not recommended for production use.
Cloud Pod Architecture for Hybrid Cloud
If you are familiar with the pod and block architecture you can start to create your architecture design. This hasn’t changed for the offering on VMC on AWS but there is a slight difference:
- Each pod consists of a single SDDC
- Each SDDC only has a single vCenter server
- A Horizon pod consists of a single block
Each SDDC only has one compute gateway which limits the connections to ~2’000 VMs or user sessions. This means that the actual limit per pod on VMC on AWS is ~2’000 sessions as well. When the number of compute gateways per SDDC can be increased, Horizon 7 on VMC on AWS will definitely have a comparable scalability with the on-premises installation.
You can deploy a hybrid cloud environment when you use the Cloud Pod Architecture to interconnect your on-premises and Horizon pods on VMC on AWS. You can also stretch CPA across pods in two or more VMware Cloud on AWS data centers with the same flexibility to entitle your users to one or multiple pods as desired.
The deployment of Horizon 7 on VMC on AWS started with Horizon 7.5 but there was no feature parity at this time. With the release of Horizon 7.7 and App Volumes 2.15 we finally had the requested feature parity. This means since Horizon 7.7 we can use Instant Clones, App Volumes and UEM. At the time of writing the vGPU feature is not available yet but VMware is working with Amazon on it. With the release of Horizon 7.8 a pool with VMware Cloud on AWS is now capable of using multiple network segments, allowing you to use less pools and/or smaller scopes. Please consult this KB for the currently supported features.
Use AWS Native Services
When you set up the Horizon 7 environment in VMware Cloud on AWS you have to install and configure the following components:
- Active Directory
- Horizon Connection Servers
If you are deploying Horizon 7 in a hybrid cloud environment by linking the on-premises pod with the
VMC on AWS pod, you must prepare the on-premises Microsoft Active Directory (AD) to access
the AD on VMware Cloud on AWS.
My recommendation: Use the AWS native services if possible 🙂
AWS Directory Services
AWS Managed Microsoft AD is built on actual Microsoft Active Directory and does not require you to synchronize or replicate data from your existing Active Directory to the cloud. You can use standard Active Directory administration tools and take advantage of built-in Active Directory features, such as Group Policy and single sign-on (SSO).
Amazon Relational Database Service
Amazon RDS is available on several database instance types – optimized for memory, performance or I/O – and provides you with six familiar database engines to choose from, including Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle Database, and SQL Server. You can use the AWS Database Migration Service to easily migrate or replicate your existing databases to Amazon RDS.
This service allows you to quickly setup a SQL Express (not recommended for production) or regular SQL Server which can be used for the Horizon Event DB or App Volumes.
Amazon FSx for Windows File Server
Amazon FSx for Windows File Server provides a fully managed native Microsoft Windows file system so you can easily move your Windows-based applications that require file storage to AWS. Built on Windows Server, Amazon FSx provides shared file storage with the compatibility and features that your Windows-based applications rely on, including full support for the SMB protocol and Windows NTFS, Active Directory (AD) integration, and Distributed File System (DFS).
At the time of writing I have to mention that the FSx service has not yet officially been tested and qualified for User Environment Manager (UEM), but that’s no problem. Technically it’s working totally fine.
Amazon Route 53
The connectivity to data centers in the cloud can be a challenge. You need to manage the external namespace to give users access to their desktop in the cloud (or on-prem). For a multi-site architecture the solution is always Global Server Load Balancing (GSLB), but how is this done when you cannot install your physical appliance anymore (in your VMC on AWS SDDC)?
The answer is easy: Leverage Amazon Route 53!
Amazon Route 53 effectively connects user requests to infrastructure running in AWS – such as Amazon EC2 instances, Elastic Load Balancing load balancers, or Amazon S3 buckets – and can also be used to route users to infrastructure outside of AWS. You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints.
Check Andrew Morgans blog article if you need more information about Route 53.
Horizon on VMC on AWS rocks! 🙂
Hi – thanks for avery useful blog! Is there any update if (and when) multiple compute gateways per SDDC will become a reality please?
At the moment I cannot tell you more about this topic, sorry.
Nice article & well explained!
Thank you, Holger. It’s probably not completely up to date anymore, but the overall architecture and integration is still valid. 🙂