EKS

Amazon Elastic Kubernetes Service (EKS) runs the Kubernetes control plane for you: a highly available, multi-Availability-Zone API server and etcd, patched and version-upgraded by AWS, billed per cluster-hour. Everything above the control plane — nodes, add-ons, workloads — is yours, unless you enable EKS Auto Mode.

For the choice between EKS and Amazon ECS, see AWS Container Services.

Compute options

EKS Auto Mode

Auto Mode extends AWS’s management past the control plane into the data plane. AWS then handles compute autoscaling (via Karpenter), node AMIs and their lifecycle, pod and service networking, network policy, application load balancing, cluster DNS, block storage and GPU support — as core cluster capabilities rather than as add-ons you install and upgrade.

Nodes under Auto Mode use immutable Bottlerocket-derived AMIs with SELinux enforcing and a read-only root filesystem, allow no SSH or SSM access, and are replaced automatically at a maximum lifetime of 21 days. It is the shortest path to a production-shaped cluster, and the right default unless you have a reason to own the data plane.

Managed node groups

AWS-managed EC2 Auto Scaling groups of worker nodes, using EKS-optimised AMIs, with node draining handled during updates.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: example-cluster
  region: eu-west-2
managedNodeGroups:
  - name: managed-ng-1
    instanceType: m7g.large
    minSize: 2
    maxSize: 5
    desiredCapacity: 3

Self-managed nodes

Your own Auto Scaling groups and AMIs. Choose this only when you need a custom AMI, an unusual kernel configuration, or hardware that managed node groups do not cover.

Fargate profiles

Pods matching a profile’s namespace and label selectors run on AWS Fargate — one micro-VM per pod, no nodes to manage.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: example-cluster
fargateProfiles:
  - name: profile-1
    selectors:
      - namespace: backend
        labels:
          env: prod

Fargate on EKS has real constraints — no DaemonSets, no privileged containers, no GPUs, no Amazon EBS volumes, no Windows or Arm workloads, private subnets only, and it is not available in every EKS Region. See ECS Fargate vs EKS Fargate for the full list.

Identity

Connect kubectl to a cluster:

aws eks update-kubeconfig --name cluster-name --region eu-west-2

Two mechanisms give a pod an AWS identity, and both are current:

• EKS Pod Identity is the newer and simpler of the two. An association maps a Kubernetes service account to an IAM role through the EKS API; there is no OIDC provider to create per cluster and no trust policy to edit when a cluster is rebuilt. It needs the EKS Pod Identity Agent, which Auto Mode installs for you. Roles are reusable across clusters.
• IAM Roles for Service Accounts (IRSA) predates it and uses an OIDC identity provider registered per cluster, with the trust relationship expressed in the role’s trust policy. It remains the option where you need the identity to work outside EKS, or where tooling assumes it.

Either way, the principle is the same: give each workload its own role rather than attaching permissions to the node role, where every pod on the node inherits them.

Cluster access itself is granted through EKS access entries mapping IAM principals to Kubernetes groups, which then bind to RBAC roles.

Networking and security

• The Amazon VPC CNI assigns pods real VPC IP addresses, so security groups and flow logs apply to them directly. Plan subnet sizing accordingly — pods consume IP addresses fast, and secondary CIDR blocks are the usual remedy.
• Kubernetes network policies restrict pod-to-pod traffic; the VPC CNI enforces them natively.
• Security groups for pods attach an EC2 security group to individual pods where a downstream resource authorises by security group.
• Put nodes and pods in private subnets and expose services through load balancers.

Scaling

Pods. The Horizontal Pod Autoscaler adjusts replica count against CPU, memory or custom metrics; the Vertical Pod Autoscaler adjusts requests and limits.

Nodes. Karpenter provisions instances directly from EC2 in response to unschedulable pods, right-sizes them to the pending workload, consolidates pods onto fewer nodes and terminates the remainder. It is what Auto Mode uses. The older Cluster Autoscaler scales Auto Scaling groups instead; if you run it, its minor version must track the cluster’s Kubernetes minor version, and it can only pick from instance types already in the node group.

Load balancing. The AWS Load Balancer Controller provisions ALBs for Ingress resources and NLBs for LoadBalancer Services, with TLS termination from AWS Certificate Manager. Auto Mode provides this without a separate controller install.

Monitoring

CloudWatch and Container Insights, or the Prometheus and Grafana stack — Amazon Managed Service for Prometheus and Amazon Managed Grafana if you would rather not run them. Fluent Bit ships container logs to CloudWatch Logs or elsewhere.

Cost

• Per-cluster charge on top of capacity, rising sharply once the cluster’s Kubernetes version enters extended support. Keeping versions current is a cost control, not just a security one.
• Spot capacity through Karpenter or a mixed-instances node group, for workloads that tolerate interruption.
• Fargate for spiky or isolated workloads, where node utilisation would otherwise be poor.
• Resource quotas and limit ranges per namespace, and cost allocation tags on everything.

EKS Anywhere

EKS Anywhere runs a Kubernetes cluster on your own on-premises infrastructure, built on the EKS Distro — the same Kubernetes distribution EKS itself uses. It gives comparable operational patterns to EKS without an AWS Region.

The important difference from ECS Anywhere: with ECS Anywhere the control plane stays in AWS and your hardware registers as capacity, so scheduling depends on connectivity to AWS. With EKS Anywhere the entire cluster, control plane included, is yours to run, place and maintain.

Practices worth adopting early

• Give pods identities through Pod Identity or IRSA, never through the node role.
• Set requests and limits on every container; unset limits are how one pod starves a node.
• Spread nodes and workloads across Availability Zones, and use pod topology spread constraints to make that stick.
• Upgrade Kubernetes versions on a schedule. Extended support is expensive and eventually ends.
• Scan images before they reach the cluster — see Amazon ECR.