Отправка сообщений в DLQ не должна зависеть от типа ошибки. Это должно зависеть от требований к целостности данных вашего приложения.
Предположим, у вас есть приложение, которое ежеминутно потребляет сообщения от многих датчиков погоды, и вы создаете набор исторических данных, чтобы вы могли использовать его в некоторой прогнозной модели. В этом случае несколько потерянных сообщений не имеют большого значения, потому что любая отдельная точка данных не очень значима. (На самом деле, в любом случае, вы, возможно, захотите отфильтровать самые экстремальные выбросы.) В этом случае вам следует регистрировать все ошибки и устанавливать срабатывание будильника, если вы отбрасываете более X% сообщений за период времени Y. (Слишком большое количество пропущенных сообщений может указывать на системную проблему.)
С другой стороны, если ваша Lambda использует сообщения от электронных устройств чтения значков, чтобы вы могли иметь запись о том, кто получил доступ к защищенным частям здания,тогда вы хотите поместить все сообщения с ошибками в DLQ. В этом случае полнота данных очень важна, и при возникновении ошибки необходимо исправить ее и повторно отправить сообщения.
Наконец, важно отметить, что DLQ на самом деле не предназначен для хранения. Думайте об этом больше как catch в блоке try / catch. Поэтому еще один вопрос о том, когда использовать DLQ, - есть ли у вас какой-то путь к восстановлению. Если сообщения являются напоминаниями о приеме у врача, которые ваше приложение использует для связи с пациентами, чтобы напомнить им об их предстоящей встрече, то у вас может быть Lambda, который звонит на их телефон с записанным сообщением, но если телефонная линия недоступна или номер телефона недействителенсообщение может отправляться в DLQ, где другая лямбда может использовать сообщение и вместо этого попытаться отправить напоминание по электронной почте.