I recently had an opportunity to work with a customer in setting up and configuring a VMware on Amazon Web Service (AWS) Software Defined Data Center (SDDC) as part of their cloud migration journey. The customer’s solution includes moving some of their applications to AWS EC2 instances, and the bulk of their applications will be migrated to VMware on AWS. For this phase of the project, our goal was to build the software defined data center and create a virtual private data center (VPN) on AWS. I’ll walk you through the process we followed to provision our account on AWS and on VMware on AWS.
To get things started we already knew that the SDDC would be connected to an AWS account so first we had to establish a new AWS account. Once we created this account we enabled our multi-factor authentication on the root account. Since we knew we would be extending our private network VLANs from on premises to the SDDC we wanted to ensure that we allocated two private CIDR blocks of a /16; one for the SDDC and one for the AWS VPC. These private CIDR blocks cannot overlap with any of the IP address spaces they currently had provisioned. Once we made these decisions, we could start creating provisioning resources.
We logged into the AWS console and captured the account number, as this will be required later when we create the SDDC. We then proceeded to create a new VPC on AWS; during the creation of the new VPC, we specified one of the /16 CIDR blocks. Next, we went to the Subnets: we already knew we wanted to leverage multiple availability zones on AWS, we needed to break down our /16. For this use case we decided to use a /20 and allocated one /20 to each of the 6 availability zones in this region.
Now that we’ve created our VPC on AWS, we can start the provisioning process on the SDDC. We had already created our SDDC account, and when we logged in we clicked a button which read “Create SDDC” and started the SDDC wizard. The first option we were presented with was to use an existing AWS account or to connect to a new AWS account. Since we created the account first, we proceeded by selecting the use existing option. Next up was naming our SDDC, selecting the number of nodes we wanted to start the cluster with, and what region we wanted to deploy into. As of today, the only available regions are US West (Oregon), US East (N. Virginia), and EU (London). The next choice we had to make was which VPC on AWS did we want to use, so we chose the new VPC we created previously. Once that was selected we were asked to select a subnet which had at least 64 IP addresses available. The next dropdown allows us to enter the /16 CIDR block for the VMware on AWS management network, this is the 2nd CIDR block we allocated previously. (As an aside: you cannot change the values specified for the management network after the SDDC has been created, and there are also some restrictions as the 10.0.0.0/15 and 188.8.131.52/16 are reserved.) Once we entered these last bits of information, we were able to click Deploy SDDC.
That’s it! The whole process from start to finish took us approximately 2 hours to complete. This included creating the AWS account, creating an AWS VPC, assigning subnets on AWS and walking through the wizard on VMware on AWS. Since we were not ready to create a VPN to our SDDC (due to change control) we decided to create a firewall rule on NSX to allow our IP address to connect to vCenter. (Important note: if you do not do this step, you won’t be able to connect.) Clicking on Open vCenter opens a popup dialogue presenting us with the default username and default password for vCenter. Clicking Open vCenter again presents us with the ever-familiar VMware vCenter Single Sign-On screen where we entered the credentials given to us and now we can access and manage our SDDC cluster.