In this analysis
Host replacement restores an execution location; workload continuity additionally depends on artifacts, durable state and the next valid operation.
A shared GPU task depends on its container, the MPS service and the host beneath both. These lifecycles can change independently. The ECS announcement is therefore useful to read as a dependency change: a running application process is no longer the only state that matters to the shared execution path.
Separate the lifecycle objects
The task owns its application initialization and work. The shared service enables GPU sharing among tasks. The host provides the place where those components run. An operating description should identify each object before explaining how recovery crosses between them.
This is an analytical model, not a claim that every deployment exposes identical controls. Its purpose is to prevent a healthy task signal from being treated as proof that every dependency remains ready.
Earlier ECS milestones established two layers
The February 4, 2019 GPU release established task-level device assignment. The September 30, 2025 Managed Instances announcement established a managed host path. The sharing service adds another operating dependency to that chronology.
Our causal hypothesis is that finer packing creates a shared runtime object whose health affects several tasks. Managing it requires reasoning beyond either the individual application’s process or the physical presence of a GPU.
Read the announced recovery action exactly
The October 27, 2026 update says Managed Instances monitors the MPS daemon and replaces an unhealthy instance, moving tasks to healthy capacity. It does not describe preservation of every in-flight GPU execution state.
That omission should remain an evidence boundary. Automatic placement on another host and continuation from the same application state are different results. A workload needing the latter requires its own documented recovery path.
Define the handoff into a replacement environment
An illustrative recovery artifact can separate what must be available:
| State | Question on the new execution path |
|---|---|
| Model version | Which exact artifact set must load? |
| Application data | Which durable state is available? |
| Active work | Which requests may be resumed or repeated? |
| Readiness | What must complete before new work is admitted? |
The artifact does not assume a particular checkpoint mechanism. It identifies the application evidence that cannot be supplied merely by observing that a replacement host exists. It also makes the point at which infrastructure recovery hands work back to the application visible.
Evaluate recovery through the next valid operation
A useful result is that the application can perform its next valid operation under its intended semantics. A new placement is a prerequisite, while artifact preparation, state handling and admission complete the execution path.
Initialization downloads discusses one preparation dependency. Startup and readiness distinguishes operating signals. The retrospective mechanism is a newly managed shared-service lifecycle, with application continuity remaining a separate, explicit contract of the workload.