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. The following table provides several criteria to evaluate when deciding which options best meet your requirements. We recommend reviewing this page often because the data in this table changes frequently as new capabilities are introduced to Amazon EKS. To view details about any existing nodes deployed in your cluster, see View nodes.

Criteria EKS managed node groups Self-managed nodes AWS Fargate

Can be deployed to AWS Outposts

No

Yes – For more information, see Amazon EKS on AWS Outposts.

No

Can be deployed to AWS Local Zones

No

Yes – For more information, see Amazon EKS on 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

No

Yes

No – There is no node.

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 – There is no node.

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 CNI custom networking. No – There is no node.

Can SSH into node

Yes

Yes

No – There is no node host operating system to SSH to.

Can deploy your own custom AMI to nodes

Yes – Using a launch template

Yes

No – You don't manage nodes.

Can deploy your own custom CNI to nodes

Yes – Using a launch template with a custom AMI

Yes

No – You don't manage nodes.

Must update node AMI yourself

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

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

No – You don't manage nodes.

Must update node Kubernetes version yourself

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

Yes – Using tools other than the Amazon EKS console, 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, in 1.18 or later clusters

Can run Kubernetes DaemonSets

Yes

Yes

No

Support HostPort and HostNetwork in the pod manifest

Yes

Yes

No

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.