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.

Before you deploy an SDDC, you'll need to understand how it will be used, who will use it, and how the management appliances and workloads in it will connect to other networks. You'll also need:
  • 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.
It would also be a good idea for you to review the VMware Cloud Tech Zone article VMware Cloud on AWS: Network Architecture, which provides a detailed discussion of the components of an SDDC network.

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

VMware Cloud on AWS services are available in many AWS regions. Service availability in each region is documented here. You have to choose a region before you can deploy an SDDC, and that choice, once made, cannot be changed. Consider the following when choosing a regions for your SDDC:
  • 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.

Note:

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

As you can see in this simplified diagram, a VMware Cloud on AWS SDDC contains two 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.
Figure 1. SDDC Network Topology

The Management Subnet

When you create the SDDC, you have to specify a CIDR block for the Management Subnet. CIDR blocks of size 16, 20, or 23 are supported, with a couple of restrictions:
  • 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).
The primary factor in choosing a Management CIDR block size is the anticipated scalability requirements of the SDDC. You can't change the Management CIDR block size after the SDDC has been deployed, so you need to think about how many hosts your SDDC will need. For example, a /23 management subnet might not support enough hosts for a long-lived SDDC that you expect to put into production use. If you expect to grow your SDDC beyond a handful of hosts or think you might want to deploy additional clusters, /20 is a better choice for the management subnet CIDR. Onboarding and Managing VMware Cloud on AWS: Part 1- Preparing to deploy an SDDC has more information about the relationship of Management CIDR block size to SDDC host capacity. And our Resource Planning page has more information about matching SDDC capacity to workload needs.

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.

See Also