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 learn more about nodes deployed in your cluster, see View nodes.

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 – 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

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 CNI 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, 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.