AWS PCS VPC and subnet requirements and considerations - AWS PCS

AWS PCS VPC and subnet requirements and considerations

When you create an AWS PCS cluster, you specify a VPC a subnet in that VPC. This topic provides an overview of AWS PCS specific requirements and considerations for the VPC and subnet(s) that you use with your cluster. If you don't have a VPC to use with AWS PCS, you can create one using an AWS-provided AWS CloudFormation template. For more information about VPCs, see Virtual private clouds (VPC) in the Amazon VPC User Guide.

VPC requirements and considerations

When you create a cluster, the VPC that you specify must meet the following requirements and considerations:

Important

AWS PCS doesn't support a VPC with dedicated instance tenancy. The VPC you use for AWS PCS must use default instance tenancy. You can change the instance tenancy for an existing VPC. For more information, see Change the instance tenancy of a VPC in the Amazon Elastic Compute Cloud User Guide.

Subnet requirements and considerations

When you create a Slurm cluster, AWS PCS creates an Elastic Network Interface(ENI) in the subnet you specified. This network interface enables communication between the scheduler controller and the customer VPC. The network interface also enables Slurm to communicate with the components deployed in your account. You can only specify the subnet for a cluster at creation time.

Subnet requirements for clusters

The subnet that you specify when you create a cluster must meet the following requirements:

  • The subnet must have at least 1 IP address for use by AWS PCS.

  • If your cluster uses IPv6, all of the subnets in your cluster must use IPv6.

Important

Compute node groups configured with AWS PCS sample AMIs and multiple network interfaces won't work currently if the subnets are only configured to use IPv6. Use dual-stack subnets (IPv4 and IPv6) or IPv4-only subnets instead. For more information, see Using sample Amazon Machine Images (AMIs) with AWS PCS.

  • The subnet can't reside in AWS Outposts, AWS Wavelength, or an AWS Local Zone.

  • The subnet can be a public or private. We recommend that you specify a private subnet, if possible. A public subnet is a subnet with a route table that includes a route to an internet gateway; a private subnet is a subnet with a route table that doesn't include a route to an internet gateway.

Subnet requirements for nodes

You can deploy nodes and other cluster resources to the subnet you specify when you create your AWS PCS cluster, and to other subnets in the same VPC.

Any subnet that you deploy nodes and cluster resources to must meet the following requirements:

  • You must ensure that the subnet has enough available IP addresses to deploy all the nodes and cluster resources.

  • If your cluster uses IPv4 and you plan to deploy nodes to a public subnet, that subnet must auto-assign IPv4 public addresses.

    Note

    Instances in a public subnet must use a security group with inbound rules that permit traffic from public IP addresses. Unless you have specific source address restrictions, this means an IPv4 source address of 0.0.0.0/0 or an IPv6 source address of ::/0.

  • If the subnet where you deploy nodes to is a private subnet and its route table doesn't include a route to a network address translation (NAT) device (IPv4), add VPC endpoints using AWS PrivateLink to the customer VPC. VPC endpoints are needed for all the AWS services that the nodes contact. The only required endpoint is for AWS PCS to allow the node to call the RegisterComputeNodeGroupInstance API action. For more information, see RegisterComputeNodeGroupInstance in the AWS PCS API Reference.

  • Public or private subnet status doesn't impact AWS PCS; the required endpoints must be reachable.