SHART.CLOUD | DESKTOP | LABROULETTE | AWS-LAMBDA-DLQ-OBSERVABILITY.YAML
01 - Labroulette - Catch a Failing Lambda Pipeline Before It Eats the Queue
| shart.cloud / labroulette / aws-lambda-dlq-observability |
AWS *OO ~55 min $0-2 reviewed 6/30/2026

Catch a Failing Lambda Pipeline Before It Eats the Queue

Put a sane failure path around an SQS-to-Lambda pipeline: retries, a dead-letter queue, alarms, and least-privilege permissions so bad messages get captured instead of silently draining morale.

#serverless#observability#iam
Lab ReceiptHeap, a receipt-parsing SaaS that retries failed invoices forever because "eventual consistency" got translated into "eventual landfill." all labs
02 - Actions
score -- - -- votes
-- completed
State loading
03 - Scenario

ReceiptHeap, a receipt-parsing SaaS that retries failed invoices forever because "eventual consistency" got translated into "eventual landfill."

Put a sane failure path around an SQS-to-Lambda pipeline: retries, a dead-letter queue, alarms, and least-privilege permissions so bad messages get captured instead of silently draining morale.

Constraints

  • Failed messages must land in a dead-letter queue after a bounded number of receives
  • An alarm must fire when the dead-letter queue has visible messages
  • Lambda can read only the source queue and write only the logs it needs
  • Everything is Terraform and can be destroyed without leaving queues behind
Scenario AWS - beginner
05 - Steps
  1. STEP_01

    Create the source queue and dead-letter queue

    Create two SQS queues: one for incoming receipts and one dead-letter queue for messages that fail repeatedly. Configure the source queue redrive policy so poison messages move after a small, explicit receive count.

    Hint: Set maxReceiveCount low during the lab so you can trigger the DLQ without waiting around like a cursed cron job.

    Terraform docs

  2. STEP_03

    Lock the function's role down

    Create an execution role and policy that allows only the source queue receive/delete actions and basic log writes. Do not hand the function a project-wide "fix it in prod" sledgehammer.

    Terraform docs

  3. STEP_04

    Alarm on dead letters

    Add a CloudWatch metric alarm on the dead-letter queue's visible-message count. Route the alarm to an SNS topic with an email subscription or other channel someone will actually read.

    Terraform docs

  4. STEP_05

    Prove the failure path

    Send one valid message and one intentionally broken message. Capture proof that the valid one clears, the broken one lands in the DLQ, and the alarm moves into ALARM state.

    Terraform docs

Steps 5 tasks
06 - Deliverables
  • A Terraform stack defining the queues, Lambda, IAM role, alarm, and notification path
  • CLI output showing a poison message in the dead-letter queue
  • A screenshot or log excerpt showing the CloudWatch alarm fired
Deliverables 3 required
07 - Rubric
Redrive policy moves repeated failures into the dead-letter queue 30%
Lambda event source mapping processes the source queue cleanly 25%
IAM permissions are scoped to the exact queue and log resources 20%
Alarm and notification path fire when dead letters appear 25%
Rubric self-assessed