Managed Compute Patching Is Not Managed Remediation

Managed compute patching means AWS ships the fixed platform. It does not mean your running workloads are on it.

On October 30, AWS published bulletin 2026-160-AWS for CVE-2026-98432, a Linux kernel IPv4 TCP use-after-free, and has updated it since, most recently on November 4. The bulletin lists what AWS is releasing for Fargate, ECS Managed Instances, EKS Auto Mode, Bottlerocket and RDS, and it reads like a remediation statement. For three of those services it is closer to a start date: new compute gets the fix, while existing compute moves through provider-managed lifecycle processes shaped by service settings and workload constraints.

This post is about that interval, not the flaw. The bulletin says AWS has no evidence the issue has been leveraged, and the exploit conditions are out of scope here.

What the AWS Bulletin Confirms and What It Leaves to You

The bulletin gives each service a different kind of statement. For Fargate and ECS Managed Instances, compute launched after 17:00 UTC on November 1 (9:00 AM PST in the bulletin) uses the patched platform version or AMI. For EKS Auto Mode, AWS released updated AMIs on October 31 and says Auto Mode replaces existing nodes automatically, subject to your NodePool disruption budgets. Bottlerocket and RDS get dates of their own, shown in the table below.

Everything in that list is about what exists. None of it is about what is running, and what exists is all that managed compute patching can promise on its own. For existing compute, each managed service hands the timing of the last step to a setting: Fargate tasks are retired per your task retirement settings, ECS Managed Instances drain 14 days after launch or earlier if event windows say so, and Auto Mode replaces nodes automatically, subject to your NodePool disruption budgets. Those are lifecycle and governance questions of the kind the modern infrastructure and IaC architecture pillar covers. The fix is a provider artifact, and the state it has to reach is yours.

The Managed Compute Patching Gap

The managed compute patching gap is the interval between a provider making a security fix available and your existing workloads running on remediated compute. AWS controls when the replacement revision exists and how the managed service applies it. You control some of the conditions that shape when existing workloads move: retirement timing, maintenance windows, disruption budgets and deployment behavior. The gap sits between provider availability and workload adoption, with responsibility split across both sides.

It is not an interval this site has measured before. Patch visibility debt is the time between attacker activity and the confirmation signals that set remediation priority. Patch rollback risk is the question of who may reverse a remediation once it breaks something. Neither measures how long existing compute stays on the old revision after the provider has shipped the new one.

Three Services, Three Levers

Each service splits the last step differently. The table names what AWS ships, what moves existing compute, which lever you hold, and what the sources leave open. Bottlerocket and RDS appear as contrast rows only.

Fargate: Retirement Timing

On Fargate, managed compute patching is retirement timing. New tasks run on the newest platform revision, and older revisions are retired once a newer one exists. AWS sends a retirement notice with a date, and you cannot opt out of retirement. The task maintenance documentation says so directly. What you set is when it starts. The account setting fargateTaskRetirementWaitPeriod takes 0, 7 or 14 days, with 7 as the default; 0 retires affected tasks immediately after the notice. If you enable EC2 event windows for Fargate, they take precedence over the wait period, and replacement inside a window is best effort. With event windows, Fargate also keeps tasks running at least three days before retiring them in the next available window, except for user-initiated stops or critical health events such as hardware degradation. You can also replace tasks yourself at any time, for example with a forced new deployment of the service.

What happens at retirement depends on the task type. ECS replaces service tasks automatically, starting the replacement first unless the service's maximum percent is 100. Standalone tasks, such as those started by RunTask, EventBridge, Batch or Step Functions, are stopped on or after the retirement date and are not replaced. For those, "no action required" is not true.

AWS has also said it may override the wait period for a critical security update and retire affected tasks immediately. That statement comes from an AWS blog post, not the current task maintenance page, and the bulletin does not say whether it applied to this CVE.

ECS Managed Instances: Day 14 and Day 21

Per the ECS Managed Instances patching documentation, ECS Managed Instances set a drain schedule at launch. Draining begins at day 14, and event windows you configure can pull it earlier on a best-effort basis. ECS also lists detection of security vulnerabilities as a reason to drain early, and the bulletin does not say whether that applied here. Until the scheduled drain time, ECS keeps placing tasks on the instance as it normally would, so an instance launched on the old AMI can keep receiving new tasks until its drain begins. Event window changes apply only to instances launched afterward, so editing a window today does not shorten the clock for instances already running.

Once draining starts, ECS honors your service deployment configuration. If draining has not finished by day 21, ECS deregisters the instance and stops what remains. Your deployment settings decide whether a drain finishes cleanly before then or is cut off at the limit.

EKS Auto Mode: Drift, Budgets and the Grace Period

