AWS authorization failed解决方案：通过CloudWatch日志和requestId定位缺失权限

1. 现有requestId可直接查询到具体缺失权限 #

你获取到的requestId7f09cdeb-cd2c-4c47-b6eb-ae1ed3bf8aca可以直接用来定位权限问题，操作步骤如下：

• 打开AWS控制台的CloudTrail服务，进入「事件历史」页面
• 筛选条件选择「请求ID」，粘贴对应的requestId进行检索
• 找到匹配的403响应事件后，查看事件详情的errorCode、errorMessage字段，会直接标注缺失的具体权限动作（例如ecs:RunTask、dynamodb:Query等），同时会展示请求发起身份、被访问资源的ARN等完整上下文

你目前贴出的是应用层封装后的报错，本身没有携带AWS返回的权限细节，需要通过上述步骤查询原始事件：

{
    "errorType": "Forbidden",
    "errorMessage": "AWS authorization failed",
    "code": "Forbidden",
    "message": "AWS authorization failed",
    "time": "2021-09-28T07:52:25.809Z",
    "requestId": "7f09cdeb-cd2c-4c47-b6eb-ae1ed3bf8aca",
    "statusCode": 403,
    "retryable": false,
    "retryDelay": 13.803204907216827,
    "stack": [
        "Forbidden: AWS authorization failed"
    ]
}

2. 直接从CloudWatch日志获取权限细节的配置方法 #

如果需要后续直接在CloudWatch中就能看到缺失的权限信息，不需要每次跳转CloudTrail查询，可以做如下配置：

• 调整对应服务的日志级别：将你使用的AWS服务（如API Gateway、Lambda、S3等）的访问日志级别调整为INFO或DEBUG，开启授权失败详情投递到CloudWatch的配置，后续403报错会直接携带权限缺失信息写入日志
• 开启AWS SDK日志输出：如果是应用内调用AWS SDK触发的报错，在SDK初始化时开启请求日志打印，SDK返回的原始AccessDenied错误会包含完整的权限缺失描述，随应用日志上报到CloudWatch后可直接查看

3. 常见问题 #

• 如果CloudTrail中检索不到对应requestId的事件，确认CloudTrail跟踪的覆盖范围包含请求所在的AWS区域，且事件未超出配置的保留周期
• 跨账户请求的授权报错，需要到请求接收方的AWS账户下查询对应CloudTrail事件才能拿到完整的权限详情

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