Help improve this page
Want to contribute to this user guide? Scroll to the bottom of this page and select Edit this page on GitHub. Your contributions will help make our user guide better for everyone.
Create a VPC and subnets for Amazon EKS clusters on AWS Outposts
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 Assign more IP addresses to Amazon EKS nodes with prefixes and Assign IPv6 addresses to 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 AWS 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 AWS services
The local cluster’s private subnets on Outposts must be able to communicate with Regional AWS 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 |
---|---|
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
Interface |
|
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 AWS PrivateLink pricing
Create a VPC
You can create a VPC that meets the previous requirements using one of the following AWS CloudFormation templates:
-
Template 1
– This template creates a VPC with one private subnet on the Outpost and one public subnet in the AWS Region. The private subnet has a route to an internet through a NAT Gateway that resides in the public subnet in the AWS 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).