On Auto Mode, managed compute patching is a drift and budget question. AWS controls the AMI. Auto Mode releases a new one roughly weekly, and a new AMI marks existing nodes as drifted so they are replaced. By default, per the EKS Auto Mode node pool documentation, a NodePool has a single disruption budget of 10 percent of nodes, nodes expire after 336 hours, and a 24-hour termination grace period is applied to the node's claim when you set none. Those are defaults, not a deadline for this CVE. On custom NodePools you can change the budget, the expiry and the grace period. The built-in system and general-purpose pools cannot be modified. A budget can also be scoped by reason, so a zero-node budget for drifted nodes outside a maintenance window can stop drift replacement from starting there.

Pods are the other lever. Pods that block eviction, through a PodDisruptionBudget or a do-not-disrupt annotation, are respected while a node drains. The termination grace period is the ceiling on that: AWS guidance on re:Post says blocking pods are honored until it is reached, and then they are deleted. The Kubernetes scheduler post describes a different failure, a strict PodDisruptionBudget that leaves a node drain hanging indefinitely during an upgrade. Auto Mode does not leave it open-ended. With a grace period set or defaulted, the block ends. That limits the delay. It does not remove it.

Where the Customer Lever Becomes the Delay

Every lever above exists for a good reason: a wait period or event window lets a task stop when you chose, and a disruption budget keeps capacity serving while nodes turn over. Each one also lengthens the time existing compute stays on the old revision.

The providers set lifecycle controls, and they matter. Fargate retirement cannot be declined, ECS deregisters at day 21, and Auto Mode nodes expire after 336 hours by default. Those controls shape how long existing compute can stay on an older revision, but they are not interchangeable, and their defaults are not a universal remediation deadline. The practical question in managed compute patching is where your workloads sit within the lifecycle AWS provides and the settings your team has chosen. A team that tuned a wait period or a budget for availability made a patch-timing decision at the same moment, whether or not it saw it that way.

The lifecycle controls are the provider's. The position inside them is set by your settings.

This is the same shape CA distrust propagation describes for client classes. A vendor's action establishes what the vendor changed, not that each of your clients has consumed it, and the update owner differs by class. Managed compute adds a twist. Because the provider also runs the replacement, it is easier to assume the provider owns the last step too.

Derived, not published: Assume one ECS Managed Instance launched just before 17:00 UTC on November 1. On the documented schedule, draining begins at day 14, around November 15, and ECS deregisters the instance if draining has not finished by day 21, around November 22. This is a single example built from the documented 14-day and 21-day behavior and an assumed launch time. AWS has not published it as a guarantee. Event windows or early draining can shorten it, and instances launched at other times follow other dates. It is not a worst case for your estate.

What to Inventory Before the Next Provider Bulletin

The managed compute patching gap is measurable, but only if someone has written down the settings that position it. Four items, in order.

01 — Name the compute classes

List which workloads run on Fargate, ECS Managed Instances, EKS Auto Mode and compute you patch yourself, such as Bottlerocket. On Fargate, separate service tasks from standalone tasks, because only service tasks are replaced for you. Each class has a different owner for the last step.

02 — Record the settings that position the gap

For each class, record the values in force: the Fargate retirement wait period and event windows, ECS event windows and service deployment settings, Auto Mode disruption budgets, expiry and termination grace period, and the PodDisruptionBudgets that block drains. Note which are defaults and which someone changed.

03 — Decide how you will show remediation

Evidence of remediation comes from the running compute, not from the provider's release notice or your deployment record. A shipped revision tells you what AWS released. The revision a workload is running is a separate fact, and it is the one that answers whether you are remediated.

04 — Assign an owner and an expiry

Name the role that can change these settings during a security event. Any setting that defers replacement beyond the provider's default should carry an owner and an expiry, so a deferral made for availability does not outlive the reason for it.

What This Post Does Not Establish

It does not assess exploitation or exploit conditions. The bulletin says AWS has no evidence the issue has been leveraged and says researchers have demonstrated remote code execution against hosts with an MPTCP listener; this post evaluates neither statement. It does not establish whether AWS overrode the Fargate wait period or drained ECS Managed Instances early for this CVE, or what the maximum lifetime of an Auto Mode node is beyond the documented 336-hour default. The November 15 and November 22 dates above are one example, not a bound. The bulletin was most recently updated on November 4, so read the current bulletin before acting on any date here.

Architect's Verdict

Managed compute patching ends where the provider's fix exists. Whether your workloads are running that fix is a separate state, and it is decided by lifecycle settings, not by the bulletin.

The real problem is that the last step has three authors. The provider sets the defaults and the lifecycle controls, and in some cases it can override your settings. You hold some of the levers in between: wait periods, event windows, disruption budgets, grace periods and the PodDisruptionBudgets your applications ship with. Most estates cannot say which of those values is in force on which compute.

In managed compute patching, the settings that protect availability are the same ones that position the exposure. That is not a flaw in them. It is why they need an owner and an expiry, and why the evidence that a workload is remediated has to come from the running compute.

The provider ships the fix. The provider's lifecycle and your settings together determine when existing workloads receive it.

Originally published at rack2cloud.com