---
title: "EKS | Skills We Assign For | Azendo"
description: "EKS for managed Kubernetes on AWS — what is actually managed, upgrade cadence, and the Azendo roles assigned for it."
url: "https://azendo.co/skills/eks/"
---

[Skills](https://azendo.co/skills/) Cloud and infrastructure 

# EKS.

EKS is AWS's managed Kubernetes service. AWS runs the control plane; the cluster operator remains responsible for node groups, networking, add-ons, upgrades and everything running on top.

## 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](https://azendo.co/pricing/) 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](https://azendo.co/services/cloud-and-devops/), with the upgrade cadence treated as recurring scope rather than raised when support lapses.

## Roles we assign EKS for

* [Cloud Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/cloud-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in cloud and infrastructure

* [Kubernetes — skill we assign for](https://azendo.co/skills/kubernetes/)
* [Docker — skill we assign for](https://azendo.co/skills/docker/)
* [Terraform — skill we assign for](https://azendo.co/skills/terraform/)
* [AWS — skill we assign for](https://azendo.co/skills/aws/)
* [Azure — skill we assign for](https://azendo.co/skills/azure/)
* [GCP — skill we assign for](https://azendo.co/skills/gcp/)
* [Terraform modules — skill we assign for](https://azendo.co/skills/terraform-modules/)
* [Pulumi — skill we assign for](https://azendo.co/skills/pulumi/)

## Tell us what your roadmap needs EKS for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)