A VMware Cloud on AWS SDDC network is carved out of a subnet in an AWS VPC that you own. Before you can deploy your first SDDC, you need to create that VPC and subnet using AWS tools.
- Administrator access to an AWS account so you can create and configure the VPC.
- Information about Choosing a Region so you can understand how the available AWS regions and availability zones affect your plans for SDDC deployment.
- IP address space details for other networks, including your on-premises network and networks used by services such as storage providers and disaster recovery solutions, to which the SDDC network will connect. Your SDDC management network address space cannot overlap with any of those address spaces.
- A network addressing plan including:
- any routes into the SDDC you plan to advertise externally, and a list of the addresses to which they will be advertised
- SDDC network gateways from which where you want traffic to egress the network
- Any public IP addresses, assigned to you by IANA or another regional internet registry. where your customers expect your applications to be accessible.
Many of the decisions you have to make when creating the AWS VPC and subnet you'll use for VMware Cloud on AWS can't be changed without deleting the SDDC and starting over, so lets begin with a summary of the AWS objects and operations you'll need to understand before making those decisions.
AWS Accounts and Account Linking
Every VMware Cloud on AWS SDDC runs in an AWS account owned and managed by VMware and dedicated to your VMware Cloud on AWS Organization. This gives VMware complete responsibility for the operational integrity of the VPC and the SDDC services that run in it. We use AWS cross-account access to link this VPC to your own VPC during SDDC deployment. We give you a couple of options when it's time to link the accounts, including delayed linking for single-host trial SDDCs and re-using an AWS account that had been previously linked to an SDDC that you abandoned, but for most new SDDC deployments, it's a good idea to start by creating a VPC owned by an AWS account that you own and have Administrator access to. Before you do that, you need to understand the basics of AWS regions and availability zones
AWS Regions and Availability Zones
- A region that's geographically close to the majority of your users helps reduce network latency for them.
- A region that's geographically close to any on-premises data centers you’ll be connecting with helps reduce network latency for those connections.
- If you plan to use the SDDC for Disaster Recovery (DR), pick a region that's geographically distant from the data you're protecting, but close enough to your users and on-premises data centers to keep latency to a minimum.
Every AWS region includes multiple availability zones (AZs), each of which constitutes a separate fault domain. Events such as natural disasters and power grid failures do not typically affect more than one AWS region. Configuring your VMware Cloud on AWS SDDC to use stretched clusters (in multiple AZs) provides additional fault tolerance for SDDC operations.
The AZ names you see in the VMware Cloud Console are unique to your AWS account. The same AZ could have a different name when viewed from another account
The VMware Cloud Tech Zone article VMware Cloud on AWS: Stretched Clusters has more information about how stretched clusters work in VMware Cloud on AWS. We discuss stretched clusters in more detail in our topic on Resource Planning.
VPC Subnets
When you deploy an SDDC, you have to choose at least one AZ for it to occupy. If you want the SDDC to have stretched clusters, you'll need to choose two. And because the SDDC will be deployed in the AZ containing the subnet you select, it's best to start by creating a VPC and subnet in every region of that AZ. Doing this makes it easier to identify all AZs where your SDDC can be deployed and select the one that best meets your SDDC placement needs. The VPC you connect to when deploying the SDDC becomes the Connected Amazon VPC in the VMware Cloud Console. The VPC subnet is used only for communication between workloads running in your SDDC and native AWS services in the connected VPC.
The VPC subnet CIDR must be unique within your enterprise network and cannot overlap with any other SDDC networks, including the Management subnet discussed in the next section. The minimum size for the VPC subnet the SDDC is linked to is /27, but to support the maximum capacity of the SDDC’s management cluster, we recommend using a /26 subnet. There is no advantage to using a subnet larger than /26. Once the SDDC has been created, you cannot moify or delete or change this subnet.
See Creating a Subnet in Your VPC in the AWS documentation for information about how to use the Amazon VPC console to create a subnet in your VPC.
SDDC Subnets
- A single Management subnet, used by SDDC management components such as the ESXi hosts (management, vMotion, and other interfaces), vCenter, NSX Manager, and managed services such as HCX and Site Recovery appliances.
- A Compute network with one or more Compute subnets for use by SDDC workloads.
The Management Subnet
- It cannot overlap with the VPC subnet CIDR.
- It cannot overlap with the CIDR of any on-premises network.
- It must be in one of the "private address space" blocks defined by RFC 1918 (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16).
Compute Subnets
Unlike the Management subnet, which you must specify before you deploy the SDDC, compute subnets can be created only after the SDDC is up and running. Each compute subnet is a virtual network (an NSX network segment) that is typically routed so that workloads connected to it are accessible from other networks, but also be configured as an isolated network with no external connectivity, or an extended network that you can use with an L2VPN. Selecting IP Subnets and Connectivity for your SDDC has more information about SDDC subnets and how they connect to each other and the outside world.