如何为多区域使用的IAM角色指定信任关系以解决CDK自动加服务区域后缀问题

• 该行为并非异常，是CDK内置的服务主体适配逻辑：CDK会针对部分支持区域化访问的AWS服务，自动在服务主体后拼接当前栈的部署区域，匹配区域服务的最小权限合规要求。该逻辑仅对states这类同时提供全局、区域两种主体格式的服务生效，lambda、apigateway等无对应区域后缀主体的服务不会触发拼接。
• IAM控制台手动创建角色时不会触发该自动拼接逻辑，因此生成的信任关系为无区域后缀的全局主体，和CDK默认生成的结果存在差异。
• IAM角色为全局资源，信任策略中无区域后缀的全局states.amazonaws.com主体，可被所有区域的Step Functions服务正常识别并扮演；带区域后缀的主体仅能匹配对应单区域的服务访问，反而会限制跨区域复用能力。

• 方法1：绕过CDK的ServicePrincipal自动适配逻辑，手动构造全局服务主体
  原写法会触发CDK的区域拼接逻辑：
  assumedBy: new ServicePrincipal('states.amazonaws.com')
  替换为通用Principal构造，完全跳过自动拼接规则：

  assumedBy: new iam.Principal({
    Service: 'states.amazonaws.com'
  })
  

• 方法2：如果希望保留ServicePrincipal构造类的其他能力，可显式覆盖默认区域参数
  传入全局标识作为区域值，阻止CDK拼接当前部署区域：

  assumedBy: new ServicePrincipal('states.amazonaws.com', {
    region: '*'
  })
  

  注：该写法最终生成的信任主体仍为无区域后缀的全局states.amazonaws.com，不会出现单区域限制。

• 部署完成后可进入IAM控制台检查角色信任关系，确认仅存在无区域后缀的states.amazonaws.com主体条目。
• 后续多区域业务栈通过Role.fromRoleArn()引用该角色时，所有区域的Step Functions服务均可正常扮演该角色，无跨区域权限问题。

内容的提问来源于stack exchange，提问作者zdenko.s