Amazon EKS local cluster VPC and subnet requirements and considerations
When you create a local cluster, you specify a VPC and at least one private subnet that runs on Outposts. This topic provides an overview of the VPC and subnets requirements and considerations for your local cluster.
VPC requirements and considerations
When you create a local cluster, the VPC that you specify must meet the following requirements and considerations:
-
Make sure that the VPC has enough IP addresses for the local cluster, any nodes, and other Kubernetes resources that you want to create. If the VPC that you want to use doesn't have enough IP addresses, increase the number of available IP addresses. You can do this by associating additional Classless Inter-Domain Routing (CIDR) blocks with your VPC. You can associate private (RFC 1918) and public (non-RFC 1918) CIDR blocks to your VPC either before or after you create your cluster. It can take a cluster up to 5 hours for a CIDR block that you associated with a VPC to be recognized.
-
The VPC can't have assigned IP prefixes or IPv6 CIDR blocks. Because of these constraints, the information that's covered in Increase the amount of available IP addresses for your Amazon EC2 nodes and IPv6 addresses for clusters, Pods, and services isn't applicable to your VPC.
-
The VPC has a DNS hostname and DNS resolution enabled. Without these features, the local cluster fails to create, and you need to enable the features and recreate your cluster. For more information, see DNS attributes for your VPC in the Amazon VPC User Guide.
-
To access your local cluster over your local network, the VPC must be associated with your Outpost's local gateway route table. For more information, see VPC associations in the Amazon Outposts User Guide.
Subnet requirements and considerations
When you create the cluster, specify at least one private subnet. If you specify more than one subnet, the Kubernetes control plane instances are evenly distributed across the subnets. If more than one subnet is specified, the subnets must exist on the same Outpost. Moreover, the subnets must also have proper routes and security group permissions to communicate with each other. When you create a local cluster, the subnets that you specify must meet the following requirements:
-
The subnets are all on the same logical Outpost.
-
The subnets together have at least three available IP addresses for the Kubernetes control plane instances. If three subnets are specified, each subnet must have at least one available IP address. If two subnets are specified, each subnet must have at least two available IP addresses. If one subnet is specified, the subnet must have at least three available IP addresses.
-
The subnets have a route to the Outpost rack's local gateway to access the Kubernetes API server over your local network. If the subnets don't have a route to the Outpost rack's local gateway, you must communicate with your Kubernetes API server from within the VPC.
-
The subnets must use IP address-based naming. Amazon EC2 resource-based naming isn't supported by Amazon EKS.
Subnet access to Amazon Web Services
The local cluster's private subnets on Outposts must be able to communicate with Regional Amazon Web Services. You can achieve this by using a NAT gateway for outbound internet access or, if you want to keep all traffic private within your VPC, using interface VPC endpoints.
Using a NAT gateway
The local cluster's private subnets on Outposts must have an associated route table that has a route to a NAT gateway in a public subnet that is in the Outpost's parent Availability Zone. The public subnet must have a route to an internet gateway. The NAT gateway enables outbound internet access and prevents unsolicited inbound connections from the internet to instances on the Outpost.
Using interface VPC endpoints
If the local cluster's private subnets on Outposts don't have an outbound internet connection, or if you want to keep all traffic private within your VPC, then you must create the following interface VPC endpoints and gateway endpoint in a Regional subnet before creating your cluster.
| Endpoint | Endpoint type |
|---|---|
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Interface |
com.amazonaws. |
Gateway |
The endpoints must meet the following requirements:
-
Created in a private subnet located in your Outpost's parent Availability Zone
-
Have private DNS names enabled
-
Have an attached security group that permits inbound HTTPS traffic from the CIDR range of the private outpost subnet.
Creating endpoints incurs charges. For more information, see Amazon PrivateLink pricing
Create a VPC
You can create a VPC that meets the previous requirements using one of the following Amazon CloudFormation templates:
-
Template 1
– This template creates a VPC with one private subnet on the Outpost and one public subnet in the Amazon Web Services Region. The private subnet has a route to an internet through a NAT Gateway that resides in the public subnet in the Amazon Web Services Region. This template can be used to create a local cluster in a subnet with egress internet access. -
Template 2
– This template creates a VPC with one private subnet on the Outpost and the minimum set of VPC Endpoints required to create a local cluster in a subnet that doesn't have ingress or egress internet access (also referred to as a private subnet).