Event-Driven Pipeline
SNS fan-out → SQS queue → Lambda processor → DynamoDB, with a dead-letter queue for failed messages.
What you can build with this
Publish an event once to SNS and have it delivered to the processing queue, which triggers your Lambda automatically via a real EventSourceMapping — no polling code, no scheduler, just your application publishing events as they happen. The processor writes to DynamoDB through an explicit IAM policy (no canvas edge to the table — see the Data Table node's comment for why: any Lambda<->DynamoDB edge forces an unwanted Streams trigger, which would re-invoke this processor on its own writes).
Deployment timing
After you run the deploy command, resources come online at different times. Check the validation steps in order.
| Resource | Ready in |
|---|---|
| SNS Topic, SQS Queues, DynamoDB Table | Immediate |
| Lambda Function + Event Source Mapping | 30–60 sec |
| First message processed after you publish | Under 1 second once the mapping is active |
CloudFormation parameters
These are the values you will fill in when deploying the exported template. Changing these does not break the template — that is the point.
| Parameter | What to provide | Example |
|---|---|---|
| Environment | Environment tag applied to resources (does not rename them) | dev |