我试图在Lambda中使用boto3将消息发布到SNS主题，如下所示：
def publish_msg(msg, bar):
response = SNS.publish(
TopicArn='blah_blah_arn',
Message=msg,
MessageAttributes={
'foo': {
'DataType': 'String',
'StringValue': bar
}
}
)
这没有用，因为它不断给我一个身份验证错误，它是这样的：
Error publishing message because lambda_fn_role doesn't have the permissions to invoke SNS:Publish on resource blah_blah_arn
但是我确定我对该功能的策略是正确的，因此我将TopicARN更改为TargetARN并成功了！
所以我的问题是：主题和目标ARN有什么区别？什么时候应该使用另一个？
非常感激！
事实证明，这里的问题并不像看起来那样。
TopicArn而TargetArn实际上是可以互换的，在这种情况下。（为什么有两种可能的方法来传递主题ARN？SNS最初仅支持将主题作为目标，但现在支持其他类型的东西，因此这很可能是API向后兼容的一种情况，AWS通常非常擅长此功能。）
tl; dr：有时，当修改Lambda执行角色使用的IAM策略时，Lambda函数的行为就好像发生了策略更改一样。
它看起来只有在从一个更改为另一个后才起作用的原因（在某种程度上）与更新Lambda函数的代码时发生的情况有关。
Lambda服务管理着运行您的代码的容器，每个容器一次只能运行一个并发调用函数。后续调用可以重用相同的容器...但是仅当与该函数关联的代码相同且不变时。
更新功能代码，然后再次运行该功能（第一次使用新代码），可以确保您位于一个以前未使用过的新容器中。
新容器必须使用AssumeRoleAWS Security Token Service中的Action来获取Lambda Execution角色的临时凭证，该操作提供了临时的AWS-Access-Key-ID和密钥以及会话令牌。Lambda将它们存储在，和中的环境变量中AWS_ACCESS_KEY_ID，您函数中的AWS-SDK（在此示例中用于调用其他服务，例如SNS）将其拾取并用于对请求进行签名。AWS_SECRET_ACCESS_KEYAWS_SESSION_TOKEN
OP遇到的是这种设置中的一个古怪之处。IAM或STS中的某些内容会导致AWS系统内部缓存或过时的数据-SNS:Publish尚不可见的一项策略（或策略的最新版本），该策略是允许Lambda执行角色针对相关主题执行操作的必要条件一个需要查看它的组件，以便允许执行该操作。
目前尚不清楚该缓存在何处发生。Lambda当然会缓存临时凭证，但是EC2元数据服务也会缓存，而且行为良好的客户端也会缓存，因为当临时凭证仍然有效时，继续向STS发出请求是没有意义的。我不相信凭据本身的缓存是原因（尽管是原因）。
STS凭证是一个黑匣子，尤其是“会话令牌”。它是否包含加密数据？还是只是一个较大的随机值，而实际上只是一个没有内在含义的符号“令牌”？其实并不重要，但是重点是没有明确记录在案。
IAM是一个庞大的分布式系统，因此，它的确会偶尔出现“最终一致性”问题。
但是，以某种方式，创建一个新的Lambda容器（必须必须对STS进行新调用）似乎具有缓存无效化的副作用，这使当前执行角色的IAM策略在某些情况下不可用在新的部署中工作。
尝试执行给定的操作后，有时会弹出该对话框，但它失败了，并且您意识到需要编辑足以使该操作生效的IAM策略。因此，您编辑了该策略，但是随后的尝试仍然失败，但是该策略似乎仍然有效，因此您无法弄清为什么它不起作用，您将手扔在空中，向John Rotenstein发送消息，告知您在机智的尽头...然后，在失望的夜晚放弃后，您第二天早晨返回进一步进行故障排除，发现它突然开始工作。
推测这与旧的执行角色临时凭证有关，这可能是由于容器由于不活动而被修剪并替换了，或者仅仅是因为临时凭证的寿命有限...但是目前尚不清楚是否刷新STS令牌解决方案的必要部分，或者是否只是在侧面IAM中解决了一个僵局的副作用。
无论采用哪种方式，重新部署Lambda函数以测试代码更改都可能具有与此处相同的效果。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句