How Amazon EKS Makes Kubernetes on AWS Easier to Manage

What Amazon EKS manages for you

Running Kubernetes yourself means operating etcd, the API server, the scheduler and the controller manager: keeping them highly available, patched, backed up and upgraded. Amazon Elastic Kubernetes Service (Amazon EKS) takes that layer off your hands. AWS runs the Kubernetes control plane across multiple Availability Zones, replaces unhealthy control plane instances, and manages the etcd database. You get a standard, conformant Kubernetes API, so kubectl, Helm and the rest of the ecosystem work as they do anywhere else.

What stays with you depends on the compute option you choose. That choice, more than anything else, decides how much of the cluster you still operate.

Compute options: from node groups to Auto Mode

EKS gives you four ways to run Pods, and you can mix them in one cluster:

• Self-managed nodes. EC2 instances you launch and maintain yourself. Maximum control, maximum work.
• Managed node groups. EKS creates and manages the EC2 instances and their Auto Scaling group for you. When you update a node group, EKS launches new nodes, cordons and drains the old ones (honoring Pod Disruption Budgets), then terminates them. You still choose instance types and AMIs, and you still trigger updates.
• AWS Fargate. Each Pod runs in its own isolated compute environment with no nodes to see or patch. A Fargate profile selects which Pods run on Fargate by namespace and labels. Some node-level features do not apply: DaemonSets, privileged containers, GPUs and Amazon EBS volumes are not supported on Fargate.
• EKS Auto Mode. AWS also manages the data plane infrastructure. According to the EKS Auto Mode documentation, Auto Mode provisions and scales nodes using Karpenter, and includes Pod networking, network policy, load balancer integration, cluster DNS, EBS block storage and GPU support as core components rather than add-ons you install. Nodes use immutable, locked-down AMIs, have a maximum lifetime of 21 days, and are replaced automatically while respecting your Pod Disruption Budgets.

Creating an Auto Mode cluster with eksctl is one command:

eksctl create cluster --name my-cluster --enable-auto-mode

If you prefer managed node groups, you add them to an existing cluster with eksctl create nodegroup:

eksctl create nodegroup \
  --cluster my-cluster \
  --region us-east-1 \
  --name my-mng \
  --node-type m5.large \
  --nodes 3 \
  --nodes-min 2 \
  --nodes-max 4

Note that EKS does not scale a managed node group on its own. You set minimum and maximum sizes, then run an autoscaler such as Karpenter or the Kubernetes Cluster Autoscaler to adjust capacity to demand. Auto Mode is the exception because it includes that autoscaling.

Add-ons

Every cluster needs some operational software: the Amazon VPC CNI plugin, CoreDNS and kube-proxy at minimum, and often the Amazon EBS CSI driver and the EKS Pod Identity Agent. EKS add-ons let AWS package, version and update these for you, so you are not tracking compatible versions by hand.

# List add-on versions compatible with your Kubernetes version
aws eks describe-addon-versions --kubernetes-version 1.37 --addon-name coredns

# Install an add-on
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent

On Auto Mode clusters, several of these capabilities are built in, and the Pod Identity Agent does not need to be installed.

Upgrades and version support

Kubernetes releases a new minor version about three times a year, and EKS follows that cycle. The EKS version lifecycle page explains the two support phases:

• Standard support lasts 14 months from the date a version becomes available on EKS.
• Extended support follows for another 12 months, at an additional cost per cluster hour. It is enabled by default through the cluster upgrade policy; you can set the policy to standard to opt out.
• At the end of extended support, EKS automatically upgrades the control plane. Managed node groups and self-managed nodes are not upgraded with it, so plan upgrades yourself rather than waiting.

Upgrades move one minor version at a time. Before you start, check the cluster’s upgrade insights, which flag issues such as use of deprecated Kubernetes APIs. Then upgrade the control plane:

eksctl upgrade cluster --name my-cluster --version 1.37 --approve

Or with the AWS CLI:

aws eks update-cluster-version --name my-cluster --kubernetes-version 1.37

After the control plane, update your nodes, your add-ons and your client tools. EKS also lets you roll a cluster back to the previous minor version within seven days of an in-place upgrade. Pricing for both support phases is on the Amazon EKS pricing page.

Access control with access entries

Older clusters granted IAM principals access to Kubernetes through the aws-auth ConfigMap, which was easy to break and hard to audit. Access entries replace it with the EKS API. An access entry links an IAM role or user to Kubernetes permissions, either through an AWS-managed access policy or through Kubernetes groups that you bind with RBAC.

# Grant an IAM role access to the cluster
aws eks create-access-entry \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::111122223333:role/platform-admins

# Give it cluster-wide admin through an AWS-managed access policy
aws eks associate-access-policy \
  --cluster-name my-cluster \
  --principal-arn arn:aws:iam::111122223333:role/platform-admins \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster

Because access is managed through the EKS API, you can define it in AWS CloudFormation, Terraform or the AWS CDK, audit changes in AWS CloudTrail, and recover access to a cluster without going through Kubernetes. AWS recommends using IAM roles with short-term credentials rather than IAM users.

AWS permissions for Pods with EKS Pod Identity

Applications often need to call AWS services. Instead of putting access keys in Pods or relying on node instance roles, EKS Pod Identity maps an IAM role to a Kubernetes service account. The role’s trust policy allows the pods.eks.amazonaws.com service principal, and you create the association through the EKS API:

aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace default \
  --service-account my-service-account \
  --role-arn arn:aws:iam::111122223333:role/my-role

There is no annotation on the service account and no per-cluster OIDC provider to manage, which makes the same role easier to reuse across clusters. Pod Identity works for Pods on Linux EC2 nodes; for Pods on Fargate or Windows nodes, use IAM roles for service accounts (IRSA), which remains fully supported.

Choosing how much to hand over

A practical way to decide:

• Choose EKS Auto Mode if you want AWS to own node provisioning, patching and the core cluster components, and your workloads fit its managed nodes.
• Choose managed node groups if you need specific AMIs, node configuration or tooling on the nodes, and you are ready to run your own autoscaler and plan node updates.
• Choose Fargate for stateless workloads that suit one-Pod-per-environment isolation and do not need DaemonSets, EBS volumes or node access.

Whichever you pick, you still own your workloads, their security settings, network design and the timing of version upgrades.

9Acts is an AWS Advanced Tier Services Partner and AWS MSP Partner and has worked with clients on AWS since 2016. If you want help designing or upgrading EKS clusters, see our Kubernetes solutions.