Product wants richer success payloads routed to a downstream event bus when a Lambda finishes, not only failure capture after async retries. Which capability should the developer prefer?

When product wants richer success payloads routed to a downstream event bus when a Lambda finishes—not only failure capture after async retries—prefer Lambda Destinations so both success and failure outcomes can route payloads to targets such as SQS, SNS, EventBridge, or another function. Destinations formally extend beyond “DLQ only on failure,” enabling event-driven follow-on work when license PDFs succeed while still notifying ops on failure.

Using only a dead-letter queue and discarding all successful invocation results cannot satisfy success routing. Disabling async invoke and requiring every caller to ignore responses abandons the outcome-routing goal. Replacing Destinations with CloudTrail alone for application payload routing misuses an audit trail as an application integration bus.

Exam caveat: Destinations are for asynchronous invocation modes—verify how your trigger invokes. Failure destinations and DLQs can both be configured; avoid duplicate operator toil. Limit success payload size and sensitivity when targeting EventBridge.

Operational check: configure success→EventBridge and failure→SQS (or SNS); test both paths; authorize Lambda to publish to targets; alarm on failures; and document consumer contracts for the success event schema.