SNS в SQS против Direct SQS, помещенных в Lambda @ Edge Applications

Question

Я изучаю использование Lambda @ Edge для помещения событий, сгенерированных из внешних источников, во внутреннюю очередь SQS. Лямбда просто нуждается в том, чтобы преобразовать ее, когда это необходимо, снять руку и уйти. Я бы хотел, чтобы это было как можно быстрее, поэтому мой вопрос: есть ли польза от использования SNS в дополнение к SQS или мне просто нужно использовать SQS?

Другими словами, учитывая эти две конфигурации, одна из них будет более производительной для конечного пользователя ?

A) Запрос поступает в Lambda @ Edge, лямбда преобразует запрос и отправляет событие в SNS, SNS помещает событие в SQS.

B) Запрос поступает в Lambds @ Edge, лямбда преобразует запрос и напрямую помещает событие в SQS.

Edit:

Я говорю о кросс-регионе.

Answer 1

Межрегиональный, SNS-to-SQS будет значительно быстрее, , если настроен, как описано здесь.

Оптимальная конфигурация будет состоять в том, чтобы создать тему SNS с одинаковым именем в в каждом регионе AWS и подписать вашу очередь SQS (которая предположительно представляет собой одну очередь в одном регионе) на все из этих тем.

Когда запускается триггер Lambda @ Edge, этот код выполняется в области, ближайшей к средству просмотра, и process.env.AWS_REGION сообщит вам, что это за область, для каждого вызова.

Используйте эту информацию для инициализации клиента SNS и отправки сообщения в тему SNS в этом регионе . SNS немедленно примет сообщение, но доставит его асинхронно (с вашей точки зрения), межрегионально, в очередь SQS - так что это не будет препятствовать завершению вашей функции. Выполнение любого межрегионального запроса непосредственно из триггерной функции Lambda, будь то SQS или SNS, увеличит вашу задержку.