Introduction

On AWS, the usual way to add nodes to a Kubernetes cluster is to add a new Amazon EKS node group or scale an existing one. If you are using EKS, managed node groups are the simplest path because AWS handles the underlying Auto Scaling group and node lifecycle for you.

The recommended path: add a managed node group

For an existing EKS cluster, a managed node group is the cleanest way to add capacity. Before creating one, make sure:

• the cluster is in ACTIVE state,
• the worker-node IAM role exists,
• the subnets are correct,
• and your local kubectl access is working.

A typical eksctl command looks like this:

1eksctl create nodegroup \
2  --cluster=my-cluster \
3  --name=workers-a \
4  --managed \
5  --node-type=t3.large \
6  --nodes=3 \
7  --nodes-min=2 \
8  --nodes-max=6

This adds a new managed node group with three initial worker nodes and a scaling range from two to six.

Verify that the new nodes joined the cluster

After the node group is created, check Kubernetes directly:

kubectl get nodes --watch

You want to see the new nodes appear and reach Ready state. If they do not join, the problem is usually in IAM permissions, subnet routing, security groups, or bootstrap configuration.

You can also inspect the EKS side:

aws eks describe-nodegroup \
  --cluster-name my-cluster \
  --nodegroup-name workers-a

That helps distinguish "AWS did not create the instances" from "the instances exist but failed to register as Kubernetes nodes."

When to scale an existing node group instead

If the existing node group already has the right instance type and labels, you may not need a new group at all. You can just increase its desired size.

With eksctl:

1eksctl scale nodegroup \
2  --cluster=my-cluster \
3  --name=workers-a \
4  --nodes=5

This is useful when you only need more of the same worker configuration.

Why separate node groups are often useful

Adding a new node group is better than scaling one large group when you need different scheduling behavior. Examples include:

• GPU workloads,
• spot instances,
• memory-heavy services,
• or nodes dedicated to one Availability Zone.

Separate node groups let you apply different labels, taints, and instance types. That gives the scheduler better control and makes cluster operations easier.

Self-managed nodes are still possible

If you are not using EKS managed node groups, you can still add EC2 instances manually and join them to the cluster. In a self-managed setup, you are responsible for the bootstrap process, the AMI, the Auto Scaling group, and the worker-node join configuration.

For kubeadm-style clusters, that often means launching an instance and running a join command similar to:

kubeadm join CONTROL_PLANE_IP:6443 \
  --token TOKEN_VALUE \
  --discovery-token-ca-cert-hash sha256:HASH_VALUE

That path is more flexible, but it is also more operationally expensive than a managed node group.

Common Pitfalls

The most common mistake is treating node creation as only an EC2 problem. A new instance is not a usable Kubernetes node unless IAM, cluster bootstrap, networking, and node registration are all correct.

Another frequent issue is using the wrong subnets or security groups. The instances may launch successfully but fail to communicate with the cluster API or other cluster components.

Be careful with workload placement too. If you add new nodes but your Pods use strict selectors, taints, or topology rules, the cluster may remain under-scheduled even though more compute exists.

Finally, think about node groups as an architecture choice, not just a scaling button. Separate groups for spot, GPU, or zone-specific workloads often make the cluster more predictable and easier to operate.

Summary

• On AWS EKS, the normal way to add nodes is to add or scale a managed node group.
• 'eksctl create nodegroup is a straightforward way to create new worker capacity.'
• Always verify new nodes with kubectl get nodes --watch.
• Use separate node groups when workloads need different instance types, labels, or scheduling rules.
• Self-managed nodes are possible, but they require more manual bootstrap and operational work.