SQS加密配置疑问：为什么对接SNS需KMS CMK而Lambda无需

两种场景的核心差异是访问KMS密钥的身份逻辑完全不同：

• Lambda作为SQS触发器访问加密队列的权限逻辑
  Lambda拉取SQS消息时，使用你配置的Lambda执行角色作为身份凭证发起接口调用。AWS托管密钥aws/sqs的内置密钥策略默认允许同账户内持有SQS队列访问权限的IAM身份，隐式获得该密钥的kms:Encrypt、kms:Decrypt等必要操作权限，因此只要你的Lambda执行角色已经配置了SQS读写权限，就不需要额外配置KMS相关权限。
  额外说明：如果你给仅配置Lambda触发器的SQS队列使用客户托管密钥，仍然需要在密钥策略或Lambda执行角色的权限中添加对应KMS操作权限，因为客户托管密钥默认不会隐式授予同账户IAM身份的访问权限。
• SNS向加密SQS队列投递消息的权限逻辑
  SNS向订阅的SQS队列投递消息时，使用的是*SNS服务主体（sns.amazonaws.com）*作为身份凭证，而非你账户内的自定义IAM身份。AWS托管密钥的内置策略不允许跨服务的服务主体直接访问，且你无权修改AWS托管密钥的策略配置，因此必须使用支持自定义密钥策略的客户托管密钥，在策略中显式为SNS服务主体授予KMS操作权限，才能完成消息的正常投递。

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