Подключение к SMTP-серверу из AWS Lambda
В моей функции AWS Lambda время ожидания кода javascript истекает всякий раз, когда я пытаюсь использовать nodemailer для подключения к моему SMTP-серверу Amazon SES (порт 465). Однако, если я запускаю сценарий локально, он работает нормально, что наводит меня на мысль, что это либо проблема с лямбда-вызовом на SMTP-сервер, либо с SMTP-сервером, блокирующим лямбда-соединение от подключения - я подозреваю, что первое - проблема .
Я использую брандмауэр за своим дистрибутивом Cloudfront, но не думаю, что это применимо к входящим соединениям SES или исходящим лямбда-функциям. В VPC я вижу, что к экземпляру подключен интернет-шлюз. Исходящие соединения для группы безопасности разрешают всем протоколам доступ к 0.0.0.0/0, однако ACL выглядит странно, поскольку он одновременно разрешает и отклоняет все входящие / исходящие соединения:
В VPC я вижу перечисленные 6 подсетей, из которых для меня не очень очевидно, что именно они делают в общей схеме вещей.
В журналах я просто вижу Task timed out after 6.01 seconds
Есть идеи, как я могу получить дополнительную информацию о том, где происходит зависание?
Это ожидаемо.
Лямбда-функции в VPC не могут связываться с Интернетом (включая стандартные API-интерфейсы служб) с помощью Интернет-шлюза, поскольку Интернет-шлюз требует, чтобы внутренние устройства имели связанные общедоступные IP-адреса. Находиться в общедоступной подсети (где маршрут по умолчанию - Интернет-шлюз) недостаточно.
Важный
Если вашей лямбда-функции требуется доступ к Интернету, не подключайте ее к общедоступной подсети или к частной подсети без доступа к Интернету. Вместо этого подключайте его только к частным подсетям с доступом в Интернет через инстанс NAT или шлюз NAT Amazon VPC.
Устройство NAT - обычно NAT-шлюз - требуется, если рассматриваемая служба не поддерживает Конечные точки VPC (чего в настоящее время нет в SES).
Поместите шлюз NAT в общедоступную подсеть (чтобы он мог выходить в Интернет с помощью Интернет-шлюза), а затем создайте одну или несколько частных подсетей, указав их маршрут по умолчанию на шлюз NAT.
Шлюз NAT - это новая альтернатива Экземпляр NAT, который является экземпляром EC2, предназначенным для той же цели. Раньше это был единственный способ предоставить необходимую службу NAT. В отличие от шлюза NAT, который управляется AWS и является отказоустойчивым, экземпляр NAT представляет собой потенциальную единую точку отказа (но имеет более низкую сопутствующую стоимость).
Или вы можете переместить функцию Lambda из VPC, если она не требует других ресурсов VPC.
Сетевой ACL разрешает все и все запрещает - это нормально, потому что правила обрабатываются по порядку. Это последнее правило является поведением по умолчанию, которое будет применяться, если правило разрешения будет удалено. В основном это визуальный сигнал, напоминающий вам, почему NACL не работает, если вы удалите другие правила. В противном случае пользователи могли бы предположить, что, поскольку они явно не отрицали что-то, это должно быть разрешено.
Каждый сетевой ACL также включает правило, номер правила которого отмечен звездочкой. Это правило гарантирует, что если пакет не соответствует ни одному из других пронумерованных правил, он будет отклонен. Вы не можете изменить или удалить это правило.
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html