В этом разборе
Релиз описывает восстановление MPS заменой инстанса и перемещением задач в Managed Instances, не устанавливая одинаковую реакцию каждого режима ECS.
Анонс ECS даёт общий GPU для EC2 и Managed Instances, но автоматическое наблюдение MPS-демона и замену инстанса описывает именно для Managed Instances. Эта область меняет ответственность эксплуатации. Одинаковая функция выделения не позволяет предполагать одинаковые обязанности восстановления в обоих способах развёртывания без отдельного подтверждения того, как обслуживается окружающий общий сервис.
Читаем выделение и восстановление отдельно
Релиз 27 октября 2026 года описывает связанные возможности: объявление общих ресурсов GPU и управление нездоровым сервисом разделения. Второе явно относится к управляемому пути хоста. При сравнении режимов нужно сохранить эту область, а не распространить каждое предложение релиза на все перечисленные варианты использования функции.
| Режим развёртывания | Совместный GPU в анонсе | Описанное там восстановление демона |
|---|---|---|
| ECS Managed Instances | Поддерживается | Наблюдение, замена инстанса и перемещение задач |
| ECS на EC2 | Поддерживается | Такое управляемое восстановление не установлено |
Таблица не утверждает невозможности автоматизации EC2. Она показывает отсутствие в релизе подтверждения одинакового управляемого поведения каждого режима. Конкретная установка может иметь другие механизмы, которые нужно устанавливать по её собственному эксплуатационному устройству.
Предпосылка управления хостами существенна
Объявление Managed Instances 30 сентября 2025 года установило управляемый вычислительный путь до разделения GPU. Оно даёт причинный контекст назначения реакции уровня хоста сервису вместо передачи каждой операции команде приложения. Новый ресурсный механизм развивается внутри ранее обозначенной модели эксплуатации окружающей вычислительной инфраструктуры.
Различие касается ответственности, а не только удобства. Кто-то наблюдает общий сервис, решает о нездоровом хосте и предоставляет новое место задачам. Эти обязанности сохраняются при автоматизации; меняется их исполнитель и способ соединения с планировщиком. Для понимания предложения нужно назвать действие, а не ограничиваться общей меткой управляемости.
У целого GPU был проще объект зависимости
Релиз GPU 4 февраля 2019 года даёт раннюю основу выделения. Общий сервис добавляет зависимость между задачей и устройством, поэтому здоровье хоста нельзя описать одним живым контейнером. Сам процесс приложения не устанавливает готовность всех частей пути, через которые оно получает доступ к разделяемому вычислительному ресурсу.
Наша гипотеза — управляемое восстановление ценнее при зависимости нескольких задач от общего runtime-сервиса. Это объясняет направление эксплуатации без прогноза частоты отказов или универсального времени восстановления. Причинная связь относится к распределению обязанностей вокруг нового общего компонента, а не к выдуманному измерению надёжности фактически работающих клиентских приложений.
Называем действительно объявленную реакцию
AWS описывает замену инстанса и перемещение задач на здоровую мощность при нездоровом демоне. Это действие уровня хоста, а не только перезапуск локального процесса приложением. Объект восстановления становится существенной частью новости, потому что реакция затрагивает окружающее место выполнения, на котором могут находиться несколько зависимых задач.
Запись ответственности называет обнаружение, замену и границу продолжения задачи. Не следует заполнять пробелы выдуманной гарантией непрерывного исполнения: релиз не даёт достаточных подтверждений такого широкого вывода. Он устанавливает автоматизированное инфраструктурное действие, сохраняя дальнейшее поведение приложения предметом его собственного состояния, инициализации и условий допустимого возобновления работы.
Осознанно выбираем эксплуатационную модель
Хроника связывает управляемые хосты, общее выделение GPU и определённую реакцию восстановления. Польза — понятное распределение инфраструктурных обязанностей при сохранении прикладных. Запуск и готовность объясняют неполноту сигнала живого контейнера. Подключение GPU рассматривает ответственность эксплуатации. Различия помогают сравнивать режимы по действительно описанному поведению, не приписывая объявлению неизвестной общей гарантии.