Подключение к 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
Любая идея, как я могу получить больше информации о том, где зависание?
1 ответ
Это ожидается.
Лямбда-функции в VPC не могут обмениваться данными с Интернетом (включая стандартные сервисные API) с помощью интернет-шлюза, поскольку интернет-шлюз требует, чтобы внутренние устройства имели связанные публичные IP-адреса. Находясь в общедоступной подсети (где по умолчанию используется Интернет-шлюз), недостаточно.
Важный
Если вашей функции Lambda требуется доступ к Интернету, не подключайте ее к общедоступной подсети или к частной подсети без доступа в интернет. Вместо этого подключите его только к частным подсетям с доступом к Интернету через экземпляр NAT или шлюз Amazon VPC NAT.
Требуется устройство NAT - обычно шлюз NAT - если только рассматриваемая служба не поддерживает конечные точки VPC (чего в настоящее время нет в SES).
Разместите шлюз NAT в общедоступной подсети (чтобы он мог выходить в Интернет с помощью интернет-шлюза), а затем создайте одну или несколько частных подсетей, указывая их маршрут по умолчанию к шлюзу NAT.
Шлюз NAT является более новой альтернативой экземпляру NAT, который является экземпляром EC2, предназначенным для той же цели. Раньше это был единственный способ получить доступ к необходимой службе NAT. В отличие от шлюза NAT, который управляется AWS и является отказоустойчивым, экземпляр NAT представляет потенциальную единственную точку отказа (но имеет более низкую связанную стоимость).
Или вы можете переместить функцию Lambda из VPC, если она не требует других ресурсов VPC.
Сетевой ACL, разрешающий и запрещающий все, является нормальным, поскольку правила обрабатываются по порядку. Это последнее правило является поведением по умолчанию, которое применяется при удалении правила Allow. Это в основном визуальная подсказка, чтобы напомнить вам, почему NACL не работает, если вы удалите другие правила. В противном случае пользователи могут предположить, что, поскольку они явно не отрицают что-либо, это должно быть разрешено.
Каждый сетевой ACL-список также включает в себя правило, номером которого является звездочка. Это правило гарантирует, что если пакет не соответствует ни одному из других пронумерованных правил, он будет отклонен. Вы не можете изменить или удалить это правило.
https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html