**Help improve this page**
To contribute to this user guide, choose the **Edit this page on GitHub** link that is located in the right pane of every page.
# Learn how EKS Auto Mode works
Use this chapter to learn how the components of Amazon EKS Auto Mode clusters work.
**Topics**
+ [Learn about Amazon EKS Auto Mode Managed instances](automode-learn-instances.md)
+ [Learn about identity and access in EKS Auto Mode](auto-learn-iam.md)
+ [Learn about VPC Networking and Load Balancing in EKS Auto Mode](auto-networking.md)
# Learn about Amazon EKS Auto Mode Managed instances
This topic explains how Amazon EKS Auto Mode manages Amazon EC2 instances in your EKS cluster. When you enable EKS Auto Mode, your cluster’s compute resources are automatically provisioned and managed by EKS, changing how you interact with the EC2 instances that serve as nodes in your cluster.
Understanding how Amazon EKS Auto Mode manages instances is essential for planning your workload deployment strategy and operational procedures. Unlike traditional EC2 instances or managed node groups, these instances follow a different lifecycle model where EKS assumes responsibility for many operational aspects, while restricting certain types of access and customization.
Amazon EKS Auto Mode automates routine tasks for creating new EC2 Instances, and attaches them as nodes to your EKS cluster. EKS Auto Mode detects when a workload can’t fit onto existing nodes, and creates a new EC2 Instance.
Amazon EKS Auto Mode is responsible for creating, deleting, and patching EC2 Instances. You are responsible for the containers and pods deployed on the instance.
EC2 Instances created by EKS Auto Mode are different from other EC2 Instances, they are managed instances. These managed instances are owned by EKS and are more restricted. You can’t directly access or install software on instances managed by EKS Auto Mode.
AWS suggests running either EKS Auto Mode or self-managed Karpenter. You can install both during a migration or in an advanced configuration. If you have both installed, configure your node pools so that workloads are associated with either Karpenter or EKS Auto Mode.
For more information, see [Amazon EC2 managed instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-ec2-managed-instances.html) in the Amazon EC2 user guide.
## Comparison table
| Standard EC2 Instance | EKS Auto Mode managed instance |
| --- | --- |
| You are responsible for patching and updating the instance. | AWS automatically patches and updates the instance. |
| EKS is not responsible for the software on the instance. | EKS is responsible for certain software on the instance, such as `kubelet`, the container runtime, and the operating system. |
| You can delete the EC2 Instance using the EC2 API. | EKS determines the number of instances deployed in your account. If you delete a workload, EKS will reduce the number of instances in your account. |
| You can use SSH to access the EC2 Instance. | You can deploy pods and containers to the managed instance. |
| You determine the operating system and image (AMI). | AWS determines the operating system and image. |
| You can deploy workloads that rely on Windows or Ubuntu functionality. | You can deploy containers based on Linux, but without specific OS dependencies. |
| You determine what instance type and family to launch. | AWS determines what instance type and family to launch. You can use a Node Pool to limit the instance types EKS Auto Mode selects from. |
The following functionality works for both Managed instances and Standard EC2 instances:
+ You can view the instance in the AWS console.
+ You can use instance storage as ephemeral storage for workloads.
### AMI Support
With EKS Auto Mode, AWS determines the image (AMI) used for your compute nodes. AWS monitors the rollout of new EKS Auto Mode AMI versions. If you experience workload issues related to an AMI version, create a support case. For more information, see [Creating support cases and case management](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html) in the AWS Support User Guide.
Generally, EKS releases a new AMI each week containing CVE and security fixes.
## EKS Auto Mode supported instance reference
EKS Auto Mode only creates instances of supported types, and that meet a minimum size requirement.
EKS Auto Mode supports the following instance types:
| Family | Instance Types |
| --- | --- |
| Compute Optimized © | c8id, c8i, c8i-flex, c8gd, c8gn, c8g, c8a, c8gb, c7a, c7g, c7gn, c7gd, c7i, c7i-flex, c6a, c6g, c6i, c6gn, c6id, c6in, c6gd, c5, c5a, c5d, c5ad, c5n, c4 |
| General Purpose (M) | m8id, m8i, m8i-flex, m8a, m8azn, m8gn, m8gb, m8gd, m8g, m7i, m7a, m7g, m7gd, m7i-flex, m6a, m6i, m6in, m6g, m6idn, m6id, m6gd, m5, m5a, m5ad, m5n, m5dn, m5d, m5zn, m4 |
| Memory Optimized ® | r8id, r8i, r8i-flex, r8gn, r8gb, r8gd, r8g, r8a, r7a, r7iz, r7gd, r7i, r7g, r6a, r6i, r6id, r6in, r6idn, r6g, r6gd, r5, r5n, r5a, r5dn, r5b, r5ad, r5d, r4 |
| Burstable (T) | t4g, t3, t3a, t2 |
| High Memory (Z/X) | z1d, x8aedz, x8g, x8i, x2gd |
| Storage Optimized (I/D) | i8ge, i7i, i8g, i7ie, i4g, i4i, i3, i3en, is4gen, d3, d3en, im4gn |
| Accelerated Computing (P/G/Inf/Trn) | p6-b200, p6-b300, p5, p5e, p5en, p4d, p4de, p3, p3dn, g7e, g6, gr6, g6e, g5g, g5, g4dn, g4ad, inf2, inf1, trn1, trn1n, trn2 |
| High Performance Computing (HPC/X2) | hpc8a, x2iezn, x2iedn, x2idn |
Additionally, EKS Auto Mode will only create EC2 instances that meet the following requirements:
+ More than 1 CPU
+ Instance size is not nano, micro or small
For more information, see [Amazon EC2 instance type naming conventions](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html).
## Instance Metadata Service
+ EKS Auto Mode enforces IMDSv2 with a hop limit of 1 by default, adhering to AWS security best practices.
+ This default configuration cannot be modified in Auto Mode.
+ For add-ons that typically require IMDS access, supply parameters (such as AWS region) during installation to avoid IMDS lookups. For more information, see [Determine fields you can customize for Amazon EKS add-ons](kubernetes-field-management.md).
+ If a Pod absolutely requires IMDS access when running in Auto Mode, the Pod must be configured to run with `hostNetwork: true`. This allows the Pod to access the instance metadata service directly.
+ Consider the security implications when granting Pods access to instance metadata.
For more information about the Amazon EC2 Instance Metadata Service (IMDS), see [Configure the Instance Metadata Service options](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html) in the *Amazon EC2 User Guide*.
## Considerations
+ If the configured ephemeral storage in the NodeClass is smaller than the NVMe local storage for the instance, EKS Auto Mode eliminates the need for manual configuration by automatically taking the following actions:
+ Uses a smaller (20 GiB) Amazon EBS data volume to reduce costs.
+ Formats and configures the NVMe local storage for ephemeral data use. This includes setting up a RAID 0 array if there are multiple NVMe drives.
+ When `ephemeralStorage.size` equals or exceeds the local NVMe capacity, the following actions occur:
+ Auto Mode skips the small EBS volume.
+ The NVMe drive(s) are exposed directly for your workload.
+ Amazon EKS Auto Mode does not support the following AWS Fault Injection Service actions:
+ `ec2:RebootInstances`
+ `ec2:SendSpotInstanceInterruptions`
+ `ec2:StartInstances`
+ `ec2:StopInstances`
+ `ec2:TerminateInstances`
+ `ec2:PauseVolumeIO`
+ Amazon EKS Auto Mode supports AWS Fault Injection Service EKS Pod actions. For more information, see [Managing Fault Injection Service experiments](https://docs.aws.amazon.com/resilience-hub/latest/userguide/testing.html) and [Use the AWS FIS aws:eks:pod actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html#configure-service-account) in the AWS Resilience Hub User Guide.
+ You do not need to install the `Neuron Device Plugin` on EKS Auto Mode nodes.
If you have other types of nodes in your cluster, you need to configure the Neuron Device plugin to not run on Auto Mode nodes. For more information, see [Control if a workload is deployed on EKS Auto Mode nodes](associate-workload.md).
# Learn about identity and access in EKS Auto Mode
This topic describes the Identity and Access Management (IAM) roles and permissions required to use EKS Auto Mode. EKS Auto Mode uses two primary IAM roles: a Cluster IAM Role and a Node IAM Role. These roles work in conjunction with EKS Pod Identity and EKS access entries to provide comprehensive access management for your EKS clusters.
When you configure EKS Auto Mode, you will need to set up these IAM roles with specific permissions that allow AWS services to interact with your cluster resources. This includes permissions for managing compute resources, storage volumes, load balancers, and networking components. Understanding these role configurations is essential for proper cluster operation and security.
In EKS Auto Mode, AWS IAM roles are automatically mapped to Kubernetes permissions through EKS access entries, removing the need for manual configuration of `aws-auth` ConfigMaps or custom bindings. When you create a new auto mode cluster, EKS automatically creates the corresponding Kubernetes permissions using Access entries, ensuring that AWS services and cluster components have the appropriate access levels within both the AWS and Kubernetes authorization systems. This automated integration reduces configuration complexity and helps prevent permission-related issues that commonly occur when managing EKS clusters.
## Cluster IAM role
The Cluster IAM role is an AWS Identity and Access Management (IAM) role used by Amazon EKS to manage permissions for Kubernetes clusters. This role grants Amazon EKS the necessary permissions to interact with other AWS services on behalf of your cluster, and is automatically configured with Kubernetes permissions using EKS access entries.
+ You must attach AWS IAM policies to this role.
+ EKS Auto Mode attaches Kubernetes permissions to this role automatically using EKS access entries.
+ With EKS Auto Mode, AWS suggests creating a single Cluster IAM Role per AWS account.
+ AWS suggests naming this role `AmazonEKSAutoClusterRole`.
+ This role requires permissions for multiple AWS services to manage resources including EBS volumes, Elastic Load Balancers, and EC2 instances.
+ The suggested configuration for this role includes multiple AWS managed IAM policies, related to the different capabilities of EKS Auto Mode.
+ `AmazonEKSComputePolicy`
+ `AmazonEKSBlockStoragePolicy`
+ `AmazonEKSLoadBalancingPolicy`
+ `AmazonEKSNetworkingPolicy`
+ `AmazonEKSClusterPolicy`
For more information about the Cluster IAM Role and AWS managed IAM policies, see:
+ [AWS managed policies for Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Amazon EKS cluster IAM role](cluster-iam-role.md)
For more information about Kubernetes access, see:
+ [Review access policy permissions](access-policy-permissions.md)
## Node IAM role
The Node IAM role is an AWS Identity and Access Management (IAM) role used by Amazon EKS to manage permissions for worker nodes in Kubernetes clusters. This role grants EC2 instances running as Kubernetes nodes the necessary permissions to interact with AWS services and resources, and is automatically configured with Kubernetes RBAC permissions using EKS access entries.
+ You must attach AWS IAM policies to this role.
+ EKS Auto Mode attaches Kubernetes RBAC permissions to this role automatically using EKS access entries.
+ AWS suggests naming this role `AmazonEKSAutoNodeRole`.
+ With EKS Auto Mode, AWS suggests creating a single Node IAM Role per AWS account.
+ This role has limited permissions. The key permissions include assuming a Pod Identity Role, and pulling images from ECR.
+ AWS suggests the following AWS managed IAM policies:
+ `AmazonEKSWorkerNodeMinimalPolicy`
+ `AmazonEC2ContainerRegistryPullOnly`
For more information about the Cluster IAM Role and AWS managed IAM policies, see:
+ [AWS managed policies for Amazon Elastic Kubernetes Service](security-iam-awsmanpol.md)
+ [Amazon EKS node IAM role](create-node-role.md)
For more information about Kubernetes access, see:
+ [Review access policy permissions](access-policy-permissions.md)
## Service-linked role
Amazon EKS uses a service-linked role (SLR) for certain operations. A service-linked role is a unique type of IAM role that is linked directly to Amazon EKS. Service-linked roles are predefined by Amazon EKS and include all the permissions that the service requires to call other AWS services on your behalf.
AWS automatically creates and configures the SLR. You can delete an SLR only after first deleting their related resources. This protects your Amazon EKS resources because you can’t inadvertently remove permission to access the resources.
The SLR policy grants Amazon EKS permissions to observe and delete core infrastructure components: EC2 resources (instances, network interfaces, security groups), ELB resources (load balancers, target groups), CloudWatch capabilities (logging and metrics), and IAM roles with "eks" prefix. It also enables private endpoint networking through VPC/hosted zone association and includes permissions for EventBridge monitoring and cleanup of EKS-tagged resources.
For more information, see:
+ [AWS managed policy: AmazonEKSServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy)
+ [Service-linked role permissions for Amazon EKS](using-service-linked-roles-eks.md#service-linked-role-permissions-eks)
## Access Policy Reference
For more information about the Kubernetes permissions used by EKS Auto Mode, see [Review access policy permissions](access-policy-permissions.md).
# Learn about VPC Networking and Load Balancing in EKS Auto Mode
This topic explains how to configure Virtual Private Cloud (VPC) networking and load balancing features in EKS Auto Mode. While EKS Auto Mode manages most networking components automatically, you can still customize certain aspects of your cluster’s networking configuration through `NodeClass` resources and load balancer annotations.
When you use EKS Auto Mode, AWS manages the VPC Container Network Interface (CNI) configuration and load balancer provisioning for your cluster. You can influence networking behaviors by defining `NodeClass` objects and applying specific annotations to your Service and Ingress resources, while maintaining the automated operational model that EKS Auto Mode provides.
## Networking capability
EKS Auto Mode has a new networking capability that handles node and pod networking. You can configure it by creating a `NodeClass` Kubernetes object.
Configuration options for the previous AWS VPC CNI will not apply to EKS Auto Mode.
### Configure networking with a `NodeClass`
The `NodeClass` resource in EKS Auto Mode allows you to customize certain aspects of the networking capability. Through `NodeClass`, you can specify security group selections, control node placement across VPC subnets, set SNAT policies, configure network policies, and enable network event logging. This approach maintains the automated operational model of EKS Auto Mode while providing flexibility for network customization.
You can use a `NodeClass` to:
+ Select a Security Group for Nodes
+ Control how nodes are placed on VPC Subnets
+ Set the Node SNAT Policy to `random` or `disabled`
+ Enable Kubernetes *network policies* including:
+ Set the Network Policy to Default Deny or Default Allow
+ Enable Network Event Logging to a file.
+ Isolate pod traffic from the node traffic by attaching pods to different subnets.
Learn how to [Create an Amazon EKS NodeClass](create-node-class.md).
### Considerations
EKS Auto Mode supports:
+ EKS Network Policies.
+ The `HostPort` and `HostNetwork` options for Kubernetes Pods.
+ Nodes and Pods in public or private subnets.
+ Caching DNS queries on the node.
EKS Auto Mode does **not** support:
+ Security Groups per Pod (SGPP). To apply separate security groups to Pod traffic in Auto Mode, use `podSecurityGroupSelectorTerms` in the `NodeClass` instead. For more information, see [Separate subnets and security groups for Pods](create-node-class.md#pod-subnet-selector).
+ Custom Networking in the `ENIConfig`. You can put pods in multiple subnets or exclusively isolate them from the node traffic with [Separate subnets and security groups for Pods](create-node-class.md#pod-subnet-selector).
+ Warm IP, warm prefix, and warm ENI configurations.
+ Minimum IP targets configuration.
+ Other configurations supported by the open source AWS VPC CNI.
+ Network Policy configurations such as conntrack timer customization (default is 300s).
+ Exporting network event logs to CloudWatch.
### Network Resource Management
EKS Auto Mode handles prefix, IP addressing, and network interface management by monitoring NodeClass resources for networking configurations. The service performs several key operations automatically:
**Prefix Delegation**
EKS Auto Mode defaults to using prefix delegation (/28 prefixes) for pod networking and maintains a predefined warm pool of IP resources that scales based on the number of scheduled pods. When pod subnet fragmentation is detected, Auto Mode provisions secondary IP addresses (/32). Due to this default pod networking algorithm, Auto Mode calculates max pods per node based on the number of ENIs and IPs supported per instance type (assuming the worst case of fragmentation). For more information about Max ENIs and IPs per instance type, see [Maximum IP addresses per network interface](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AvailableIpPerENI.html) in the EC2 User Guide. Newer generation (Nitro v6 and above) instance families generally have increased ENIs and IPs per instance type, and Auto Mode adjusts the max pods calculation accordingly.
For IPv6 clusters, only prefix delegation is used, and Auto Mode always uses a max pods limit of 110 pods per node.
**Cooldown Management**
The service implements a cooldown pool for prefixes or secondary IPv4 addresses that are no longer in use. After the cooldown period expires, these resources are released back to the VPC. However, if pods reuse these resources during the cooldown period, they are restored from the cooldown pool.
**IPv6 Support**
For IPv6 clusters, EKS Auto Mode provisions a `/80` IPv6 prefix per node on the primary network interface. When using `podSubnetSelectorTerms`, the prefix is allocated on a secondary network interface in the pod subnet instead.
The service also ensures proper management and garbage collection of all network interfaces.
## Load balancing
You configure AWS Elastic Load Balancers provisioned by EKS Auto Mode using annotations on Service and Ingress resources.
For more information, see [Create an IngressClass to configure an Application Load Balancer](auto-configure-alb.md) or [Use Service Annotations to configure Network Load Balancers](auto-configure-nlb.md).
### Considerations for load balancing with EKS Auto Mode
+ The default targeting mode is IP Mode, not Instance Mode.
+ EKS Auto Mode only supports Security Group Mode for Network Load Balancers.
+ AWS does not support migrating load balancers from the self managed AWS load balancer controller to management by EKS Auto Mode.
+ The `networking.ingress.ipBlock` field in `TargetGroupBinding` spec is not supported.
+ If your worker nodes use custom security groups (not `eks-cluster-sg- ` naming pattern), your cluster role needs additional IAM permissions. The default EKS-managed policy only allows EKS to modify security groups named `eks-cluster-sg-`. Without permission to modify your custom security groups, EKS cannot add the required ingress rules that allow ALB/NLB traffic to reach your pods.
#### CoreDNS considerations
EKS Auto Mode does not use the traditional CoreDNS deployment to provide DNS resolution within the cluster. Instead, Auto Mode nodes utilize CoreDNS running as a system service directly on each node. If transitioning a traditional cluster to Auto Mode, you can remove the CoreDNS deployment from your cluster once your workloads have been moved to the Auto Mode nodes.
**Important**
If you plan to maintain a cluster with both Auto Mode and non-Auto Mode nodes, you must retain the CoreDNS deployment. Non-Auto Mode nodes rely on the traditional CoreDNS pods for DNS resolution, as they cannot access the node-level DNS service that Auto Mode provides.