EKS.

Where EKS fits on a long engagement.

The word "managed" does less work here than teams expect. AWS runs the control plane and keeps it available; node groups, CNI configuration, IAM integration, add-on versions, upgrades and cost are all still yours. EKS removes one hard problem and leaves several.

The upgrade cadence is the standing obligation. Kubernetes versions have a supported window measured in months, and a cluster that falls out of it either pays for extended support or runs unsupported. Upgrades touch the control plane, the nodes and every add-on, which is why a cluster nobody has upgraded in a year is a project rather than a task.

What an assigned team does with EKS.

Kubernetes rewards teams who operate it continuously and punishes those who treat it as set-and-forget. The upgrade cadence alone means there is no steady state in which nothing needs doing.

That is why cluster ownership is scoped as standing capacity rather than an initial build, agreed as a committed monthly capacity across the platform discipline.

What we use EKS for.

• Upgrades absorbed on cadence Control plane, nodes and add-ons moved each cycle rather than accumulating into a migration.
• IAM integrated with workloads Pod-level AWS permissions through service accounts, rather than shared node credentials.
• Node strategy matched to the workload Managed groups, spot capacity or Fargate chosen against real usage rather than by default.

How EKS capacity is assigned.

Cluster capacity is assigned under devops as a service, with the upgrade cadence treated as recurring scope rather than raised when support lapses.