Managed Kubernetes Services: What Is Still Yours on EKS?

Managed Kubernetes services all sell the same word, and on EKS it means one thing: AWS runs the API server and etcd. It does not mean anyone is upgrading your nodes, and it does not mean the audit log exists. Most of the clusters we take over were "managed" for two years and upgraded once, by AWS, without anyone being told.

The bill notices before the auditor does. A version leaves standard support 14 months after EKS ships it, and from that morning the cluster costs six times as much. By default. Nobody decides it.

Our position: on EKS, everything a regulator will ask about is still yours. The version, the nodes, the audit log and who can reach the API. A provider is worth paying for only when they take exactly those four things off you and can show the evidence every month.

What does "managed" actually cover on EKS?

AWS draws the line itself. The EKS security best practices guide says AWS is responsible for "the Kubernetes control plane nodes, the ETCD database, and other infrastructure necessary for AWS to deliver a secure and reliable service", and that you are "largely responsible" for "IAM, pod security, runtime security, network security, and so forth".

So the managed part is the components you would never log into anyway. The kubelet, the CNI, CoreDNS, the ingress controller, the minor version and every RBAC binding are yours. How a provider gets in is the argument in the post on how an AWS managed service provider should get into your account; this one is about what they do once inside.

Why is your cluster on extended support, and who chose that?

Nobody chose it. The EKS version lifecycle page gives each minor version 14 months of standard support, after which it "enters extended support for the next 12 months", and states plainly: "Extended support is enabled by default." The pricing page puts the cluster fee at $0.10 per hour in standard support and "$0.60 per cluster per hour" after. That is about $73 a month becoming about $438, per cluster. Dev, staging and production is $1,095 a month more for clusters that have not changed.

The dates are on the same page. Version 1.33 aged out on 29 July 2026, so a cluster built in mid-2025 on the then-current version has been on the higher rate for eight weeks. Version 1.31 reaches the end of the road on 26 November 2026, after which "existing control planes are automatically updated by Amazon EKS to the earliest supported version", and warns: "You won't receive any notification before the update." The auto-upgrade "includes only the Kubernetes control plane"; the nodes "will remain on the previous version".

The compliance reading is not about the money. The RBI Cybersecurity Directions 2026 require middle layer and larger NBFCs, at paragraph 92, to "avoid using outdated and unsupported hardware or software" and to "monitor software end-of-support (EOS) dates"; paragraph 93 wants "a technology refresh plan" that replaces software "before they reach EOS". Whether the extended rate counts as unsupported is for your compliance team. Whether the EOS date is written down anywhere is not. The rest of the direction is in the post on the 2026 direction.

Who upgrades the nodes when AWS upgrades the control plane?

You do, and it is the half that breaks things. The lifecycle page's FAQ is direct: "Are Amazon EKS managed node groups automatically updated along with the cluster control plane version? No." Self-managed nodes get the same answer. We have inherited clusters where the top had been auto-upgraded twice and every node was still where the consultancy left it.

An upgrade is three times a year, per cluster, and each one is the same work: read the release notes, run a deprecation check against every manifest and chart, upgrade the VPC CNI, kube-proxy and CoreDNS add-ons in order, roll the nodes, and keep the rollback plan to hand, which the lifecycle page limits to "within 7 days of the upgrade completing". A provider who cannot show you the change record for the last one is not doing it.

EKS Auto Mode is AWS offering to do that half too. The Auto Mode page says it "keeps your Kubernetes cluster, nodes, and related components up to date with the latest patches", that nodes "have a maximum lifetime of 21 days", and that the AMIs prevent "direct access to the nodes by disallowing SSH or SSM access". That last line removes the whole class of problem in the SSM Agent CVE post: there is no agent to be out of date.

Where is the Kubernetes audit log, and is it in India?

Off, unless someone turned it on. The control plane logging page: "By default, cluster control plane logs aren't sent to CloudWatch Logs. You must enable each log type individually." Two of the five types matter to an auditor: the audit log, "a record of the individual users, administrators, or system components that have affected your cluster", and the authenticator log, which records which IAM identity became which Kubernetes user. CloudTrail does not have this. It records the call that fetched a token; what the token then did is only in the audit log.

