Hybrid Cloud VMware Cloud on AWS

Blog Series- Onboarding and Managing VMware Cloud on AWS: Part 1- Preparing to deploy an SDDC

It’s a simple process to deploy a VMware Cloud on AWS SDDC. However choosing the wrong options during deployment can mean deploying an SDDC that’s not fit for purpose. Follow these seven steps to help you make sure that the SDDC that you build is the one you want.

Part 1 – Preparing to deploy an SDDC

Deploying a VMware Cloud on AWS SDDC is a simple process, requiring only a few clicks. When done correctly it results in a full vSphere SDDC, running ESXi, vCenter, vSAN & NSX-T hosted on AWS cloud in under 2 hours.  While it is a simple process, it’s important to understand the impacts of the options you select during the creation process.This helps ensure that the SDDC you build is really the SDDC you want. While there are many options that you can modify post-deployment, there are some key decisions that you need to make up-front and these can’t easily be changed. This article will help you make the choices that result in the right SDDC for your needs.

Here are some of the steps in order to deploy your SDDC:

  1. The first choice you’re presented with is the AWS region where you want your SDDC to be deployed. In most cases, this will be obvious. You’ll choose the region that’s closest to where the majority of your users are, to any on-prem data centers you’ll be interconnecting with, where you have AWS Direct Connects to, or in the case of a DR site, far enough away from your primary site to meet your DR Plan’s tolerance, but close enough to still meet the required connectivity. The important item to note with this choice is that it can’t be changed once the SDDC is deployed, as physical hosts are allocated to your SDDC in the selected region.
  2. Following that, you’ll select whether the SDDC is a single-host (with 30-days lifespan), multi-host (standard SDDC) or Stretched Cluster. The Stretched Cluster distributes the hosts across 2 AZs to provide higher availability, by being able to tolerate a complete AZ loss. These SDDCs provide better availability, however they consume double the storage.
  3. Next, you have to choose the host/instance type, which determines the hardware used. This choice also impacts how much storage is available, as the ratio of CPU, Memory, and storage is fixed for a given host type. i3 hosts are the default option, providing about 10TB of local NVMe-based storage, 36 CPU cores and 512GB of memory per host. R5 hosts use EBS backed storage with a capacity of 15 to 35TB per host (that you can add in 5TB increments as per your requirement), 48 CPU cores and 768GB of memory per host. The selected host type will be used for the first cluster. This hosts management components, and can’t be changed post-deployment. Additional clusters added to your SDDC can use any available host type and don’t need to use the same type as the first cluster.
  4. A name will also need to be provided for the SDDC. It’s best to determine the naming convention you wish to use ahead of time, to align with your operational processes and growth plans. The name can be changed after deployment.
  5. Once this is done, the next steps are about connecting to your AWS account. This serves several purposes: it selects the AZ where the SDDC will be deployed, so that it can be close to existing AWS workloads, or conversely, separated from them to improve availability. It also creates a connection between the SDDC and native AWS to allow workloads in the SDDC to leverage native AWS services such as EC2, RDS, S3. The process itself involves running a cloud formation template that can be accessed directly from the create SDDC wizard. This sets up IAM roles granting VMware’s accounts access to the required components of your AWS account to be able to create and maintain the VPC & ENI links. You’ll also need to dedicate a subnet in the VPC you’re linking to the SDDC for these ENIs. When an SDDC is created, 17 ENIs will be created, and 18 IPs assigned from the selected subnet.
  6. The next part of the SDDC creation wizard involves defining a Management subnet for the SDDC to use. It’s important to note that this subnet is dedicated to the management of the SDDC itself, and not for use by workload VMs in the SDDC. This network must come from your enterprise IP space, as the SDDC includes services that communicate with your on-prem environment, such as vCenter, NSX API endpoints, router interfaces, and ESXi host IPs (for VM mobility, replication, and remote console access). The network can be one of three sizes: /23, /20 or /16.  The size of the subnet determines the scalability of the SDDC: a /23 management subnet supports up to 27 ESXi hosts. A /20 will support up to 251 hosts, and a /16 will allow up to the supported maximum.  Since this subnet can’t be changed afterward, it’s important to use the appropriate size for the SDDC to avoid constraints later on. Note this network must be from the RFC1918 ranges, although 10.0.0.0/15 and 172.31.0.0/16 are reserved and cannot overlap the selected network.
  7. The final item to be aware of prior to deploying an SDDC is how it will be billed. By default, all hosts are billed at the on-demand rate, which provides full flexibility in adding or removing resources, as hosts are billed by the hour with no long-term commitment.  However, since most SDDCs will be deployed for longer durations, there is the option to purchase subscription of 1- or 3-year duration paid up-front that provide significant discounts on the per-host price. Subscriptions are associated with the region, customer Org, and instance type (i.e. i3 or R5).These can’t be changed once purchased. They expire at the end of the term, regardless of how much they’ve been used. Any subscription that match deployed hosts will be used for billing automatically, with any additional hosts deployed being charged at the on-demand rate.  Subscriptions can be added at any time. These will automatically take effect against deployed hosts by providing the discounted rate over on-demand pricing.

Check out this SDDC deployment video to see how simple it is to deploy your first SDDC.

Pre-Deployment Checklist

For other information related to VMware Cloud on AWS, here are some more learning resources for you:

Michael Kolos

Michael Kolos has been at VMware since 2015, starting with NSX, then moving to the VMC product area in 2017 as a Customer Success Architect. In 2020, he joined VMC…

Related Articles