Step Functions以IAM_ROLE认证跨账号调用API Gateway 403问题咨询

数据老陈

2026-8-29

方案选型判断

方案2（Step Functions原生集成调用API Gateway）确实是更优选择，合理性如下：

无额外计算资源开销：不需要维护Lambda函数、不需要处理代码部署、冷启动、运行时补丁等运维工作，架构链路更短
原生能力覆盖通用需求：状态机自带的重试、超时、错误捕获、观测能力直接覆盖API调用的通用运维需求，不需要自定义代码重复实现
链路可观测性更好：API调用的请求、响应、错误信息直接关联到状态机执行记录，排查问题不需要跨服务跳转捞日志

*该选型适用边界：如果你的调用逻辑需要自定义复杂签名、特殊请求头处理、响应体的复杂格式转换，再考虑Lambda方案；常规跨账号IAM鉴权的API调用，原生集成完全满足需求。

403错误根因与修复方案

你当前报错的核心原因：配置AuthType: IAM_ROLE时没有指定要代入的跨账号角色ARN，Step Functions默认使用状态机自身的执行角色直接调用目标API，该角色不属于对方账号的授权范围，因此返回403，错误信息里显示的用户ARN就是你的状态机执行角色，可以直接验证这个判断。
按以下步骤修复配置：

修改状态机API调用任务参数，补充RoleArn字段，填入对方账号提供的可代入IAM角色完整ARN，正确配置示例：

{
  "Comment": "A description of my state machine",
  "StartAt": "API Gateway Invoke",
  "States": {
    "API Gateway Invoke": {
      "Type": "Task",
      "Resource": "arn:aws:states:::apigateway:invoke",
      "Parameters": {
        "ApiEndpoint": "https://{对方API ID}.execute-api.{region}.amazonaws.com",
        "Method": "GET",
        "Path": "/{your-api-path}",
        "AuthType": "IAM_ROLE",
        "RoleArn": "arn:aws:iam::{对方账号ID}:role/{对方提供的跨账号角色名}"
      },
      "End": true
    }
  }
}

*注意ApiEndpoint仅填写API域名部分，不要拼接接口路径；Path字段必须以/开头，否则会出现路径拼接错误导致调用失败。
2. 校验对方账号侧的跨账号角色信任策略：跨账号场景下，角色信任策略不能仅配置同账号服务主体，必须加入你方账号作为可信实体，信任策略示例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::{你的账号ID}:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

如果需要做权限收敛，可以在策略里加Condition，限制仅你的状态机执行角色可以代入该角色。
3. 校验对方账号API Gateway资源策略：必须允许该跨账号角色对目标API、方法、路径有execute-api:Invoke权限，策略片段示例：

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::{对方账号ID}:role/{跨账号角色名}"
  },
  "Action": "execute-api:Invoke",
  "Resource": "arn:aws:execute-api:{region}:{对方账号ID}:{API ID}/*/GET/{path}"
}

权限收敛：你之前给状态机执行角色加的全量API Gateway invoke权限属于多余配置，可以删除。跨账号调用场景下，你方执行角色只需要保留对目标跨账号角色的sts:AssumeRole权限即可，实际调用API的签名凭证来自代入后的跨账号角色，不需要你方角色本身有API Gateway的调用权限。

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