Amazon EKS

The problem it solves

Kubernetes is made of two parts: the control plane, that is the API server, the scheduler, the controllers and the etcd database that holds the state of the cluster, and the nodes, the machines where the containers run. Installing a control plane takes an afternoon. Keeping a cluster highly available is a project in its own right: redundancy, backups, certificates and version upgrades all have to be taken care of.

A managed Kubernetes service such as Amazon EKS takes charge of the control plane. AWS runs it across several Availability Zones, upgrades it, backs its availability with an SLA and exposes it as a service. The resulting cluster is certified Kubernetes: the same manifests, the same tools, the same operators that run anywhere else.

It is not necessarily the right fit for everyone. A small team with a handful of services and no Kubernetes experience may be better served by Amazon ECS, which has no control plane cost and does not impose the pace of upgrades, or by Lambda functions. EKS makes sense when the team already knows Kubernetes or wants to learn it, when the ecosystem around it (operators, GitOps, Helm) is part of the project, or when a degree of portability or interoperability towards other clouds or the datacenter matters.

Shared responsibility

In the standard model AWS manages the API server, etcd and the network interfaces that connect the control plane to your VPC. Everything else stays with the operator: the EC2 nodes and their operating system, the networking and storage components installed in the cluster (the add-ons), the VPC with its subnets, the mapping between IAM identities and Kubernetes permissions, and above all the node upgrades, which do not follow the control plane on their own. It is a more lopsided split than the word "managed" suggests, and the established way to handle it is to run the nodes in managed node groups.

Since December 2024 AWS also offers EKS Auto Mode, and it is the path it pushes for new clusters. In this mode AWS takes over the nodes as well, from the operating system to the patches. The nodes are EC2 instances that AWS treats as cattle: an immutable Bottlerocket operating system, no SSH access, automatic replacement within 21 days of creation.

Fargate, the serverless mode, runs each pod in a dedicated micro-VM, with no nodes to see or manage explicitly. It has hard limits: no DaemonSets, no GPUs, no privileged containers, private subnets only. It remains an option for specific cases, and AWS is pushing Auto Mode as its replacement.

	Managed node groups	EKS Auto Mode	Fargate
Who manages the nodes	The operator	AWS	No nodes: one pod per micro-VM
Node upgrades	Started by the operator	Automatic, within 21 days	When the pod restarts
What you pay	EC2	EC2 plus a management fee	vCPU and memory of the pod
Limits	The operational work	No access to the nodes	No DaemonSets, GPUs, privileged containers

How it works

The default network plugin, VPC CNI, gives every pod an address from the VPC. It is a choice that simplifies security groups and debugging, and one that uses up addresses fast: plan for it when sizing the subnets. A Service or an Ingress becomes a Network or an Application Load Balancer, each with its own cost. Since October 2026 Auto Mode also supports the Gateway API.

Identities travel on two separate tracks. Whoever administers the cluster signs in with their own IAM credentials, mapped to Kubernetes roles through access entries. Pods that need to call AWS services receive an IAM role through EKS Pod Identity, with no keys stored in the cluster. Storage is EBS for block volumes and EFS for shared file systems, through their respective CSI drivers.

Version upgrades

The community releases a Kubernetes minor version roughly every four months, and EKS follows upstream. Each new version gets 14 months of standard support, followed by 12 months of extended support (at an extra charge). At the end of the 26 months AWS upgrades the control plane on its own, without notice, and leaves nodes and add-ons where they are. Staying within standard support therefore means about three upgrades a year.

Most of the work is in the nodes and the add-ons. Every control plane upgrade has to be followed by the upgrade of the node groups, the VPC CNI, CoreDNS, kube-proxy and the CSI drivers, and preceded by a check that the manifests use no removed APIs. EKS helps with upgrade insights, which flag deprecated APIs in use and block the upgrade when they find problems, and since July 2026 an upgrade can be rolled back within seven days. With Auto Mode the nodes follow the control plane on their own, honouring Pod Disruption Budgets.

When estimating the cost of an EKS cluster, pay close attention to the ancillary services that inflate the base price: NAT Gateways, traffic between Availability Zones, one load balancer for every exposed Service, logs in CloudWatch. On a small cluster they weigh more than the base fee for the control plane.

AWS in Italy

AWS has had a region in Milan since 2020 (eu-south-1), with three Availability Zones, and EKS is available there. For anyone with data residency constraints the Milan region can be a good fit, with one caveat: smaller regions receive new instance types and the latest services a few months after Frankfurt or Ireland, so check case by case.

Adoption

In EKS adoption projects I usually follow these steps:

1. Account and network before the cluster. Account structure with AWS Organizations, user access control through SSO, VPC design with properly sized subnets, private and protected access to the API server. Reworking these components later risks becoming impractical.
2. Everything in Terraform (or another Infrastructure as Code tool), cluster included, with no exceptions for things "done only once".
3. Managed node groups, with Bottlerocket or Amazon Linux 2023 images. Auto Mode I assess case by case.
4. GitOps releases and observability from day one, and not when the first incident makes them urgent.
5. An upgrade calendar, with an owner and a window every four months.

EKS or GKE?

The two services look very much alike. Google Kubernetes Engine upgrades control plane and nodes on its own according to a release channel, while on EKS the upgrade is started by the operator or handed to Auto Mode. GKE Autopilot bills the resources requested by the pods, EKS Auto Mode bills the EC2 instances plus a management fee. Identity on GKE rests directly on Google IAM, on EKS it goes through an explicit mapping. The choice is usually made by looking at the rest of the infrastructure and at the long-term goals.

Maturity

I have worked on AWS and on EKS for years, as a cloud architect and as a Kubernetes consultant, and I consider it the default choice for anyone who has already decided to be on AWS and needs Kubernetes. The service is mature, and the operational work on the nodes, which once weighed on small teams, now comes down to a few initial decisions and a calendar that is kept. The delicate point is still the first one: understanding whether Kubernetes is needed at all. I cover this, and how to set up the AWS infrastructure around the cluster, on the cloud consulting and Kubernetes consulting pages.