Retry-patronen onderzoeken in CloudWatch

Je team bij ReliableApp Co heeft een Lambda-functie genaamd payment-processor die betalingsmeldingen asynchroon afhandelt. De functie faalt af en toe, en je operations-team heeft een dead-letter queue (DLQ) genaamd payment-processor-dlq geconfigureerd om gebeurtenissen op te vangen die niet verwerkt kunnen worden. Een collega vraagt je hoe het retry-gedrag van Lambda werkt met de DLQ.

Hoe vaak probeert Lambda standaard een mislukte asynchrone aanroep opnieuw voordat de gebeurtenis naar de DLQ wordt gestuurd?