AWS показала две cross-account схемы управления AI-моделями

Один механизм, две границы доверия

AWS расширила связку managed MLflow и SageMaker AI Model Registry на организации с несколькими аккаунтами. В опубликованной архитектуре есть два варианта: hub-and-spoke central governance с общим MLflow app в центральном аккаунте и hub-and-spoke hybrid governance, где каждый development account сохраняет собственный MLflow и локальный реестр.

Обе схемы используют автоматическую регистрацию модели и отдельный approval gate, но по-разному отвечают на главный вопрос: когда артефакт должен пересечь границу аккаунта. В центральном варианте кандидат появляется в hub сразу при регистрации. В гибридном — только после локальной проверки и запуска контролируемого copy workflow.

Центральный hub принимает кандидатов напрямую

В первой топологии hub-аккаунт размещает общий MLflow app и центральный Model Registry, а затем делится приложением с development accounts через AWS Resource Access Manager. Data scientist в spoke регистрирует модель против этого общего MLflow app. Автоматическая синхронизация сразу создаёт Model Package Group и версию в реестре hub-аккаунта.

После первой регистрации администратор добавляет resource policy к синхронизированной Model Package Group и через AWS RAM предоставляет spoke разрешение `AllowDeploy`. Governance officer проверяет кандидата в центральном SageMaker Studio, переводит его в production и одобряет. Событие одобрения может запускать CI/CD pipeline, который разворачивает модель обратно в spoke.

Цена централизации — запись из spoke в hub

Центральная схема даёт governance-команде одно место для кандидатов из всех development accounts. Но эта простота означает, что spoke фактически пишет в hub через shared MLflow app. Кроме того, аккаунту deployment нужен доступ к model artifacts в bucket центрального контура.

Есть и ограничение lineage. Поскольку синхронизация выполняется в hub, полный lineage graph доступен governance officer в центральном Studio. Однако связанные lineage entities не возвращаются в spoke автоматически через AWS RAM share. Следовательно, общий доступ к Model Package Group не равен двустороннему обмену всей историей происхождения модели.

Гибридная схема пропускает через границу только одобренное

Во второй топологии каждый development account использует собственный MLflow app. Регистрация автоматически создаёт пакет в локальном Model Registry, не затрагивая hub. Затем model owner проверяет и одобряет модель внутри development account; только это событие запускает workflow передачи в центральный контур.

Copy workflow переносит артефакты в bucket, принадлежащий hub, переписывает inference specification и регистрирует пакет в общей destination group. После этого центральный governance officer повторно проверяет копию и одобряет её как общий governance record. Deployment при этом может использовать локально одобренную модель, поэтому во время выпуска не требуется читать артефакт через границу аккаунтов.

Изоляция требует второго решения и большего обслуживания

Гибридный вариант сохраняет development accounts полностью изолированными до локального approval. Это подходит организациям, которым важно не давать рабочим аккаунтам возможность напрямую регистрировать объекты в hub. Взамен появляется второй контрольный этап: сначала решение model owner в разработке, затем повторная валидация governance officer в центре.

AWS прямо сравнивает operational cost: одноаккаунтная схема имеет наименьшую стоимость сопровождения, централизованная cross-account — умеренную, гибридная — наибольшую. Причина не только в числе аккаунтов, но и в дополнительных bucket policies, AWS RAM shares, destination groups и автоматизации копирования, которые нужно создать, наблюдать и удалять при завершении эксперимента.

Approval остаётся воротами, а не deployment

Для обеих cross-account топологий AWS подчёркивает: approval в Model Registry является gate, но сам по себе не разворачивает модель. После решения проверяющего отдельный ML engineer или CI/CD pipeline выполняет deployment. Аккаунт, из которого идёт запуск, должен иметь доступ к соответствующим артефактам.

Выбор между схемами поэтому зависит не от числа моделей, а от границы доверия. Если допустим общий MLflow app и важен единый оперативный обзор, central hub сокращает число копий и стадий. Если development accounts должны оставаться изолированными, hybrid pattern добавляет стоимость и повторную проверку, но не переносит в центральный контур кандидатов до локального одобрения. Базовая автоматическая синхронизация, описанная в первой части, служит строительным блоком для обоих вариантов.