AWS Managed Service Provider: Who Owns the End-of-Support Date?

The scope from the AWS managed service provider says patch management. You read that as everything in the account with a version number. They read it as Patch Manager running against your EC2 instances on a schedule, which is a real deliverable with real evidence behind it. Both of you signed.

Most of what will break on a regulated account in the next twelve months is not a missing OS package. It is a date. A Kubernetes version leaving extended support. A Lambda runtime passing the point where you can no longer deploy a fix. An engine version RDS moves for you at 02:00 on a Sunday. Our position: the calendar of those dates is what to make somebody own by name, and the patch report is the easy half.

How the provider reaches the account at all is the other day-one question, and we made that argument in the access model to insist on before the first login. This post is about time rather than identity.

Why does an AWS managed service provider's patching scope stop short?

Because the word has a narrow documented meaning, and it is not yours. AWS's shared responsibility model puts it in one line: "AWS is responsible for patching and fixing flaws within the infrastructure, but customers are responsible for patching their guest OS and applications." A provider delivering against that sentence delivers guest OS patching, usually through patch policies in Systems Manager, which are good: one policy covers "all your managed nodes in all AWS Regions in all your AWS accounts".

What a patch report cannot show you is an operating system that has stopped receiving patches entirely. Amazon Linux 2 reached its end of support on 2026-06-30, and the FAQ does not soften it: "Remaining on AL2 carries increasing risk as new vulnerabilities are no longer patched." Compliance is measured against patches that exist. When none are published nothing is missing, and the dashboard goes green on a fleet four months past its last security update. We have sat in a review where that green number was the evidence on the slide.

What does AWS upgrade without asking you?

Three things, and each lands on your availability, not the provider's.

The EKS control plane, first. A Kubernetes minor version gets 14 months of standard support and 12 of extended support, and then AWS moves it. The version lifecycle page is specific about how that arrives: "Automatic updates can happen at any time after the end of extended support date. You won't receive any notification before the update." And it moves half the cluster: "Self-managed nodes and EKS Managed Node Groups will remain on the previous version." Two dates are close enough to matter. Extended support for 1.31 ends on 26 November 2026, standard support for 1.34 on 2 December 2026.

RDS minor versions, second. Clearing AutoMinorVersionUpgrade does not mean what the name suggests. The upgrade documentation says: "In cases of critical security issues or when a version reaches its end-of-support date, Amazon RDS will apply a minor version upgrade even if you haven't enabled the Auto minor version upgrade option." Downtime comes with it, in your maintenance window. If that window overlaps a settlement run, move it.

Lambda runtimes, third, and only for zip functions. For a function shipped as a container image, "you're responsible for rebuilding your function's container image from the latest base image and redeploying the container image."

Which deadlines does nobody get a warning for?

Those container images, mostly. Lambda's runtime deprecation policy looks generous on paper: an email and a Health Dashboard notice "at least 180 days before" deprecation, creates blocked "at least 30 days after deprecation", then code and configuration updates blocked "at least 60 days after". The third is what hurts: it turns up as a failed deploy of a hotfix on a bad night.

Read the shared responsibility table on that page to the end, though. "Deprecation notifications are not available for functions using container images." Teams move Lambda to images for good reasons, package size and build parity, and the notification path a provider watches goes quiet for those functions. Trusted Advisor and the Health Dashboard list zip functions. Nothing is watching your image tags.

The address matters too. Lambda "sends email notification to your AWS account's primary account contact", which on an account somebody else set up is often an alias at the provider. And the API that would automate the watching is gated: the AWS Health API needs a Business Support+, Enterprise or Unified Operations plan, and without one "you receive a SubscriptionRequiredException error". On Developer Support, the scheduled-change feed everyone assumes is running is not. Whose account carries the plan is the same question as who is paying for the work.

When does your EKS cluster certificate authority expire?

Within ten years of whenever somebody created it, and nobody has the date written down. Each cluster has its own certificate authority signing the API server's certificate, and the rotation documentation gives the numbers: "The original CA created with your cluster has a 10-year validity period. Successor CAs created through the rotation process have 5-year validity periods." AWS will not let one expire under you: a successor is appended "approximately 2 years before your outgoing CA expires" and auto-activated "approximately 6 months before expiration" if you have not done it yourself.

