Менеджер секретов очень медленно в EC2s через awscli и boto3
Я пишу API колбу в Pycharm. Когда я запускаю свой код локально, запросы с использованием boto3 для получения секретов от менеджера секретов занимают меньше секунды. Однако когда я помещаю свой код в EC2, это занимает около 3 минут (пробовал как в t2.micro, так и в m5.large).
Сначала я подумал, что это может быть проблема с Python, поэтому я запустил его в своих EC2 через awscli, используя:
aws secretsmanager get-secret-value --secret-id secretname
Это заняло около 3 минут. Почему это происходит? Разве это теоретически не должно быть быстрее в EC2, чем на моей локальной машине?
РЕДАКТИРОВАТЬ: Это происходит только тогда, когда EC2 внутри VPC отличается от VPC по умолчанию.
4 ответа
После почти двух месяцев борьбы с этой же проблемой на наших локальных машинах мы наконец-то достигли определенного прогресса.
Оказывается, проблема связана с IPv6.
Если вы используете IPv6, то домен диспетчера секретов будет преобразован в адрес IPv6. По какой-то причине клиент не может установить безопасное соединение с использованием IPv6. По истечении этого времени клиент возвращается к IPv4, а затем успешно.
Чтобы проверить, разрешаете ли вы IPv6-адрес, просто отправьте ping secretsmanager.us-east-1.amazonaws.com. Не беспокойтесь об ответе ping, вы просто хотите увидеть IP-адрес, к которому относится домен.
Чтобы решить эту проблему, у вас есть 3 варианта:
- Выясните свои проблемы с сетью. Это может быть что-то на вашей машине или маршрутизаторе. Если вы используете AWS VPC, проверьте таблицы маршрутизации и группы безопасности. Убедитесь, что вы разрешаете исходящий трафик IPv6 (::/0).
- Сократите время ожидания соединения, чтобы ускорить сбой вызова IPv6. Это сделает возврат к IPv4 раньше. Возможно, вы захотите дать лучшее значение времени ожидания, но общая идея состоит в том, чтобы добавить что-то вроде этого:
--cli-connect-timeout 1 - Отключить IPv6. Вы можете либо полностью отключить IPv6 на своем компьютере / маршрутизаторе, либо настроить свой компьютер так, чтобы он предпочитал IPv4 для этого конкретного адреса (см.: https://superuser.com/questions/436574/ipv4-vs-ipv6-priority-in-windows-7).
В конечном счете, вариант 1 является реальным решением, но, поскольку он настолько широк, другие могут быть проще.
Надеюсь, это поможет кому-то еще обрести немного здравомыслия, когда они достигнут этого.
У меня возникла эта проблема при работе из дома через VPN-клиент Cisco AnyConnect. Видимо блокирует что-нибудь IPv6.
Для меня решением было полностью отключить IPv6 на моем ноутбуке.
Для этого в macos:
networksetup -setv6off Wi-Fi # wireless
networksetup -setv6off Ethernet # wired
Чтобы снова включить:
networksetup -setv6automatic Wi-Fi # wireless
networksetup -setv6automatic Ethernet # wired
Я выполнил следующие команды со своего компьютера и с Amazon EC2 t2.nano экземпляр в ap-southeast-2 область, край:
aws secretsmanager create-secret --name foo --secret-string 'bar' --region ap-southeast-2
aws secretsmanager get-secret-value --secret-id foo --region ap-southeast-2
aws secretsmanager delete-secret --secret-id foo --region ap-southeast-2
В обоих случаях каждая команда возвращалась в течение секунды.
Дополнительно:
Чтобы проверить вашу ситуацию, я сделал следующее (в районе Сиднея):
- Создан новый VPC с помощью мастера VPC (просто общедоступная подсеть)
- Запущен новый экземпляр Amazon EC2 в новом VPC с ролью, предоставляющей разрешение на доступ к Secrets Manager
- Обновлен интерфейс командной строки AWS на экземпляре (установленная версия не знала о
secretsmanager - Запустил вышеуказанные команды
Они все вернулись немедленно.
Следовательно, проблема заключается в том, что связано с вашими экземплярами или вашим VPC.