Затраты, связанные с ошибкой повторной попытки AWS Lambda?

Согласно документам AWS:

• Источники событий, не основанные на потоках: например, S3, API Gateway и т. д.

  • Синхронный вызов: если вы вызвали Lambda с помощью SDK или API Gateway, в случае возникновения исключения вы должны будете решить, следует ли / когда / как повторить запрос.

  • Асинхронный вызов: если лямбда-функция была запущена посредством асинхронного вызова (например, S3), она автоматически повторит вызов дважды с задержками между попытками. Если вы указали очередь недоставленных сообщений, то событие сбоя отправляется в SQS / SNS. Если DLQ не был указан, событие будет отклонено.

• Источники событий на основе потоков: например DynamoDB и Kinesis.

  • If a Lambda function fails, it will continue to try until the data expires (max of 7 days for Kinesis). It retries following a exponential backoff with the ceiling of 1 minute between two retries. You will pay for all retries, but you can create an alert to trigger and stop the stream when the source is offline.

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

Вопрос:

В частности, когда моя Lambda получает события Kinesis и записывает данные в другую службу ... но другая служба отключается на некоторое время (например, несколько часов) ... моя Lambda будет продолжать получать вызовы (и выкидывая ошибки) с постоянной скоростью?

Лямбда-повтор - это хорошо, потому что я хочу гарантированную доставку событий, но в идеале в этой ситуации я также не хочу, чтобы мне выставляли счет по высокой ставке, когда моя лямбда-функция становится постоянно неуспешной в течение некоторого времени.

Ответ:

Если функция начинает выполняться, но терпит неудачу из-за зависимостей от нисходящего потока, вам будет выставлен счет за время, в течение которого выполнялась функция. Лямбда экспоненциально отключается в случае сбоя функции примерно до одной минуты. Вы также можете отслеживать это по мере увеличения ShardIteratorAge и принимать меры для приостановки обработки потока, если это необходимо, до тех пор, пока вы не разрешите нижележащую зависимость.