借助访问控制 RAM 的 RAM 用户，您可以实现权限分割的目的，按需为子账号赋予不同权限，并避免因暴露阿里云账号（主账号）密钥造成的安全风险。
以下是需用到访问控制 RAM 的典型场景。
借助 RAM 用户实现分权
企业 A 的某个项目（Project-X）上云，购买了多种阿里云产品，例如：ECS 实例、RDS 实例、SLB 实例、OSS 存储空间等。项目里有多个员工需要操作这些云资源，由于每个员工的工作职责不同，需要的权限也不一样。企业 A 希望能够达到以下要求：
出于安全或信任的考虑，A 不希望将云账号密钥直接透露给员工，而希望能给员工创建独立账号。
用户账号只能在授权的前提下操作资源。A 随时可以撤销用户账号身上的权限，也可以随时删除其创建的用户账号。
不需要对用户账号进行独立的计量计费，所有开销都由 A 来承担。
针对以上需求，可以借助 RAM 的授权管理功能实现用户分权及资源统一管理。
借助 RAM 角色实现跨账号访问资源
云账号 A 和云账号 B 分别代表不同的企业。A 购买了多种云资源来开展业务，例如：ECS 实例、RDS 实例、SLB 实例、OSS 存储空间等。
企业 A 希望能专注于业务系统，而将云资源运维、监控、管理等任务授权给企业 B。
企业 B 还可以进一步将 A 的资源访问权限分配给 B 的某一个或多个员工，B 可以精细控制其员工对资源的操作权限。
如果 A 和 B 的这种运维合同关系终止，A 随时可以撤销对 B 的授权。
针对以上需求，可以借助 RAM 角色实现跨账号授权及资源访问的控制。
借助 RAM 服务角色实现动态访问云服务
如果您购买了 ECS 实例，并且打算在 ECS 中部署企业的应用程序，而这些应用程序需要使用 Access Key 访问其他云服务 API，那么有两种做法：
将 Access Key 直接嵌入代码。
将 Access Key 保存在应用程序的配置文件中。
然而，这两种做法会带来两个问题：
保密性问题：如果 Access Key 以明文形式存在于 ECS 实例中，则可能随着快照、镜像及镜像创建出来的实例被泄露。
运维难问题：由于 Access Key 存在于实例中，如果要更换 Access Key（例如周期性轮转或切换用户身份），那么需要对每个实例和镜像进行更新并重新部署，这会增加实例和镜像管理的复杂性。
ECS 服务结合 RAM 提供的访问控制能力，允许给每一个 ECS 实例（即用户应用程序的运行环境）配置一个拥有合适权限的 RAM 角色身份，应用程序通过获取该角色身份的动态令牌来访问云服务 API。
智能顾问的权限策略
Advisor 支持的系统权限策略为：
AliyunAdvisorFullAccess：管理智能顾问（Advisor）的权限，包含编辑/设置操作权限。
AliyunAdvisorReadOnlyAccess：只读访问智能顾问（Advisor）的权限。