AWS lambda medium security documentation change
Summary
Added new 'Error handling' section recommending DLQ configuration for durable functions and outlining error handling best practices
Security assessment
The change explicitly addresses data loss prevention by recommending DLQs to capture failed events, which directly improves system integrity and availability. It documents security-critical failure handling for durable functions where events aren't automatically retried.
Diff
diff --git a/lambda/latest/dg/durable-best-practices.md b/lambda/latest/dg/durable-best-practices.md index 02bdbe2f0..e035f106d 100644 --- a//lambda/latest/dg/durable-best-practices.md +++ b//lambda/latest/dg/durable-best-practices.md @@ -7 +7 @@ -Function versions and aliasesMonitoringRelated resources +Function versions and aliasesMonitoringError handlingRelated resources @@ -22,0 +23,19 @@ Enable structured logging with execution IDs and step names. Set up CloudWatch a +## Error handling + +In addition to configuring retry strategies for transient failures, configure a dead-letter queue (DLQ) on your durable function to capture events from permanently failed executions. When a durable execution reaches a terminal state (FAILED, STOPPED, or TIMED_OUT) after an asynchronous invocation, Lambda sends the original triggering event to the DLQ. This allows you to inspect, debug, and optionally reprocess failed events without losing them. + +To configure a DLQ, set the `DeadLetterConfig` property on your function to an Amazon SQS queue or Amazon SNS topic ARN. For more information, see [Dead-letter queues](./invocation-async-retain-records.html#invocation-dlq). + +Follow these best practices for error handling with durable functions: + + * **Configure a DLQ for async invocations** – Always attach a dead-letter queue when invoking durable functions asynchronously. Unlike standard Lambda functions, durable executions are not automatically retried on failure, so the DLQ is your safety net for capturing events that led to permanently failed executions. + + * **Use retry strategies within steps** – Configure explicit retry strategies with appropriate backoff for transient failures. For guidance on configuring retries, see [Retries for durable functions](./durable-execution-sdk-retries.html). + + * **Combine DLQs with EventBridge notifications** – Use EventBridge rules to alert on FAILED, STOPPED, and TIMED_OUT status changes for real-time visibility, and use a DLQ to preserve the original event payload for later analysis or reprocessing. + + * **Monitor DLQ depth** – Create a CloudWatch alarm on the `ApproximateNumberOfMessagesVisible` metric for your DLQ to detect when failures are accumulating. + + + +