CERT-In's 2022 directions, paragraph (iv), require every body corporate to "mandatorily enable logs of all their ICT systems and maintain them securely for a rolling period of 180 days and the same shall be maintained within the Indian jurisdiction". A cluster in ap-south-1 delivers to CloudWatch in ap-south-1, so residency comes free. The 180 days is a retention setting somebody has to set, and the cheap copy belongs in S3, like the other log lines in the post on reducing a fintech's AWS bill. And the six-hour clock in the incident reporting post cannot be met on a cluster with no audit log.

Who can reach the API server, and from where?

The internet, by default. The cluster endpoint page: "By default, this API server endpoint is public to the internet", secured by IAM and RBAC. Fine for a dev cluster. For the one running payments, the endpoint is private, or at least the public access CIDRs are your office and your CI runners and nothing else.

Then who. The access entries page has the detail that matters: for older clusters, EKS creates an entry that "includes the IAM identity that originally created the cluster and the administrative permissions granted to that identity during cluster creation". Whoever ran the create command in 2024 has been cluster-admin since, usually a consultancy engineer or an IAM user whose key sits in a CI secret. Until you list the entries, you are guessing.

What should managed Kubernetes services actually take off your hands?

The four things above, as a monthly report you can check without them present. Ours:

• Every cluster on a version in standard support. Policy STANDARD on non-production; a dated plan for production. Extended-rate spend on the bill: zero.
• Nodes and add-ons on the same minor as the top of the cluster within 30 days, with the change record: deprecation output, add-on order, node roll, rollback window.
• api, audit and authenticator logs on, in ap-south-1, kept 180 days, with a saved query for "who ran exec into which pod".
• Endpoint private or CIDR-restricted. Access entries listed by ARN. No IAM user with cluster-admin. The provider's own access through a role you own and can remove.

Four lines. A provider who has done this for a regulated client will add to the list rather than negotiate it down.

What can you run on Monday?

Read access to EKS is enough:

for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  aws eks describe-cluster --name "$c" --query \
    'cluster.[name,version,upgradePolicy.supportType,
      resourcesVpcConfig.endpointPublicAccess,
      resourcesVpcConfig.publicAccessCidrs,
      logging.clusterLogging[?enabled].types[]]' --output json
done

aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate]' \
  --output table

aws eks list-access-entries --cluster-name "$CLUSTER"

aws eks update-cluster-config --name "$CLUSTER" \
  --upgrade-policy supportType=STANDARD

The loop prints, per cluster, the version, whether it will drift onto the extended rate, whether the API is on the internet, which CIDRs are allowed and which logs are on. An empty log list is the finding. The second command gives the end date of every version EKS offers, for the refresh plan. The third lists every principal with access. The last turns the extended rate off, and only works while the cluster is still in standard support: once it has crossed over, the disable page says "you cannot disable extended support", and the only way off the $438 is the upgrade.

When is Auto Mode, or no Kubernetes at all, the honest answer?

Auto Mode, when nobody on the team can say what the CNI is. It takes the node lifecycle, the patching and the 21-day rotation for a per-instance fee on top of EC2, and for a team without a platform engineer that is cheaper than a provider. The version is still yours to schedule, and so are the logs and the endpoint.

No Kubernetes, for the team of three with six services from the hire-or-partner comparison. ECS behind an ALB has no minor version to chase three times a year and no audit log to remember to switch on. We say this to prospects who arrive asking which provider to buy, and the answer is often not yet.

The short version

Run the loop above before the next invoice. If a cluster shows EXTENDED on a version in standard support, set it to STANDARD today on everything that is not production and write a date for production. If the log list is empty, enable audit and authenticator now and set the retention to 180 days. If the endpoint is public with no CIDRs, fix that this week. Then list the access entries and read every ARN aloud to whoever owns the account.

Then hold the provider to the four lines. If the proposal says "fully managed Kubernetes" and cannot tell you which of your clusters it upgraded last quarter, that is the finding.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.