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.
Amazon EKS Node Classes provide granular control over the configuration of your EKS Auto Mode managed nodes. A Node Class defines infrastructure-level settings that apply to groups of nodes in your EKS cluster, including network configuration, storage settings, and resource tagging. This topic explains how to create and configure a Node Class to meet your specific operational requirements.
When you need to customize how EKS Auto Mode provisions and configures EC2 instances beyond the default settings, creating a Node Class gives you precise control over critical infrastructure parameters. For example, you can specify private subnet placement for enhanced security, configure instance ephemeral storage for performance-sensitive workloads, or apply custom tagging for cost allocation.
Create a Node Class
To create a Node Class, follow these steps:
-
Create a YAML file (for example,
nodeclass.yaml
) with your Node Class configuration -
Apply the configuration to your cluster using
kubectl
-
Reference the Node Class in your Node Pool configuration. For more information, see Create a Node Pool for EKS Auto Mode.
You need kubectl
installed and configured. For more information, see Set up to use Amazon EKS.
Basic Node Class Example
Here’s an example Node Class:
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
ephemeralStorage:
size: "160Gi"
This NodeClass increases the amount of ephemeral storage on the node.
Apply this configuration using:
kubectl apply -f nodeclass.yaml
Next, reference the Node Class in your Node Pool configuration. For more information, see Create a Node Pool for EKS Auto Mode.
Create node class access entry
If you create a custom node class, you need to create an EKS Access Entry to permit the nodes to join the cluster. EKS automatically creates access entries when you use the built-in node class and node pools.
For information about how Access Entries work, see Grant IAM users access to Kubernetes with EKS access entries.
When creating access entries for EKS Auto Mode node classes, you need to use the EC2
access entry type.
Create access entry with CLI
To create an access entry for EC2 nodes and associate the EKS Auto Node Policy:
Update the following CLI commands with your cluster name, and node role ARN. The node role ARN is specified in the node class YAML.
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name <cluster-name> \
--principal-arn <node-role-arn> \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name <cluster-name> \
--principal-arn <node-role-arn> \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
Create access entry with CloudFormation
To create an access entry for EC2 nodes and associate the EKS Auto Node Policy:
Update the following CloudFormation with your cluster name, and node role ARN. The node role ARN is specified in the node class YAML.
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName: <cluster-name>
PrincipalArn: <node-role-arn>
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ <cluster-name> ] # previously defined in CloudFormation
For information about deploying CloudFormation stacks, see Getting started with CloudFormation
Node Class Specification
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: MyNodeClass
spec:
# Required: Subnet selection for node placement
subnetSelectorTerms:
- tags:
Name: "<tag-name>"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
# Required: Security group selection for nodes
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-node-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-node-security-group"
# Optional: Configure SNAT policy (defaults to Random)
snatPolicy: Random # or Disabled
# Optional: Network policy configuration (defaults to DefaultAllow)
networkPolicy: DefaultAllow # or DefaultDeny
# Optional: Network policy event logging (defaults to Disabled)
networkPolicyEventLogs: Disabled # or Enabled
# Optional: Configure ephemeral storage (shown with default values)
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional: Name of IAM role to use for EC2 instance role
# If unspecified, EKS creates a role
# If specified, you must create an access entry for this role as described above
role: MyNodeRole
# Optional: Additional EC2 tags
tags:
Environment: "production"
Team: "platform"
Considerations:
-
If you change the Node IAM Role associated with a NodeClass, you will need to create a new Access Entry. EKS automatically creates an Access Entry for the Node IAM Role during cluster creation. The Node IAM Role requires the
AmazonEKSAutoNodePolicy
EKS Access Policy. For more information, see Grant IAM users access to Kubernetes with EKS access entries. -
EKS limits the maximum number of pods on a node to 110. This limit is applied after the existing max pods calculation. For more information, see Choose an optimal Amazon EC2 node instance type.
-
If you want to propagate tags from Kubernetes to EC2, you need to configure additional IAM permissions. For more information, see Learn about identity and access in EKS Auto Mode.
-
Do not name your custom node class
default
.