Управление / создание цепочки VPC и лямбда без VPC для обработки запроса REST шлюза API - PullRequest
0 голосов
/ 21 октября 2019

У меня есть следующие настройки AWS:

  • Шлюз API (REST) ​​
  • VPC "X" для частных ресурсов
  • Лямбды, запущенные в VPC X для запросачастные ресурсы
  • VPC "Y" для кластера DB / RDS Aurora без сервера
  • Lambdas запрашивает кластер БД через API данных (т. е. нет необходимости запускать Lambdas в VPC Y)

Когда запрос поступает на одну из конечных точек REST моего шлюза API, я хочу запустить лямбда-запрос для частных ресурсов в VPC X, а затем запустить другую лямбда-фильтр для фильтрации результатов первой лямбды на основе информации, доступной вБД в VPC Y.

Это очень простой сценарий, но я пока не нашел решения, которым я полностью доволен, поэтому я хотел бы спросить ваши предложения здесь.
Я нашел похожие темы / сообщения, такие как , этот и , этот , но однозначного ответа нет, и с тех пор могут появиться некоторые новые функции AWS.

Опции, которые я рассмотрел:

  1. Шаговые функции
    • Шаговая функция казалась идеальной, пока я не понял, что их выполнение асинхронно.
    • Так что размещать их за синхронными конечными точками REST нехорошо.
    • Я знаю, что вы можете создать вторичную конечную точку для запроса результатов выполнения Step Function, но это создаст ненужную работу и испортит API.
    • Мой вариант использования - простое, короткое, синхронное выполнение.
  2. Соединить 2 лямбды через SNS / SQS
    • Мне нужно добавить конечную точку VPC для SQS / SNS в VPC X, и этосделать поток асинхронным, что та же проблема, что и с пошаговыми функциями.
  3. Одиночная лямбда
    • Это противоречит принципу, согласно которому лямбды несут ответственность только за одну вещь.
    • Это также не работает (из коробки), потому что, если я добавлю логику БД в Lambda в VPC X, запрос к API данных истечет, потому что у Lambda нетдоступ в Интернет.
  4. Одиночная Lambda с NAT / IGW
    • Чтобы решить проблему доступа к API данных, я мог бы разрешить доступ к Lambdas через Интернет в VPC X. Однако я не хочу этого делать, потому что я не хочу получать доступ к Интернету (за пределами AWS), и включение доступа к Интернету в качестве обходного пути не кажется хорошей идеей.
  5. Одиночная лямбда с пирингом VPC между X и Y
    • Для этого мне потребуется сбросить API данных и управлять явными соединениями с БД. Не очень хорошее решение.
  6. Лямбда-мастер / контроллер для вызова других лямбд
    • Мне нужно было бы создать лямбду-мастер / контроллер, которая запускается APIШлюз, который затем будет вызывать Lambda в VPC X (для доступа к частным ресурсам), и другой Lambda, который обращается к БД через API данных. Т.е. у меня было бы 3 лямбды.
    • В качестве альтернативы я мог бы сделать лямбду, обращающуюся к БД, мастером / контроллером, таким образом, у меня было бы только 2 лямбды, одна из которых вызывала бы другую (проще, но не так чисто).
    • Одна проблема с этим заключается в том, что мне пришлось бы заплатить почти двойную цену, потому что теперь ламбда-мастер / контроллер бездействуют, ожидая завершения выполнения других лямбд.
    • Кажется, это лучшее решение, но оно все еще не идеально.

Есть ли у подхода «6. Лямбда-мастер / контроллер для вызова других лямбд» какой-либо другой недостаток, кроме (почти удвоенных) затрат? Например, влияние на производительность вызова Lambdas из Lambdas, трудности с мониторингом или что-то еще?

Есть ли лучшее решение для этого простого варианта использования, чем # 6?

Спасибо!

...