Advanced 20 min read

Lambda Triggers: S3 Events and DynamoDB Integration

By the end of this lesson, you'll be able to:

Trace an S3 event-driven Lambda flow from upload to processed result
Explain why event-driven functions should be designed to be idempotent
Design a Lambda execution role scoped to only the S3 and DynamoDB permissions a function actually needs

Prerequisites: "API Gateway and Event-Driven Architecture"

S3 as an event source

Recall Module 4's S3 buckets and objects. S3 can be configured to raise an event whenever an object is created (or, depending on configuration, other object-level changes) — and that event can invoke a Lambda function automatically.

Diagram showing an object uploaded to S3 raising an event that invokes a Lambda function, which processes the object such as generating image metadata, then writes a result, a log entry, or a message to another service. — A common, concrete use case: generating metadata for an uploaded image, without a learner ever uploading real sensitive data for this exercise.

A realistic use case: a document- or image-processing pipeline, where uploading a file automatically triggers metadata extraction, a thumbnail, or a validation step — all without a server sitting idle, waiting for the next upload.

Idempotency: handling a redelivered event safely

This is one of the most important practical concepts in event-driven serverless design: an event can sometimes be delivered more than once. If processing the same event twice would produce a different (and wrong) result — creating two records instead of one, for example — that function has a real bug waiting to happen.

A function is idempotent when processing the same event multiple times produces the same end result as processing it once. A simple, common technique: check whether the specific item this event refers to has already been processed (for example, using the object's key, or an ID embedded in the event) before repeating the work. This lesson introduces the concept at a beginner level — the point isn't building a complete idempotency framework, it's recognizing that "this event might arrive twice" is a real design constraint, not an edge case worth ignoring.

Connecting to DynamoDB: building on Module 5

Many event-driven Lambda functions read from or write to DynamoDB (Module 5) as part of their processing — recording that a file was processed, storing extracted metadata, or looking up related data by a partition key. The same DynamoDB design guidance from Module 5 still applies here: know the access pattern this function actually needs (a specific lookup by key, or a specific write) before designing the table, rather than treating DynamoDB as a generic drop-in for any storage need.

Scoping the execution role narrowly

A function that reads from S3 and writes to DynamoDB needs an execution role (Module 2's least-privilege principle, applied to Lambda) granting exactly those two things — nothing wider.

Diagram showing a Lambda function assuming an execution role that grants s3:GetObject on one specific bucket and dynamodb:PutItem on one specific table, labeled as better than a broad policy allowing every action on every resource. — A policy granting every action on every resource is an anti-pattern here exactly as it was in Module 2 — narrow to the specific actions and resources the function actually uses.

Exercise

An S3-triggered Lambda function extracts metadata from uploaded images and writes one record per image to a DynamoDB table. The same upload event is occasionally delivered twice by AWS. (1) What could go wrong if the function isn't designed to handle this? (2) Describe one simple technique that would make the function idempotent. (3) What two specific permissions should its execution role grant, and nothing more?

Show hint

For (2), think about checking whether this specific image has already been processed before repeating the work. For (3), match the permissions to exactly what the function does: read from S3, write to DynamoDB.

Lambda Triggers: S3 Events and DynamoDB Integration Quiz

1. An S3 event may be delivered to a Lambda function more than once. What should the function's design account for?

Idempotency — processing the same event twice should not produce a different or duplicated result Nothing — S3 guarantees every event is delivered exactly once with no exceptions The function should always fail on the second delivery The function should ignore all events except the first one it ever receives

2. A Lambda function's execution role should be granted broad, unrestricted permissions so it never fails due to a missing permission.

True False

3. A design that safely handles the same event more than once is described as ______.

Show hint

It's the property this lesson names directly as one of the most important event-driven design concepts.

My Notes

Questions about this lesson

No questions yet — be the first to ask.

Summary

S3 can invoke a Lambda function whenever an object is uploaded, and the same function commonly reads from or writes to DynamoDB as part of its processing — but because an event can sometimes be delivered more than once, this kind of function should be designed to be idempotent, and its execution role should grant only the specific S3 and DynamoDB permissions it actually needs.

❬ Previous Next ❭