Amazon EKS nodes - Amazon EKS

Amazon EKS nodes

Your Amazon EKS cluster can schedule pods on any combination of Self-managed nodes, Amazon EKS Managed node groups, and AWS Fargate. To learn more about nodes deployed in your cluster, see View Kubernetes resources.

Note

Nodes must be in the same VPC as the subnets you selected when you created the cluster. However, the nodes don't have to be in the same subnets.

The following table provides several criteria to evaluate when deciding which options best meet your requirements. This table doesn't include connected nodes that were created outside of Amazon EKS, which can only be viewed.

Note

Bottlerocket has some specific differences from the general information in this table. For more information, see the Bottlerocket documentation on GitHub.

Criteria EKS managed node groups Self managed nodes AWS Fargate

Can be deployed to AWS Outposts

No

Yes

No

Can be deployed to an AWS Local Zone

No

Yes – For more information, see Amazon EKS and AWS Local Zones.

No

Can run containers that require Windows

No

Yes – Your cluster still requires at least one (two recommended for availability) Linux node though.

No

Can run containers that require Linux

Yes

Yes

Yes

Can run workloads that require the Inferentia chip

Yes – Amazon Linux nodes only

Yes – Amazon Linux only

No

Can run workloads that require a GPU

Yes – Amazon Linux nodes only

Yes – Amazon Linux only

No

Can run workloads that require Arm processors

Yes

Yes

No

Can run AWS Bottlerocket

Yes

Yes

No

Pods share a kernel runtime environment with other pods

Yes – All of your pods on each of your nodes

Yes – All of your pods on each of your nodes

No – Each pod has a dedicated kernel

Pods share CPU, memory, storage, and network resources with other pods.

Yes – Can result in unused resources on each node

Yes – Can result in unused resources on each node

No – Each pod has dedicated resources and can be sized independently to maximize resource utilization.

Pods can use more hardware and memory than requested in pod specs

Yes – If the pod requires more resources than requested, and resources are available on the node, the pod can use additional resources.

Yes – If the pod requires more resources than requested, and resources are available on the node, the pod can use additional resources.

No – The pod can be re-deployed using a larger vCPU and memory configuration though.

Must deploy and manage Amazon EC2 instances

Yes – automated through Amazon EKS if you deployed an Amazon EKS optimized AMI. If you deployed a custom AMI, then you must update the instance manually.

Yes – Manual configuration or using Amazon EKS provided AWS CloudFormation templates to deploy Linux (x86), Linux (Arm), or Windows nodes.

No

Must secure, maintain, and patch the operating system of Amazon EC2 instances

Yes

Yes

No

Can provide bootstrap arguments at deployment of a node, such as extra kubelet arguments.

Yes – Using a launch template with a custom AMI

Yes – For more information, view the bootstrap script usage information on GitHub.

No

Can assign IP addresses to pods from a different CIDR block than the IP address assigned to the node. Yes – Using a launch template with a custom AMI Yes, using Tutorial: Custom networking. No

Can SSH into node

Yes

Yes

No – There's no node host operating system to SSH to.

Can deploy your own custom AMI to nodes

Yes – Using a launch template

Yes

No

Can deploy your own custom CNI to nodes

Yes – Using a launch template with a custom AMI

Yes

No

Must update node AMI on your own

Yes – If you deployed an Amazon EKS optimized AMI, you're notified in the Amazon EKS console when updates are available. You can perform the update with one-click in the console. If you deployed a custom AMI, you're not notified in the Amazon EKS console when updates are available. You must perform the update on your own.

Yes – Using tools other than the Amazon EKS console. This is because self managed nodes can't be managed with the Amazon EKS console.

No

Must update node Kubernetes version on your own

Yes – If you deployed an Amazon EKS optimized AMI, you're notified in the Amazon EKS console when updates are available. You can perform the update with one-click in the console. If you deployed a custom AMI, you're not notified in the Amazon EKS console when updates are available. You must perform the update on your own.

Yes – Using tools other than the Amazon EKS console. This is because self managed nodes can't be managed with the Amazon EKS console.

No – You don't manage nodes.

Can use Amazon EBS storage with pods

Yes

Yes

No

Can use Amazon EFS storage with pods

Yes

Yes

Yes

Can use Amazon FSx for Lustre storage with pods

Yes

Yes

No

Can use Network Load Balancer for services

Yes

Yes

Yes, when using the Create a network load balancer

Pods can run in a public subnet

Yes

Yes

No

Can assign different VPC security groups to individual pods

Yes – Linux nodes only

Yes – Linux nodes only

Yes

Can run Kubernetes DaemonSets

Yes

Yes

No

Support HostPort and HostNetwork in the pod manifest

Yes

Yes

No

AWS Region availability

All Amazon EKS supported regions

All Amazon EKS supported regions

Some Amazon EKS supported regions

Can run containers on EC2 dedicated hosts

No

Yes

No

Pricing

Cost of Amazon EC2 instance that runs multiple pods. For more information, see Amazon EC2 pricing.

Cost of Amazon EC2 instance that runs multiple pods. For more information, see Amazon EC2 pricing.

Cost of an individual Fargate memory and CPU configuration. Each pod has its own cost. For more information, see AWS Fargate pricing.