# ECS MPS limits versus isolation: different questions

ECS GPU budgets describe allocation, while isolation requires a separate property and mechanism. The MPS announcement does not identify its daemon interface version or equate MPS with MIG.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-27
Original announcement: https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-ecs-gpu-sharing-nvidia-mps/
Canonical URL: https://retrivium.ai/retrospectives/retro-ecs-mps-memory-compute-isolation/

ECS memory and compute declarations answer how much shared GPU capacity a container requests. Isolation asks a different question: which effects can cross the boundary between workloads? The October MPS launch makes resource planning more expressive, while a security or fault-containment conclusion still needs the actual sharing mechanism and configuration.

## Read the declared budget precisely

The [October 27, 2026 announcement](https://aws.amazon.com/about-aws/whats-new/2026/10/amazon-ecs-gpu-sharing-nvidia-mps/) describes GPU memory in the container definition and an optional maximum compute share. These are allocation controls. They should not be silently rewritten as every possible property of a hardware partition.

A budget helps a scheduler reason about placement. Whether neighboring work can affect latency, faults or access is a separate system question. A useful analysis identifies the exact property it wants to establish.

## Name the mechanism before comparing it

[NVIDIA's MPS documentation](https://docs.nvidia.com/deploy/mps/index.html) describes a runtime service and distinguishes legacy MPS v2 from opt-in MPS v3 interfaces. The AWS announcement does not identify its daemon interface version. It would be unsupported to infer that version merely from the date of the release.

[NVIDIA's MIG guide](https://docs.nvidia.com/datacenter/tesla/mig-user-guide/introduction.html) describes hardware instances with assigned compute and memory-system paths. That is a specific partitioning architecture. An MPS feature name and a MIG instance are therefore not interchangeable descriptions of the same boundary.

## Keep the service chronology intact

The [February 4, 2019 ECS GPU release](https://aws.amazon.com/about-aws/whats-new/2019/02/gpu-support-for-amazon-ecs-now-available/) established device assignment. The [September 30, 2025 Managed Instances release](https://aws.amazon.com/blogs/aws/announcing-amazon-ecs-managed-instances-for-containerized-applications/) established a managed host path. October adds finer shared allocation to that history.

The causal benefit is a new placement option. The history does not establish a universal isolation result, because allocation, host management and hardware partitioning concern different mechanisms.

## Separate the acceptance questions

An illustrative review can preserve the distinctions:

| Question | Property to establish |
| --- | --- |
| Does the model fit? | Required memory within its execution envelope |
| Can work be packed? | Compatible resource declarations and actual demand |
| Is latency acceptable? | Behavior with the intended neighboring workloads |
| Is the boundary suitable? | The isolation and fault properties the application requires |

The table does not prescribe AWS admission policy. It prevents a successful capacity check from being used as evidence for an unrelated trust or failure boundary.

## Choose by the required property

A small inference task may be a good candidate for shared allocation while another task needs a different boundary. That decision follows workload requirements and supported configurations, not a universal ranking of sharing technologies.

[GPU sharing mechanisms](/journal/gpu-mig-vs-time-slicing/) explains differing boundaries. [Throughput and latency](/journal/throughput-latency-tradeoff/) explains operating tradeoffs. The retrospective lesson is to value the new budget controls for what they express while keeping isolation claims tied to their own evidence.