Вы путаете поведение двух разных функций.
В очереди SQS может быть очередь недоставленных сообщений.
Когда ReceiveCount для сообщения превышает maxReceiveCount для очереди, Amazon SQS перемещает сообщение в очередь недоставленных сообщений (с ее исходным идентификатором сообщения).
https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html
Лямбда-функция также может иметь очередь недоставленных сообщений.
Любая лямбда-функция, вызванная асинхронно , повторяется дважды, прежде чем событие сбрасывается. Если повторная попытка не удалась и вы не знаете, почему, используйте Dead Letter Queues (DLQ), чтобы направить необработанные события в очередь Amazon SQS или в раздел Amazon SNS для анализа ошибки.
...
Полезная нагрузка, записанная в целевой ARN DLQ, является исходной полезной нагрузкой события без изменений в теле сообщения. Атрибуты сообщения содержат информацию, помогающую понять, почему событие не было обработано
https://docs.aws.amazon.com/lambda/latest/dg/dlq.html
У вас есть первое - очередь SQS с DLQ, а не второе - лямбда-функция с DLQ.
В вашей конфигурации сообщения просто перемещаются в DLQ, как описано, без изменений в соответствии с политикой повторного запуска.
Невозможно получить искомые сообщения в DLQ для лямбда-функции, которая прослушивает очередь SQS, поскольку интеграция SQS / Lambda не использует вызовы асинхронных функций.
Лямбда опрашивает очередь и вызывает вашу функцию синхронно с событием, которое содержит сообщения очереди.
https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html
Интеграция SQS / Lambda не может быть настроена иначе, и настройка самой функции Lambda с DLQ (вместо очереди SQS) не будет иметь никакого эффекта.
Обходной путь - использовать журналы CloudWatch для вашей функции Lambda для поиска проблемных сообщений. Зарегистрируйте SQS MessageId в своем коде, чтобы позже его можно было найти в журналах.