如何理解AWS Service link role？其与Service role有何差异？

两者同属服务侧跨资源权限的身份载体，你已经掌握的「普通Service Role附加到服务后，服务即可执行角色策略定义的操作」是两类角色共有的底层逻辑，但两者的设计初衷、管控方式、适用场景有清晰的不可混淆的边界：

核心差异对比 #

• 创建主体与生命周期管控权完全不同
  普通Service Role是用户完全自主创建、全流程自控的角色：从信任策略编写、权限策略配置，到后续的权限调整、角色删除，所有操作都由用户主动发起，没有系统级的强制约束。比如你给自定义Lambda函数配置的、允许读写业务DynamoDB表的角色，就属于这类。
  Service Linked Role（SLR）是AWS平台预定义规则、系统自动生成的特殊角色：你不需要手动创建它，当你第一次启用某个AWS服务的内置跨权限功能时，系统会自动在你的账号下拉取对应规则的SLR实体，整个生成过程不需要你手动填配置，你也没法自主修改它的核心信任规则。这类角色的命名规则是官方固化的，通常带AWSServiceRoleFor固定前缀，很容易和用户手动创建的角色区分开。

• 策略的可修改权限边界不同
  普通Service Role的信任关系、权限范围是完全开放给用户调整的：你可以给同一个角色配置同时信任多个AWS服务主体，也可以根据需求随时追加、删除权限策略，没有官方侧的固化限制。
  SLR的基础信任策略、核心权限范围是被AWS官方固化的：你不能随意修改它的信任主体（比如不能把对应Lambda的SLR信任关系改成允许EC2调用），也不能绕过服务本身的功能逻辑随意删除角色——如果当前账号下还有正在运行的服务功能依赖这个SLR，系统会强制拦截删除操作。即便你手动给SLR追加额外权限，服务运行时也不会超出官方固化的权限范围去调用这些操作。

• 适用场景的明确划分
  普通Service Role只对应自定义的跨权限需求：所有你自己设计的、不在AWS服务官方内置功能范围内的跨服务/跨账号调用场景，都需要手动创建这类角色。比如你自己写脚本让EC2实例每天同步数据到外部S3桶、给自定义API网关配置调用后端Lambda的身份，全属于这类场景的范畴。
  Service Linked Role只对应服务内置标准化功能的权限承载：所有AWS服务自带的、开箱即用的功能背后的身份，全是对应的SLR。比如EC2 Auto Scaling的故障实例替换、CloudTrail的日志自动投递、GuardDuty的S3敏感数据扫描这些平台默认功能，运行时的调用身份全是自动生成的SLR，你不需要手动配置这类角色就能让内置功能跑通。

常见认知误区澄清 #

• 不要把SLR等同于“更严格的普通Service Role”：虽然两者底层都是带信任和权限策略的IAM角色结构，但在IAM管控台的分类里，SLR是独立于普通Service Role的单独分类，系统会自动识别所有平台生成的SLR，不会和你手动创建的角色混为一列。
• 不要尝试通过给SLR加权限实现自定义功能：SLR是服务内置功能的专属身份，服务代码只会调用官方定义好的操作集，你额外追加的权限不会被服务使用，反而会带来不必要的权限暴露风险。

内容的提问来源于stack exchange，提问作者vinSan