无AWS-SDK调用CloudWatch Logs接口所需请求头与API版本

1. Content-Type头的必要性 #

Content-Type必须同时加入请求头，且纳入Sigv4签名的已签名头部列表。
你遇到的两个错误的原因对应如下：

• 带Content-Type报签名不匹配：是因为你计算Sigv4签名时未将Content-Type纳入已签名头部，或头部值、大小写与实际请求发送的Content-Type存在偏差
• 移除Content-Type报UnknownOperationException：是CloudWatch Logs的JSON-RPC接口强制要求Content-Type: application/x-amz-json-1.1才能识别请求对应的接口方法，缺失就无法匹配到具体操作

2. CloudWatch Logs 接口必填请求头 #

以下请求头除Authorization外，全部需要纳入Sigv4签名的已签名头部列表：

• Host：固定格式为logs.<region>.amazonaws.com
• Content-Type：固定值为application/x-amz-json-1.1
• X-Amz-Date：符合ISO 8601规范的UTC时间，格式示例20240520T143000Z
• X-Amz-Target：对应接口的目标标识，CreateLogStream为Logs_20140328.CreateLogStream，PutLogEvents为Logs_20140328.PutLogEvents
• X-Amz-Content-Sha256：请求体的SHA256哈希值，空请求体对应固定值e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
• Authorization：Sigv4计算生成的签名字符串，无需参与签名计算

若使用AWS临时凭证，还需额外添加X-Amz-Security-Token头，且该头也需要纳入已签名头部列表。

3. 对应API版本号说明 #

你当前使用X-Amz-Target调用JSON-RPC格式的CloudWatch Logs接口时，不需要在URL中添加Action和version查询参数，接口版本已经通过X-Amz-Target前缀的Logs_20140328声明，固定为2014-03-28。
你之前URL拼接查询参数的写法反而会导致签名不匹配：Sigv4签名计算时需要将所有URL查询参数按ASCII顺序编码，如果加了Action、version参数却未纳入签名计算，就会返回400签名错误。正确的请求URL为https://logs.<region>.amazonaws.com/，无需携带任何查询参数。

签名错误补充排查点 #

如果确认密钥、头部都无问题仍报签名不匹配，可检查以下规则：

• 计算canonical headers时，所有头部key需转为小写，value需修剪掉首尾多余空格
• 已签名头部列表需要按ASCII码顺序排列，示例：host;content-type;x-amz-content-sha256;x-amz-date;x-amz-target
• 签名计算用的请求路径、查询参数需和实际发起请求的内容完全一致

内容的提问来源于stack exchange，提问作者Sravan Reddy Jeedipelly