AWS发布Amazon Quick用户角色降级指南：控制台不支持直接降级，需删除重建或用CLI分步降级
AWS Machine Learning博客介绍了在Amazon Quick中把Admin或Author降为Reader的两种方法，并说明通过IAM Identity Center或Active Directory认证的用户改由外部身份提供方组映射处理，无需分步降级。
AI解读：手动方法需要先转移被降级用户拥有的仪表板、数据集和分析等资产，然后删除账号，再以Reader角色重新邀请该邮箱加入；删除时若未提前转移，Quick会弹出对话框要求把所有资源转给单一管理员。
资产所有权转移有三种方式：逐个手动邀请另一位管理员成为共同所有者、在Admin页面使用Manage assets批量转移、或把资源分享给用户组；对Quick Identity用户可建Quick组，对IAM Identity Center或Active Directory集成账户则使用外部组。
角色变更不会自动调整Limit Profiles或Custom Permissions配置文件；降级后应检查并为Reader重新分配适当的限制配置文件，或在最后一步CLI命令中使用 --unapply-custom-permissions取消自定义权限。
AWS Machine Learning博客发布了一篇关于Amazon Quick用户角色降级的操作指南，作者为Gaurav Jaisingh。文章指出，Amazon Quick控制台没有为所有角色转换提供直接降级路径，具体来说无法通过控制台界面从Admin直接降为Reader，也无法从Author直接降为Reader；update-user API同样强制执行这一限制，会以“You cannot downgrade a user role”错误拒绝直接降级。
文章给出两种可行方案：手动删除并重建用户，以及使用AWS CLI分步降级。后者对旧版BI角色（Admin、Author、Reader）采用的顺序是Admin > Author > Restricted Reader > Reader；文章称该序列对Pro用户也可用，只要中间步骤使用旧版角色，例如Author Pro > Author > Restricted Reader > Reader Pro能成功完成。
适用范围方面，文章主要针对Amazon Quick Identity（Quick-managed）用户。通过IAM Identity Center或Active Directory认证的用户，角色变更通常由外部身份提供方组映射管理；文章称若使用IAM Identity Center，降级通过把用户从一个IdC组移到另一个组处理，例如从Quick-Admins组移到Quick-Readers组，不需要分步降级序列。
为什么降级：最小权限与按角色计费
文章将角色降级放在最小权限原则下说明：当用户职责不再需要创作或管理能力时，应降低其角色，以减少安全面。文章还提到Quick按角色计费——Authors和Admins按每用户固定月费收费，Readers使用基于会话的定价；将只消费仪表板却配置为Author的用户调整为Reader角色，可降低费用。文章建议查看Amazon Quick定价页面获取当前价格，并提到可通过Custom Permissions在同一角色层级内限制特定能力，以及通过AWS IAM集成提供额外的权限边界。
CLI分步降级的操作要点
文章将CLI方法称为推荐方式，因为Quick要求角色变更按特定顺序进行，不能从任意Admin直接转到任意Reader。示例命令使用aws quicksight update-user，依次把角色改为AUTHOR、RESTRICTED_READER、READER，并要求 --role值与API角色名称完全一致。
文章附了一段用于批量更新多个用户的bash脚本，按AUTHOR、RESTRICTED_READER、READER循环执行，出错则停止该用户的转换，并在每步之间sleep 3秒；脚本从users_to_downgrade.txt读取“username,email”格式的行，以 # 开头的行视为注释。文章提醒，运行前确认用户当前是Admin或Author；在联合环境中应使用实际的Quick用户名，它可能与邮箱前缀不同；在AWS CloudShell中无需指定区域。
文章还列出操作前的重要注意事项：被降级的用户将无法再编辑其先前拥有的资源；对大型组织，建议从CSV文件加载用户邮箱地址而非硬编码；使用AWS CloudShell时可省略区域参数，因为它自动使用当前控制台区域上下文。
资产所有权转移与降级后的配置检查
文章强调，删除用户前必须先处理其拥有的仪表板、数据集和分析，以防资源成为孤儿。若用户是Author，需确认其是否拥有任何数据集或仪表板，并执行相同的资产重新分配步骤。文章给出三种转移方式：逐个进入资产选择Share并指定另一位管理员为共同所有者；在Quick的Admin区域使用Manage assets进行批量所有权转移或更新共享权限；或将资产分享给用户组，这样即使用户被删除，共享资源的访问权仍然保留。
角色变更完成后，文章提示Limit Profiles和Custom Permissions配置文件不会自动随角色调整，两者独立于用户角色存在。Limit Profiles控制每用户资源上限，例如索引存储和agent小时数；如果被降级用户此前被分配了适合Admin或Author的配置文件，应改配为适合Reader的配置文件，避免资源过度分配。Custom Permissions限制角色层级内的特定能力，为Author分配的配置文件在Reader上可能不会按预期工作，可选择在最后一步CLI命令中使用 --unapply-custom-permissions取消，或分配为Reader层级设计的配置文件。
手动删除重建方法与后续清理
对于无法使用CLI的环境，文章给出手动删除并重建的方法：先完成资产所有权转移，然后在AWS管理控制台进入Amazon Quick，通过个人资料图标选择Manage Quick、Manage users，找到目标管理员用户并删除，确认删除；如果未提前转移资源，Quick会显示所有权转移对话框，要求选择另一位管理员接收该用户所有资源，然后选择Delete and transfer。删除完成后，在Users页面选择Invite users，输入该用户邮箱并选择Reader角色，发送邀请；用户接受邀请后，确认权限已更新为Reader，只能查看仪表板和报告，不能修改或创建内容。
文章在结尾建议的清理步骤包括：删除任何测试用户，确认没有遗留的非预期资源，删除临时CLI脚本或用户列表文件，最后再次核对用户权限。最佳实践方面，文章列举了定期审计用户角色（每月或每季度）、变更角色前转移资源所有权、遵循最小权限原则、在同一角色层级内使用Custom Permissions做细粒度控制、把资源共享给组而非个人、以及使用AWS IAM作为额外权限边界。