Тайм-аут SQS от Lambda в VPC
У меня есть Lambda, которая должна быть в VPC, чтобы общаться с защищенными ресурсами, такими как RDS и AWSDocumentDB. Он также должен иметь возможность видеть внешний мир для некоторых вызовов сторонних API. Для этого я использовал мастер VPC для создания VPC с общедоступными и частными подсетями. Мастер также создал и подключил Интернет-шлюз.
После этого я подключил Lambda, экземпляр RDS и кластер DocumentDb к VPC. Однако с тех пор я не мог разговаривать со своими очередями SQS из моей лямбда-выражения, используя NodeJS aws-sdk.
Я хочу добавить, что я прочитал и реализовал некоторые моменты из: AWS Lambda: Невозможно получить доступ к очереди SQS из функции Lambda с доступом VPC, однако я все еще не могу подключиться.
Вот что у меня есть:
VPC:
- VPC имеет общедоступные и частные подсети, а также шлюз IG. Я использовал мастера для его создания. Я не понимаю здесь оснований.
- Конфигурация VPC (извините, это ссылка, я пока не могу встроить).
- CIDR's - мастер создал весь блок, кроме последнего. Я не уверен, правильно ли я сделал это или это даже важно, поскольку мастер заставил меня создать хотя бы один, и я сделал это, чтобы избежать перекрытия IP-адресов.
- Поскольку это проект разработки / прототипа, группа безопасности, прикрепленная к VPC, «широко открыта». Все входящие и исходящие разрешены.
- Сообщите мне, какую еще конфигурацию VPC показать, поскольку я не уверен, что полезно
Конечная точка службы:
- Я попытался создать конечную точку службы для SQS в соответствии со статьей, указанной выше, вот что у меня есть: конфигурация конечной точки.
- Я расскажу больше о том, как я это использую, в разделе «Лямбда».
- Конечная точка подключена к VPC
Лямбда:
- У меня есть лямбда, подключенная к VPC, как показано здесь .
- Это позволяет мне общаться с общедоступными сторонними API и моими защищенными ресурсами. Я надеялся, что наличие широко открытой SG все равно позволит моей лямбде общаться с SQS, но время ожидания истекает.
- Я не уверен, какой URL использовать в моей Lambda для моей конечной точки. Пример здесь:https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-sending-messages-from-vpc.html похоже, что он все еще использует региональную конечную точку.
Код
Вот как выглядит вызов SQS из моего кода:
-
const {SQS} = require('aws-sdk'); // Constructor Init const sqs = new SQS({ apiVersion: '2012-11-05', endpoint: 'https://sqs.us-west-2.amazonaws.com', // not sure if this is 'invoking' the vpc endpoint or not region: 'us-west-2' }); // Send message await sqs.sendMessage({ MessageBody: 'Test body', QueueUrl: 'https://sqs.us-west-2.amazonaws.com/<rest of URI>', MessageAttributes: {...someAttrs} }).promise();
-
Благодарю за любую помощь, дайте мне знать, какую еще информацию я могу предоставить.
Благодаря!
** Редактировать **
Я также должен упомянуть, что, чтобы обойти всю эту проблему, я начал использовать SQS в качестве Lambda Destination. Хотя это вводит сообщения в целевую очередь, это, вероятно, не будет масштабироваться с моим вариантом использования. При необходимости я могу более подробно остановиться на этом, поскольку это не полностью относится к фактическому вопросу.
** РЕДАКТИРОВАТЬ 31.08.20 **
Спасибо за все ответы, это было большим подспорьем и привело меня к решению. Я скажу, что всем, кто найдет этот пост, стоит сначала посмотреть:
https://www.youtube.com/watch?v=JcRKdEP94jM
Это то, что я хотел бы найти до того, как начал все это, потому что, хотя он специально нацелен на предоставление доступа к Интернету лямбда-выражениями, он проходит через процесс сопоставления IG и Nats с подсетями, что на самом деле является местом, где я неправильно настраивал свой vpc. В этом видео я воссоздал весь свой VPC, и теперь он намного чище и проще соединить точки. 10/10 рекомендую.
Еще раз спасибо!
Ответы
Я догадываюсь, что где-то в вашей сетевой конфигурации отсутствует правило - пакеты отбрасываются либо к вашему SQS, либо на обратном пути (оба требуют продуманного шага за шагом).
На ум приходят три вещи:
- Маршрутизация: убедитесь, что в подсетях и таблицах маршрутизации есть соответствующие маршруты для получения пакетов обратно в вашу частную подсеть из той, где находится конечная точка SQS.
- Группы безопасности - внимательно посмотрите на каждую задействованную SG. SQS может быть, например, в SG, которая ограничивает доступ к нему.
- Сетевые ACL - они не сохраняют состояние, поэтому вам нужно убедиться, что обе стороны открыты, и помните, что в большинстве случаев будут задействованы случайные номера портов, возвращающихся к запрашивающему.
Удачи!
Функция AWS Lambda должна быть подключена к частной подсети в VPC.
Amazon SQS находится в Интернете, поэтому для функции Lambda необходим способ доступа к конечной точке SQS.
Вариант 1: конечная точка VPC
VPC Endpoint для Amazon SQS может обеспечить прямую связь между VPC и конечной точкой SQS, без необходимости доступа в Интернет. После создания VPC будет автоматически отправлять запросы SQS через конечную точку VPC. Это хороший простой вариант.
Вариант 2: шлюз NAT
Если у вас есть дополнительные ресурсы в частной подсети, для которых требуется доступ в Интернет, вы можете рассмотреть возможность размещения шлюза NAT в общедоступной подсети . Для частных подсетей потребуется запись в таблице маршрутов, которая направляет интернет-трафик ( 0.0.0.0/0) на шлюз NAT.
Взимается дополнительная плата.
Вариант 3: назначение лямбда-выражения
Если у вас есть функция Lambda, успешно передающая SQS через Lambda Destination, то это звучит как отличный вариант ! Я не пробовал, но похоже, что служба Lambda отвечает за отправку вывода напрямую в SQS, без необходимости проходить через VPC или Интернет. Если это работает, я настоятельно рекомендую продолжать его использовать. Я не вижу проблем с масштабированием при использовании этого метода. Однако обратите внимание, что он работает только для асинхронных вызовов Lambda и не будет работать, например, при синхронном вызове функции или при нажатии кнопки Test .