Lesson 141 · AWS Learning Path

AWS 141: Lambda triggers and event source mappings

Anil Jalela · Published Nov 13, 2025 · 8 min read

Labelled process diagram for AWS 141: Producer or source to Push permission or Lambda poller to Function batch to Checkpoint, retry, and failure record, with decision, proof and rejection evidence.

Why this lesson matters

Distinguish push triggers from poll-based event source mappings and understand batch, checkpoint, visibility, retry, and permission behavior.

What you will be able to do

By the end, you can:

explain lambda triggers and event source mappings in plain language;
locate the current service controls in the AWS Management Console;
run the matching CloudShell or AWS CLI queries and explain every important field;
draw the identity, network, data, failure, and monitoring path;
choose the service from requirements and reject it when those requirements are absent;
diagnose a failed or misleading result from evidence;
state the cost owner and prove cleanup or a no-create result.

Before you start

Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

Question	What it means in this lesson
Purpose	Distinguish push triggers from poll-based event source mappings and understand batch, checkpoint, visibility, retry, and permission behavior.
Scope and boundary	The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda triggers and event source mappings.
Evidence of success	Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda triggers and event source mappings.
Cost model	Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Safe rejection rule	Avoid assuming every trigger retries the same way or that one delivered event means exactly-once business processing.

How the request flows

+----------------------+
|  Producer or source  |
+----------------------+
           |
           v
+------------------------------------+
|  Push permission or Lambda poller  |
+------------------------------------+
                  |
                  v
+----------------------+
|    Function batch    |
+----------------------+
           |
           v
+-----------------------------------------+
|  Checkpoint, retry, and failure record  |
+-----------------------------------------+

For Lambda triggers and event source mappings, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda triggers and event source mappings. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda triggers and event source mappings. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

Situation	Direction	Reason
Requirement matches	Use an event source mapping when Lambda should poll a supported queue or stream with managed batching.	Select only after scope, behavior, security, recovery, operations, and price evidence agree.
Requirement does not match	Avoid assuming every trigger retries the same way or that one delivered event means exactly-once business processing.	Rejecting an attractive service is a valid architecture result.
No create permission or cost approval	Use supplied evidence and local design work	Learning does not depend on creating an hourly resource.
Existing resource is unknown or unowned	Inspect only, then stop	Never change or delete a resource merely because it resembles a course example.

Push, asynchronous invoke and polling are different paths

Synchronous push sends one request and waits for the function response; the caller or integrating service owns retries. API Gateway and direct RequestResponse invocation are common examples. Asynchronous invocation accepts an event into Lambda's internal queue, returns acceptance, then Lambda invokes and applies its configured age/retry/destination behavior; S3, SNS and EventBridge integrations commonly use this model. A function resource policy authorizes the pushing service.

An event source mapping (ESM) is a Lambda-managed poller between a queue/stream and a function. It has its own UUID, state, source, target version/alias, batch/window, filter, concurrency and failure settings. The execution role needs source read/checkpoint/decrypt/network permissions as appropriate. Enabled means polling configuration is active - not that records are current or successful.

Source	Unit/order/checkpoint	Failure behavior to design
SQS standard	batch of messages; at-least-once, best-effort ordering	visibility timeout, redrive/DLQ, batch item failure, duplicate-safe handler, queue age
SQS FIFO	ordering within message group	one failed group blocks its later messages; group cardinality limits parallelism
Kinesis	ordered records per shard; checkpoint advances by batch	poison batch can stall shard; iterator age, maximum age/retries, bisect and failure destination
DynamoDB Streams	ordered item modifications within shard, 24-hour stream record retention	shard progress, parallelization, partial batch failure and expiry
MSK/self-managed Kafka	topic partitions and committed offsets	network/auth, consumer-group/offset lag and on-failure destination
Amazon MQ	broker queues and source-specific polling	broker/network/secret permissions, concurrency and redelivery

Event filtering occurs before invocation and can reduce cost, but a malformed or over-broad filter can silently discard or invoke unwanted events. Treat filter patterns as code: version, unit test and monitor producer schemas. Batch size/window improve throughput but increase per-invocation work and blast radius. Payload limits, source record size and function timeout still apply.

Partial batch response lets supported queue/stream integrations report failed item identifiers so successful items need not be retried, but the handler must return the exact expected schema. Streams still preserve ordering constraints; careless parallelization can violate application order even if source order exists. Event-source delivery is not globally exactly once. Use immutable IDs and conditional idempotency state at the business side effect.

AWS Management Console, step by step

Use the Console service search and open Lambda, Functions, Configuration, Triggers and Event source mappings; confirm the account and Region before reading the page.
Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws lambda list-event-source-mappings --query 'EventSourceMappings[].{Id:UUID,Function:FunctionArn,Source:EventSourceArn,State:State,Batch:BatchSize,Last:LastProcessingResult}' --output table
aws lambda list-functions --query 'Functions[].FunctionName' --output table

Expected interpretation

An Enabled mapping proves polling is configured, not that records are processed once, checkpoints advance, batches succeed, or poison messages are isolated.

Practical work

Compare API Gateway, SNS, EventBridge, SQS, Kinesis, and DynamoDB Streams as Lambda sources. Record who pushes or polls, batch behavior, retry owner, and failure destination.

For each source add permission direction, ordering scope, retention/visibility, filtering, concurrency control, lag/age metric and replay route. Given one poison event among ten, design the exact sequence for whole-batch failure and partial-batch response. Given a duplicated order event, show the durable idempotency key and conditional state transition. Test disabled mapping, invalid filter, expired stream record, too-short SQS visibility timeout, missing KMS permission and wrong function alias using supplied evidence.

Diagnose this topic from its own evidence

Start at source depth/age and ESM StateTransitionReason/LastProcessingResult, then correlate function Invocations, Errors, Throttles, duration and logs. Source growing with zero invokes suggests disabled/failed mapping, permission, filter, network or no concurrency. Invokes plus errors and growing age indicate poison records or dependency failure. Repeated SQS messages can mean visibility expires before processing/deletion; stalled stream iterator age commonly means a failed batch blocks checkpoint progress. Preserve one event ID and trace every attempt before changing batch/retry settings.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

What operational purpose is this lesson solving?

Expected direction: Distinguish push triggers from poll-based event source mappings and understand batch, checkpoint, visibility, retry, and permission behavior.

Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Lambda triggers and event source mappings.

What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Lambda triggers and event source mappings.

Which tempting design or shortcut must be rejected?

Expected direction: Avoid assuming every trigger retries the same way or that one delivered event means exactly-once business processing.

Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

Pass when the learner classifies direct synchronous, asynchronous and ESM invocation; maps permissions and retry owner; and accurately designs SQS, FIFO, Kinesis and DynamoDB Streams batch/order/checkpoint behavior. Evidence must cover filters, duplicate-safe processing, partial batch failures, poison isolation, age/lag alarms, concurrency/backpressure, replay, cost and cleanup. Fail if Enabled is accepted as successful processing, every trigger is said to retry identically, or exactly-once business behavior is assumed without durable idempotency.

Official sources

View complete AWS learning path