API Gateway路由请求至SQS时出现UnknownOperationException的排查求助

根据你遇到的404和UnknownOperationException错误，我整理了几个关键排查方向，你可以逐一验证：

• 确认SQS端点URL的准确性
  日志里的请求URL是https://sqs.ca-central-1.amazonaws.com/XXXXXXXX/XXXX，这里需要检查：

  • 账号ID（XXXXXXXX部分）是否和你的AWS账号ID完全一致，有没有多写、少写数字
  • 队列名称（XXXX部分）是否和目标SQS队列的名称完全匹配，注意SQS队列名称区分大小写
  • 区域标识ca-central-1是否和队列实际所在区域一致，SQS是区域级服务，跨区域访问会直接返回404

• 验证API Gateway集成的请求方法和参数
  SQS的SendMessage操作要求使用POST方法，并且必须指定Action=SendMessage参数。你需要确认：

  • API Gateway的集成请求是否设置为POST方法
  • 如果是HTTP集成，是否在请求参数或URL中明确包含了Action=SendMessage；如果是AWS服务集成，是否正确选择了SendMessage作为目标操作
  • 请求体的映射逻辑是否正确，比如是否将API的请求内容正确映射到SQS要求的MessageBody参数

• 检查IAM角色的配置有效性
  虽然你创建了角色，但需要确保配置完全生效：

  • API Gateway的集成设置是否正确关联了这个IAM角色，没有选错角色
  • 角色的信任策略是否允许apigateway.amazonaws.com作为可信实体，否则API Gateway无法扮演该角色发起请求
  • 角色的权限策略是否明确允许sqs:SendMessage动作，并且资源是目标队列的完整ARN（比如arn:aws:sqs:ca-central-1:XXXXXXXX:XXXX），避免使用范围过大的通配符或错误的ARN

• 确认集成类型是否正确
  建议优先使用API Gateway的AWS服务集成（而非自定义HTTP集成）对接SQS，这种方式会由AWS自动处理签名、区域匹配和参数格式，大幅减少手动配置错误。如果使用HTTP集成，需要手动处理AWS签名、Content-Type设置等细节，更容易出现问题。

• 查看详细的CloudWatch日志
  开启API Gateway的全量日志记录，在CloudWatch中查看更细致的请求/响应细节：

  • 请求签名是否验证通过
  • 请求头是否包含正确的Content-Type（通常为application/x-www-form-urlencoded或application/json，取决于参数传递方式）
  • 是否有隐藏的参数缺失、格式错误等信息

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