2.1.1.1. Lambda Triggers and Event Sources

2.1.1.1. Lambda Triggers and Event Sources

First Principle: Lambda functions are invoked by events from various AWS services and custom applications, enabling event-driven architectures and fostering loose coupling.

Lambda never runs on its own — something always triggers it. The trigger determines how your function receives events and how it scales.

The most common trigger on the exam is API Gateway, which turns Lambda into a web backend: each HTTP request becomes a Lambda invocation. S3 events trigger functions when objects are created or deleted — the classic use case is image thumbnail generation on upload. DynamoDB Streams invoke Lambda when table items change, enabling real-time reactions to data modifications.

For asynchronous patterns, SQS triggers Lambda to process queued messages in batches, while SNS triggers Lambda when messages are published to a topic. EventBridge (the evolution of CloudWatch Events) adds content-based routing — you can trigger Lambda only for specific event patterns, like an EC2 instance changing to "stopped" state. Kinesis triggers Lambda for real-time streaming data processing.

The key distinction for the exam: S3, SNS, and EventBridge use asynchronous invocation (Lambda manages retries), while API Gateway uses synchronous invocation (the caller waits for a response). SQS and Kinesis use poll-based invocation (Lambda polls the source for new records). A synchronous caller gets the error back directly and Lambda does not retry it; a failed asynchronous invocation is retried twice by default. Poll-based sources use an event source mapping — for Kinesis and DynamoDB Streams, Lambda reads each shard with one concurrent batch by default, so shards are processed in parallel and records stay in order within a shard.

Async failure handling — DLQ vs. Destinations: a dead-letter queue (standard SQS queue or SNS topic) receives only the original event once retries are exhausted. Destinations route on-success and on-failure separately and send a richer invocation record (request, response and error details); targets are an SQS queue, an SNS topic, another Lambda function or an EventBridge event bus, plus an S3 bucket for failures only. Prefer Destinations to hand-written try/catch publishing code.

Scenario: You're developing a serverless application where new user profiles are uploaded as JSON files to an Amazon S3 bucket. You need a Lambda function to automatically process these files as soon as they are uploaded.

⚠️ Exam Trap: Lambda processes SQS messages in batches, but a failure in one message fails the entire batch by default. To avoid reprocessing successful messages, enable partial batch failure reporting with ReportBatchItemFailures.

Idempotency — The Key to Reliable Event Processing

The answer to that reflection question is expected behavior. AWS services deliver events with at-least-once semantics — your function may be invoked multiple times for the same event due to retries, network hiccups, or infrastructure failover. This makes idempotency one of the most critical concepts for the DVA-C02.

An idempotent operation produces the same result regardless of how many times it's executed. If your Lambda processes an order, running it twice shouldn't create two orders. Design strategies include:

• Idempotency keys: Store a unique event ID (e.g., S3 object ETag, SQS message ID) in DynamoDB before processing. Check for it before each execution — if it exists, skip the duplicate.
• Conditional writes: Use DynamoDB condition expressions (attribute_not_exists) so duplicate writes fail gracefully instead of creating duplicate records.
• Powertools for AWS Lambda: The @idempotent decorator (Python) or middleware (TypeScript) handles idempotency automatically using DynamoDB as a persistence layer.

⚠️ Exam Trap: "At-least-once delivery" means your code MUST handle duplicates. If a question describes duplicate processing problems, the answer is almost always an idempotency strategy — not changing the event source configuration.