«You cannot downgrade a user role»: AWS описала два способа понизить роль пользователя в Amazon Quick

Какое ограничение обнаружилось

5 октября 2026 года AWS опубликовала в блоге Machine Learning Blog разбор Гаурава Джайсинга (Gaurav Jaisingh), технического менеджера по работе с клиентами: он посвящён одной задаче жизненного цикла пользователя — понижению роли в Amazon Quick.

Повод практический. Когда обязанности человека меняются и авторские или административные права ему больше не нужны, роль полагается понизить: это и принцип наименьших привилегий, и способ сократить расходы. Однако прямой переход доступен не для всех ролей.

Консоль Amazon Quick не даёт напрямую понизить администратора до читателя или автора до читателя, а лежащий в её основе API update-user навязывает то же ограничение, отклоняя прямое понижение сообщением «You cannot downgrade a user role». Именно поэтому AWS описывает два обходных маршрута: удаление пользователя с последующим созданием заново и пошаговое понижение через AWS CLI.

Роли, уровни подписки и деньги

В Amazon Quick базовые роли — Admin, Author и Reader. Их набор зависит от уровня подписки: в Amazon Quick Enterprise (полноценные BI-возможности плюс ИИ — агенты, topics, Q&A, истории и генеративные сводки) это Admin Pro, Author Pro и Reader Pro, а в Amazon Quick Sight с традиционным BI — Admin, Author и Reader.

Разница важна не только функционально. По справочнику API у операции UpdateUser поле Role принимает значения ADMIN, AUTHOR, READER и RESTRICTED_READER. Авторы и администраторы оплачиваются фиксированной месячной ставкой за пользователя, а читатели — по сессиям. Поэтому пользователи, заведённые как авторы, но фактически только просматривающие дашборды, при переводе в читателей заметно сокращают счёт — AWS называет это приведением роли к реальным задачам.

Способ первый: удалить и создать заново

Первый способ AWS называет самым простым и подходящим для тех, кому неудобно пользоваться CLI: пользователя полностью удаляют, а затем приглашают заново уже с ролью Reader.

В консоли нужно открыть меню профиля, перейти в Manage Quick → Manage users, найти нужного пользователя и удалить его. Если права на его активы не переданы заранее, Quick сам покажет диалог переноса владения и предложит выбрать администратора, который получит все ресурсы, — подтверждение выполняется кнопкой Delete and transfer; при этом всё уходит одному человеку.

После удаления на той же странице Users остаётся выбрать Invite users, указать адрес и назначить роль Reader. Затем AWS советует проверить результат: права обновились до Reader, пользователь видит дашборды и отчёты, но не может создавать или изменять содержимое.

Способ второй: ступенчатое понижение через AWS CLI

Второй способ, который AWS называет рекомендуемым для тех, кто работает с CLI, обходит ограничение за счёт промежуточных ролей. Для прежних BI-ролей последовательность такая: Admin → Author → Restricted Reader → Reader. Для пользователей уровня Pro работает та же лестница, если промежуточные шаги используют устаревшие роли, например: Author Pro → Author → Restricted Reader → Reader Pro.

Технически каждый шаг — это вызов update-user с явным указанием роли: aws quicksight update-user --aws-account-id… --user-name… --namespace default --email… --role AUTHOR. Значение флага --role должно точно совпадать с именем роли в API, а между шагами скрипт выдерживает паузу, чтобы изменения успели примениться.

AWS отдельно отмечает: в AWS CloudShell регион указывать не нужно, потому что среда берёт его из контекста консоли, а при запуске из локального CLI параметр --region требуется. Предлагаемая последовательность останавливает переход, если хотя бы один шаг завершился ошибкой.

Сначала активы, потом роль

Перед сменой роли AWS советует разобраться с владением контентом: у понижаемого пользователя могут оставаться дашборды, наборы данных и анализы, и после понижения он уже не сможет их редактировать.

Способов передать активы три. Самый управляемый — заранее открыть каждый ресурс, выбрать Share и назначить другого администратора со-владельцем, чтобы точно определить, кто за что отвечает. Если активов много, на странице Admin в разделе Manage assets доступен массовый перенос владения и прав сразу для множества объектов. Третий вариант — поделиться содержимым с группой пользователей Quick: тогда доступ сохраняется, даже если конкретного человека удалят.

Что проверить после понижения

Смена роли не подстраивает автоматически два независимых механизма — Limit Profiles и Custom Permissions, поэтому их нужно пересмотреть отдельно.

Limit Profiles задают персональные лимиты, например объём индексного хранилища и часы работы агентов. Если понижаемому пользователю был назначен профиль под прежнюю роль администратора или автора, ему стоит выдать профиль, рассчитанный на читателя, чтобы не выделять лишние ресурсы.

Custom Permissions ограничивают отдельные возможности внутри уровня роли, и профиль, рассчитанный на автора, на читателе может вести себя не так, как ожидается. AWS предлагает либо снять его на финальном шаге CLI флагом --unapply-custom-permissions, либо назначить профиль, предназначенный для роли Reader.

Пакетный сценарий и управление доступом

Для нескольких пользователей AWS приводит bash-скрипт: он читает из файла пары «имя, адрес» (строки с # считаются комментариями) и прогоняет каждого по трём стадиям — AUTHOR → RESTRICTED_READER → READER, делая паузу между шагами и прерывая обработку пользователя при первой ошибке.

Имя нужно брать именно такое, как оно заведено в Amazon Quick: в федеративных средах оно может отличаться от части адреса до знака @. Список же пользователей удобно готовить не вручную, а загрузкой адресов из CSV — в том числе из выгрузки list-users.

К общим рекомендациям AWS относит регулярные аудиты доступов раз в месяц или квартал, принцип наименьших привилегий, обмен ресурсами через группы, а не с отдельными людьми, передачу владения до смены роли и использование AWS Identity and Access Management как дополнительной границы прав. После завершения изменений временные тестовые пользователи, скрипты и файлы со списками удаляются, а итоговые права проверяются.

Отдельный случай — среды на AWS IAM Identity Center: там роль меняют не ступенчатой последовательностью, а переводом пользователя между группами каталога, например из группы Quick-Admins в группу Quick-Readers.