跨账号AWS Lambda向SQS发消息权限配置报错求助

你已经完成了基础的权限配置，但还是遇到了跨账号访问的权限拒绝问题，结合报错里提到的「访问https://queue.amazonaws.com/被拒」，我整理了几个针对性的排查和解决方向：

1. 修正SQS Endpoint的使用格式 #

你的报错显示请求发到了通用的queue.amazonaws.com，但跨账号且启用KMS加密的SQS队列必须使用区域特定的Endpoint，正确格式应该是：

https://sqs.us-east-1.amazonaws.com/<sqs-account-id>/<queue-name>

请检查Lambda代码中调用SendMessage时使用的Endpoint是否符合这个格式——误用通用Endpoint会导致请求路由错误，进而触发权限校验失败。

2. 验证SQS访问策略的Principal准确性 #

确认SQS访问策略中指定的Lambda角色ARN完全正确：

• 仔细核对账号ID、角色名称的拼写（包括大小写、特殊字符）
• 如果角色ARN无误，可临时将Principal替换为Lambda所在账号的根ARN（arn:aws:iam::<lambda-account-id>:root）做测试，排查是否是角色ARN的识别问题（测试后记得改回角色ARN，遵循最小权限原则）

3. 补充KMS密钥的必要权限 #

虽然你已经给Lambda角色授权了KMS权限，但针对SQS加密场景，需要确保KMS密钥策略中明确允许该角色执行：

• kms:GenerateDataKey：发送消息时，SQS需要用这个操作生成数据密钥来加密消息体
  同时确认SQS队列的加密配置中指定的KMS密钥ARN，和你配置权限的密钥完全一致。

4. 检查Lambda角色权限的Resource范围 #

查看Lambda角色的权限策略中，sqs:SendMessage对应的Resource是否是SQS队列的完整ARN：

arn:aws:sqs:us-east-1:<sqs-account-id>:<queue-name>

如果Resource配置有误（比如账号ID写错），也会直接导致权限拒绝。

5. 用CLI测试权限定位问题 #

在Lambda所在账号，切换到对应的执行角色，用AWS CLI执行以下命令测试：

aws sqs send-message --queue-url https://sqs.us-east-1.amazonaws.com/<sqs-account-id>/<queue-name> --message-body "test" --region us-east-1

如果CLI执行成功，说明权限配置没问题，问题出在Lambda代码的Endpoint或参数配置；如果CLI也报错，再回到SQS访问策略、KMS密钥策略、Lambda角色权限逐一核对细节。

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