Root Device Configuration in EKS Node Groups

Question

Hello
I'm looking for ways to increase disk capacity for instances deployed with EKS node groups, as the node disk size has become insufficient.

After several trials and errors, I found that when using only AWS Console or AWS CLI:
1. Create the node group with a launch template
2. In the launch template's volume settings, set the device name to /dev/xvda
3. When deploying the node group, it uses the volume configured as /dev/xvda as the root device (if using other device names, a default 20GiB volume is automatically created and becomes the fixed root device)

Is my understanding correct?
If so, would this be the best approach for dynamically managing node disk sizes? If there are better methods (more convenient and safer), I'd appreciate any guidance.

Manvitha Potluri · Accepted Answer

**Your understanding is accurate:**
--> The disk size set during EKS node group creation cannot be changed later."
--> This is true for EKS managed node groups created via AWS Console, CLI, or SDK.
Once the node group is created, there's no native support to modify the root volume size, even if you update the launch template afterward.

**Why using a Launch Template is correct:**
Using a Launch Template with /dev/xvda ensures the custom volume size is picked up during node creation. This is the only way to customize root volumes for EKS-managed node groups in a reliable, supported way.

**eksctl and Terraform, Good Moves Going Forward:**
Both tools offer better long-term manageability:
--> eksctl simplifies lifecycle management and supports volumeSize field in YAML.
```
volumeSize: 100  # Root volume size in GiB
```
-->Terraform gives you full IaC control, including managing launch templates, node groups, and lifecycle rules.

Note: (Optional): eksctl Method (100% works)

```
nodeGroups:
  - name: bigger-nodes
    instanceType: t3.large
    desiredCapacity: 2
    volumeSize: 100
```

Then run:

```
eksctl create nodegroup -f your-config.yaml
```

re:Post Agent · Answer

Your understanding is partially correct, but there are simpler approaches to manage root device disk size for EKS node groups.

When creating an EKS managed node group, you can specify the root device disk size directly using the `--disk-size` parameter in the AWS CLI or the `diskSize` field in the API. The default disk size is 20 GiB for Linux and Bottlerocket, and 50 GiB for Windows.

However, if you're using a launch template with your node group, you should not specify the disk size parameter separately, as this will cause the node group deployment to fail. Instead, you should configure the root volume size within your launch template.

For more flexibility in storage configuration, you have a few options:

1. Use the `volumeSize` parameter when creating a node group with eksctl
2. Configure `additionalVolumes` to add secondary volumes to your nodes
3. Use the AWS EBS CSI driver to mount EBS volumes directly to your pods

For example, with eksctl, you can create a node group with a larger root volume:
```
managedNodeGroups:
- name: ng-1-workers
instanceType: m5.xlarge
desiredCapacity: 10
volumeSize: 80
```

Or add additional volumes:
```
managedNodeGroups:
- name: al2-workers
amiFamily: AmazonLinux2
desiredCapacity: 2
volumeSize: 80
additionalVolumes:
- volumeName: '/dev/sdz'
volumeSize: 100
```

These approaches provide more straightforward ways to manage disk capacity for your EKS nodes than manually configuring launch templates.  
**Sources**  
[create-nodegroup — AWS CLI 2.27.41 Command Reference](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-nodegroup.html)  
[CreateNodegroup - Amazon EKS](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateNodegroup.html)  
[Additional Volume Mappings - Eksctl User Guide](https://docs.aws.amazon.com/eks/latest/eksctl/nodegroup-additional-volume-mappings.html)  
[Kubernetes Data Plane - Amazon EKS](https://docs.aws.amazon.com/eks/latest/best-practices/scale-data-plane.html)

Root Device Configuration in EKS Node Groups

Add your answer

Relevant content