The half that is yours is the half that breaks. Control plane, Auto Mode nodes and Fargate pods are updated for you. You are responsible for "updating your worker nodes (managed node groups, Karpenter-controlled nodes, self-managed nodes, hybrid nodes) to trust the successor CA", and for every external client: laptops, CI pipelines, monitoring agents, the Jenkins box nobody owns. AWS is honest about why it cannot help: "External clients exist outside the AWS operational boundary." Nodes that miss the activation lose the API server while the control plane stays up and healthy. A confusing page to answer.

Clusters built in 2018 and 2019 are inside that window now, presumably why AWS shipped CA rotation visibility in the EKS Dashboard on 28 October 2026. If a provider runs your clusters, this belongs in their runbook. The rest of what "managed" covers is in what is still yours when AWS runs the control plane.

What does the RBI expect you to be tracking?

A register and a plan, not a report. The RBI's Cybersecurity, Technology: Risk, Resilience and Assurance Framework Directions, 2026 ask in paragraph 92 that the NBFC "shall monitor software end-of-support (EOS) dates and Annual Maintenance Contract (AMC) dates of IT hardware on an ongoing basis", and in paragraph 93 that it "develop a technology refresh plan for the replacement of hardware and software in a timely manner before they reach EOS".

Most patch scopes are written against paragraph 112 instead, which wants patches applied "in a secure and timely manner with necessary approvals", and paragraph 125, which wants vulnerabilities fixed "in a time-bound manner". A provider carries both with a patch policy and a ticket queue. Neither produces a register of end-of-support dates, because neither is about missing packages. If the scope does not name 92 and 93, they are yours. For the contract side, see what the RBI expects in an outsourcing agreement; our wider read sits in what the directions change for an NBFC on AWS.

What can you build on Monday?

The register, in about an hour. Run this per account and region, then put the output in a sheet with an owner and a date per row.

# Kubernetes support deadlines
aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]' \
  --output table

# Each cluster's version and CAs
for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  echo "$c $(aws eks describe-cluster --name "$c" --query 'cluster.version' --output text)"
  aws eks list-certificate-authorities --cluster-name "$c"
done

# Image rows get no warning email
aws lambda list-functions \
  --query 'Functions[].[FunctionName,PackageType,Runtime]' --output text

# false here still gets upgraded
aws rds describe-db-instances \
  --query 'DBInstances[].[DBInstanceIdentifier,Engine,EngineVersion,AutoMinorVersionUpgrade]' \
  --output table

# Still on Amazon Linux 2?
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].[InstanceId,PlatformName,PlatformVersion]' --output table

# Per CA id from above
aws eks describe-certificate-authority --cluster-name my-cluster \
  --certificate-authority-id <ca-id> \
  --query 'certificateAuthority.validity.notAfter'

Then three questions for the provider, in writing. Which of these dates sit inside the scope? Which mailbox gets the Lambda and Health notifications? Who upgrades the nodes after AWS moves the control plane? A vague answer to the third is the finding.

When is "they handle patching" good enough?

More often than this post makes it sound. A seed-stage SaaS on twelve instances and one database does not need a register with owners and review dates. It needs somebody applying patches, and a provider doing exactly what the scope says beats nobody doing it. AWS's automatic behaviour is mostly protective too. Past a certain point, the lifecycle page notes, the Kubernetes community "stops releasing common vulnerabilities and exposures (CVE) patches", leaving "clusters exposed with no notice and no remediation options". A forced upgrade is the better of two bad outcomes.

So the failure is narrower than "the provider is not doing enough". It is the gap between what you believe you bought and what is written down, and it surfaces the day a deploy is blocked or a node group falls off the API server. Someone who will own the calendar is worth more than someone who will only run the job. If they will not, own it yourself and name the person, the same discipline as knowing what is in your name on the last day.

The short version

Run those commands today and build the register. Check your cluster versions against 26 November 2026 and 2 December 2026. List every Lambda with PackageType of Image, because nothing will warn you about those. Date the Amazon Linux 2 instances and get the CA expiry for each cluster. Fix the account contact. Then send the provider the three questions, and put the answers in the scope at the next renewal, not in a thread.

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.