定期检查AssumeRole的ARN，避免超出配额限制。
【以下的问题经过翻译处理】 你好，
我们需要定期检查所有为我们授予AssumeRole权限的客户，以确保他们未弃用权限/角色/用户。考虑到配额限制，最好的做法是什么？我在考虑：
- 对于每个客户账户（ARN）
- 为该ARN执行AssumeRole
- 执行一些“ping”操作（例如，DescribeRegions）
- 延迟一下，以免超过服务的配额限制（例如，DescribeRegions每秒有20个操作次数的限制）。
不清楚在进行AssumeRole时如何应用服务配额限制。这是应用于我们（服务）帐户还是客户（消费）帐户？
STS操作的限制是什么，特别是AssumeRole？在文档中没有太多相关信息，或者我漏看了。
是否有一些始终可用的“ping”操作我们可以调用，或一些STS API请求，可以确认ARN是否有效？
是否有我们可以检查配额限制消耗情况的地方，以便我们可以优化后台检查程序？
谢谢。
- 最新
- 投票最多
- 评论最多
【以下的回答经过翻译处理】 如果您执行了sts:AssumeRole调用，将会成功或者您会收到Access denied的错误信息，因此只需要做一个Try/Catch即可。因此，您已经知道角色是否存在以及是否可以访问它，因此不需要进行Ping。
如果您想确认角色的访问权限，最好的方法是使用客户账户中的角色来描述自身并查看其策略。（请注意拒绝语句和权限边界）。
sts:AssumeRole调用计入您的账户，在您消费的角色上执行的任何操作都将计入您消费的角色的账户中。
我无法找到任何关于sts:AssumeRole调用的官方限制，但AWS在某些服务上有动态限制（在您使用后会更改）。
但是，STS是AWS的核心构建模块，因此它应该能够处理您抛出的任何问题。但是，您应该始终在所有AWS SDK客户端中设置重试机制，这是一个Python Boto3示例，但是每种语言都有其自己的相同逻辑实现。您需要使用标准模式：)https://boto3.amazonaws.com/v1/documentation/api/latest/guide/retries.html
请注意，重试可能会导致长时间执行，因此与lambda结合使用时，您经常会遇到“超时”掩盖基础AWS调用的情况。因此，请配合使用lambda日志记录和执行时间。
希望这可以帮助您，祝您好运！