VMware Cloud on AWS - Part 1 - Manual Deployment
This is my first blog on Securefever, and you can read my introduction here:
https://www.securefever.com/about
In this blog post, we will cover the basics of a VMC on AWS deployment.
The blog is meant to be accessible to everyone new to VMC.
This blog series will cover requirements at both VMC and AWS levels.
Any requirement listed in this blog will include examples created in our own AWS/VMware demo environment.
My VMC environment is based on a 1-Node deployment. Keep in mind that this is not suitable for production workloads.
The expected blog series will develop over the next couple of months.
Our initial deployment will be conducted manually. We will proceed to a DevOps approach in a follow-up exercise in which we will look at an automated deployment using Terraform.
This blog series will also dive into additional services at a later stage, partially outside of the VMware/AWS ecosphere (external storage).
For those interested, I will also follow up with a series on VMware Cloud on AWS as a disaster recovery solution.
With that being said, let's jump right in!
Requirements - AWS
This series will include details and easy-to-follow instructions. However, I highly recommend acquaintance with the basics/concepts of AWS Virtual Private Clouds (VPC), Regions, and Availability Zones (AZ).
Technical requirements:
AWS Account
A VPC (in the region we want to deploy the SDDC), along with at least one VPC subnet in the AZ where we want to deploy.
Please note that like in all hyperscalers, you pay for what you use. With that in mind, setting up an account, VPCs, and Subnets are free of charge.
I encourage you to keep a cloud mindset and ensure that unused resources are powered off and that you delete all resources post the completion of your testing, as these can generate monthly charges.
I have reserved the following networks for the lab’s AWS resources. Your VPC networks do not need to reflect my selection; however, it may help you to follow along.
AWS VPC: 10.10.0.0/16
VPC Subnet AZ1: 10.10.0.64/26
VPC Subnet AZ2: 10.10.0.128/26
VPC Subnet AZ3: 10.10.0.192/26
This is just an example network that was free in our lab setup, and I use this for many different tests/resources within AWS.
The VPC network scope does not need to be a /16.
Why do I need an AWS account?
The connected VPC has VPC subnets in one or each of the available availability zones within the AWS region.
By selecting one of the VPC subnets in a specific AZ, we determine in which AZ we want the SDDC to be deployed.
Every production VMC on AWS deployment must be permitted to access a customer-owned VPC; this is referred to as a “Connected VPC” and it allows connectivity with AWS native services. The connected VPC enables customers to access services over a low-latency, high-bandwidth, AWS-managed connection. We automatically configure Elastic Network Interfaces for the above-mentioned low latency connectivity between resources in the VMC SDDC and any resources in AWS during the initial deployment. This step is optional only for environments that will be deleted prior to 60 days. Environments hosting workloads have to be connected to a shared VPC of your choice.
The ‘Connected VPC’ can be leveraged for use cases like hosting an application's database in RDS, adding load-balancing, accessing private S3 endpoints, or any of AWS' plethora of services. The ‘connected VPC’ also has the advantage of cost-free traffic to the VPC subnet in the AZ of the SDDC. This feature has the inherent benefit of lowering traffic charges, e.g. for backup costs in AWS.
We will talk about additional use cases in a future blog post.
Implementing VPC + VPC Subnets in the AWS Account
To begin we will start by deploying the VPC in our preferred region (I am using London). Please note that VMC is not available in every region. Use the following link to find an eligible region near you:
https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws.getting-started/GUID-19FB6A08-B1DA-4A6F-88A3-50ED445CFFCF.html
Every VPC must include at least one subnet. I will deploy a subnet in each of the AZs. Creating subnets in all AZs simplifies the deployment and testing process should we need to route traffic into other AZs later.
I repeated the process twice to create "rf_connected_vpc_subnet2" and "rf_connected_vpc_subnet3".
My naming convention combines the letters “RF”, followed by a description.
I encourage you to follow your organizations naming convention if you have one.
If you are building your first cloud, please mind AWS’ naming convention guidelines:
https://docs.aws.amazon.com/mediaconnect/latest/ug/tagging-restrictions.html
Our efforts should deliver a VPC with three subnets.
Now that the hard work is done, let’s proceed to the fun part, the SDDC deployment:
Table of the newly created VPC subnets
Requirements - VMware / VMC
This section assumes you have a VMC organisation.
VMC requires the following information / requirements:
The AWS region we want to deploy in (the same region where we deployed the VPC)
Deployment Type (Stretched Cluster or not)
Host Type
Number of Hosts
AWS Account (‘Shared VPC’ account)
The AZ we want the SDDC to be deployed in (determined by selecting the VPC subnet in that AZ)
Management Subnet (private IP range used to host the SDDC management components, like vCenter, NSX Manager, etc.)
AWS Region:
For this exercise, I will deploy VMC in London.
Deployment Type:
This lab will only contain a 1-Node SDDC. The "Single Host" deployment is a particular deployment only meant for POCs or short testing periods.
(This lab will not demo a stretched cluster. The stretched cluster solutions are meant for businesses that require an SLA of 99,99. Please leave a comment or message me if you're interested in learning more about stretch clustering or VMC HA capabilities.)
Host Type / Number of Hosts:
1 x i3 instance.
I am happy to announce the expanded instance size and offerings now include i3en, and i4n. Follow the link below for an overview of available instance types and their specs:
https://docs.vmware.com/en/VMware-Cloud-on-AWS/services/com.vmware.vmc-aws-operations/GUID-98FD3BA9-8A1B-4500-99FB-C40DF6B3DA95.html
Please work with VMware and / or a partner to determine which host type makes sense for your organisation and workload requirements.
AWS Account:
Let's get started by connect an AWS account to your VMC organisation.
In order to do this, you need to run an AWS Cloud Formation template with an administrative user of the AWS account.
As we have already created the VPC and subnets in a specific account, we want to make sure we link the AWS account with these resources.
AWS VPC + Subnet:
After connecting to an AWS account we can select the VPC and VPC subnet.
Remember that the VPC subnet determines the AZ in which your SDDC will be running.
Management Subnet:
The management subnet is where VMC will run the management components.
For a production setup we recommend a /16 subnet from the private IP space defined in RFC 1918, but a minimum of /20 is required. Moreover, you can not choose the CIDRs 10.0.0.0/15 or 172.31.0.0/16, as these are reserved.
Note that the size of the management subnet influences the scalability of your SDDC and can not be changed after deployment. For an in-depth explanation of the management subnets, have a look at this blog post: https://blogs.vmware.com/cloud/2019/10/03/selecting-ip-subnets-sddc/
The deployment automation expects a /16, /20 or /23 (if non-production). Other ranges will not be accepted (/22 for example).
Putting it all together - deploying the SDDC
Log in to the VMC console (vmc.vmware.com):
Click on “Inventory”
Click on “Create SDDC”
Next, we configure the SDDC properties using the parameters we defined:
Name your SDDC
Select the region in which you created the ‘Connected VPC’
Select the ‘Single Host’ or desired host count.
Select the host type
Please be advised that this configuration is not recommended for operations longer than 60 days
Click on ‘Next’
Please ensure you can access or have credentials to the AWS management console to connect the AWS ‘Connected VPC’ account.
Select "Connect to AWS now," "Connect to a new AWS account"
Press "OPEN AWS CONSOLE WITH CLOUDFORMATION TEMPLATE":
This action will redirect to the AWS management console. Here we will execute the VMware-generated CloudFormation template:
Please click check the ‘I acknowledge that the AWS CloudFormation template might create IAM resources’
Press ‘Create Stack’
For more information on the permissions and or actions please visit the following link. There you will find VMware’s documented actions, roles used by the account linking, as well as the required permissions in the product documentation:
If your template is successful the results should look as follows:
We may now return to the VMC console and continue with the SDDC deployment:
The CloudFormation template allows VMC to connect to the ‘Connected VPC’ account in AWS. Please select the appropriate VPC and subnet from the dropdown:
Select the VPC
Select the subnet
Click ‘Next’
It is a good idea to perform a review and prior to making acknowledgements. If the choices look correct, we can now provide the management CIDR.
I will use 10.20.0.0/16 as the management subnet.
(If you do not provide any input, the deployment assumes the default of 10.2.0.0/16):
Provide you Management Subnet CIDR
Click ‘Next’
We are almost there. The following screen is advising us of costs and the start of the charges. Please ensure that you are ready to launch as costing starts as soon as we complete the “Deploy SDDC” process.
Click on “Charges start once your SDDC has finished deploying. Accrued charges will be billed at the end of the month.’
Click on “Pricing is per hour-hour consumed for each host, from the time a host is launched until it is deleted.’
Completion takes around 100 - 120 minutes.
With this, we conclude the first part of this blog series.
As you see, VMC might sound complicated first, but it quickly implemented with just a bit preparation.
In the next post, we will get dirty with Terraform.
See you soon!