通过 awscli 和 boto3 在 EC2s 中的 Secrets manager 非常慢

Question

我正在 pycharm 中编写一个烧瓶 API。当我在本地运行我的代码时，使用 boto3 从机密管理器获取机密的请求不到一秒钟。但是，当我将代码放在 EC2 上时，大约需要 3 分钟（在 t2.micro 和 m5.large 中都尝试过）。

起初我认为这可能是 Python 问题，所以我使用以下命令通过 awscli 在我的 EC2 中运行它：

aws secretsmanager get-secret-value --secret-id secretname

大约用了 3 分钟。为什么会发生这种情况？理论上，这在 EC2 中不应该比在我的本地机器中更快吗？

编辑：这仅在 EC2 位于与默认 VPC 不同的 VPC 内时发生。

Answer 1

在我们的本地机器上解决了同样的问题近两个月后，我们今天终于取得了一些进展。

事实证明，问题与 IPv6 有关。

如果您使用的是 IPv6，那么机密管理器域将解析为 IPv6 地址。由于某种原因，cli 无法使用 IPv6 建立安全连接。超时后，cli 回退到 IPv4，然后成功。

要验证您是否正在解析 IPv6 地址，只需 ping secretsmanager.us-east-1.amazonaws.com。不要担心 ping 响应，您只想查看域解析到的 IP 地址。

要解决此问题，您现在有 3 个选项：

1. 找出您的网络问题。这可能是你的机器或路由器上的东西。如果在 AWS VPC 中，请检查您的路由表和安全组。确保允许出站 IPv6 流量 (::/0)。
2. 减少 cli 连接超时以使 IPv6 调用更快失败。这将使 IPv4 回退更快发生。您可能希望提供更好的超时值，但总体思路是添加如下内容：--cli-connect-timeout 1
3. 禁用 IPv6。您可以在您的机器/路由器上完全禁用 IPv6，或者您可以调整您的机器以首选此特定地址的 IPv4（请参阅：https : //superuser.com/questions/436574/ipv4-vs-ipv6-priority-in-窗户-7）。

最终，选项 1 是真正的解决方案，但由于它是如此广泛，其他选项可能更容易。

希望这有助于其他人在遇到此问题时保持一点理智。

Answer 2

我在家里通过 Cisco AnyConnect VPN 客户端工作时遇到了这个问题。显然它会阻止任何 IPv6 内容。

我的解决方案是在我的笔记本电脑上完全禁用 IPv6。

对于 Mac 系统执行此操作：

networksetup -setv6off Wi-Fi  # wireless
networksetup -setv6off Ethernet  # wired

重新启用：

networksetup -setv6automatic Wi-Fi  # wireless
networksetup -setv6automatic Ethernet  # wired