ZS построила закрытую SageMaker-платформу для тысячи пользователей

Консалтинговая компания ZS вместе с AWS описала внутреннюю платформу ad-hoc аналитики на Amazon SageMaker Studio. Она обслуживает более 200 SageMaker domains в нескольких AWS-аккаунтах и свыше тысячи ежедневных активных пользователей, став основным инструментом большинства прикладных команд ZS. Задача была характерной для регулируемой отрасли: дать аналитикам свободу работы, не открывая прямой интернет и не ослабляя контроль данных.

Архитектура multi-tenant: каждому tenant соответствует отдельный SageMaker domain с изолированным Amazon EFS, собственными IAM roles и управляемой сетевой конфигурацией. Среда по умолчанию работает в internet-free режиме, а обращения к необходимым AWS-сервисам проходят через Amazon VPC endpoints. Установка библиотек направляется только через JFrog Artifactory, где пакеты проверяются до попадания в рабочую среду.

Три уровня IAM вместо одной универсальной роли

ZS разделила полномочия на Domain Execution Roles, Studio User Roles и Space Execution Roles. Первая роль задаёт безопасные defaults для домена, вторая может точечно ограничивать или расширять права конкретного пользователя, третья управляет shared workspaces. Такая иерархия позволяет сохранить least privilege, не создавая отдельную платформу под каждую команду.

Шифрование через AWS KMS включено по умолчанию для EFS, S3, ECR и используемых репозиториев CodeCommit. CrowdStrike отвечает за обнаружение угроз на уровне ОС, Splunk собирает логи, а CloudTrail фиксирует API calls для аудита. Это не один «compliance-флаг», а несколько независимых слоёв: сеть, identity, encryption, endpoint security и журналирование.

Self-service сохранили внутри закрытого контура

Чтобы отсутствие интернета и консоли не превратило платформенную команду в очередь заявок, ZS добавила собственные интерфейсы. Расширение S3 browser позволяет работать с buckets внутри JupyterLab. Streamlit-приложения запускают и останавливают разрешённые Redshift clusters, выполняют DuckDB-запросы к S3 и создают временные EMR clusters только из заранее одобренных конфигураций. Права при этом продолжают проверяться execution roles SageMaker.

Для разных рабочих нагрузок добавлены R kernel, AWS Glue PySpark и Spark kernels, а также выбор версии Python для отдельного Space. Glue interactive sessions получают централизованные defaults для idle timeout, worker count и worker type, чтобы случайная сессия не раздувала расходы. Пользователь видит привычный launcher и веб-интерфейс, а ограничения применяются lifecycle configurations и IAM без ручной настройки каждого notebook.

Backup и наблюдаемость стали частью продукта

Рабочее пространство может быть удалено или архивировано, поэтому ZS синхронизирует данные каждого Space в выделенный S3 bucket каждые 30 минут. Дополнительно AWS Backup автоматически защищает помеченные тегом `ZS_Backup` EFS volumes и хранит копии в отдельных vaults. Такой механизм нужен не только после сбоя, но и при миграции домена.

Для CPU, memory и disk платформа публикует собственные CloudWatch metrics с детализацией до Space каждую минуту. Администраторы могут найти упирающуюся в ресурсы среду и скорректировать capacity. Параллельно IAM ограничивает пользователей небольшими заранее разрешёнными instance types, более мощный compute требует allowlisting, а auto-shutdown освобождает простаивающие ресурсы.

Экономика масштаба по данным самой ZS

ZS сообщает о месячных расходах SageMaker свыше 50 тысяч долларов при более чем 500 ежедневных пользователях в производственном срезе и экономии около 10 тысяч долларов в месяц благодаря SageMaker Savings Plans. Теги команды и проекта используются для chargeback через AWS Cost Explorer. В том же материале итоговый масштаб описан уже как более тысячи daily active users, поэтому эти цифры, вероятно, отражают разные моменты или уровни охвата платформы.

Это внутренние показатели ZS и AWS, а не независимый аудит. Они подтверждают, что система реально эксплуатируется, но не позволяют автоматически обещать другой компании такую же экономию. Полная стоимость включает платформенную разработку: lifecycle scripts, Streamlit-инструменты, monitoring, пакетный proxy, резервное копирование и процесс выдачи исключений.

Почему это важно

ZS показывает более зрелую версию «демократизации AI», чем простая выдача notebook каждому сотруднику. Self-service здесь означает быстрый доступ только к заранее очерченным операциям: approved package, разрешённый instance, изолированный Space, контролируемый endpoint и наблюдаемый расход. Удобство создаётся поверх governance, а не вместо него.

Практический вывод для платформенной команды — начинать с повторяемого tenant-шаблона и безопасных defaults. Нужно запретить прямой egress, определить доверенный package registry, разделить роли домена, пользователя и Space, автоматизировать backup и idle shutdown, а затем вернуть удобство через внутренние UI. Метрики успеха должны включать не только число пользователей, но и время выдачи среды, долю idle compute, восстановление из backup, число исключений IAM и стоимость на активную команду. Тогда безопасность перестаёт быть ручным тормозом и становится свойством платформы.