You already know that a Lambda function executes when an event occurs (subchapter 14.1). But which events? Who "calls" the function? That's defined by triggers: the sources that invoke your Lambda. In this subchapter, we'll look at the most important ones and how they open the door to a ton of architectures.

A trigger is what makes your function execute. You connect an event source to your Lambda, and every time that source generates an event, AWS automatically invokes your function, passing it the event data.

A single function can have one or several triggers. Let's look at the four most common ones.

API Gateway allows your Lambda to respond to HTTP requests, just like a normal web API. It's the way to create serverless backends and APIs.

Real-world example: a mobile app needs a backend that returns the list of products. Instead of setting up an always-on server (EC2), you use API Gateway + Lambda: when the app makes a GET /products, API Gateway invokes your Lambda, which returns the data. If no one uses the app at night, you pay nothing. If thousands use it during the day, it scales by itself.

This is one of the most popular serverless patterns, and the basis of the serverless blog project we'll see in Chapter 33.

Remember S3, the object storage (Chapter 5). You can configure a bucket so that every time a file is uploaded (or deleted), it triggers a Lambda.

Classic example: a website where users upload photos. When an image arrives in the S3 bucket, a Lambda is triggered that automatically creates a thumbnail (small version) and saves it. The user doesn't wait: the photo is processed "by itself" in the background. Other uses: converting formats, extracting text, scanning for viruses, etc.

Remember DynamoDB (subchapter 8.3). A DynamoDB Stream is a "change log" of the table: every time an item is created, modified, or deleted, it can trigger a Lambda with the details of the change.

Example: in a store, when a new order is inserted into the Orders table, the stream triggers a Lambda that sends a confirmation email to the customer and updates a sales dashboard. The database "notifies" of its own changes, and the logic reacts automatically.

Remember queues (we'll see them in depth in Chapter 15). An SQS queue accumulates messages (pending tasks), and a Lambda can process them one by one or in batches.

Example: a store receives thousands of orders in a rush (Black Friday). Instead of processing them all at once and getting overwhelmed, it puts them in an SQS queue. A Lambda takes them out and processes them at a sustainable pace. The queue acts as a "buffer" (we'll see this as decoupling in Chapter 15).

And there are many more: CloudWatch (scheduled tasks like "every night at 2:00"), SNS (notifications), EventBridge (system events, Chapter 15), Kinesis (data streaming, Chapter 29), etc.

The important thing about triggers is the pattern they enable: event-driven architectures. Instead of one big monolithic program that does everything, you have small functions that react to events:

Each piece is small, independent, and runs only when needed. This makes systems more flexible, decoupled, and cheaper. We'll dive deeper into these patterns in Chapters 15 and 28.

• A trigger is the source that invokes your Lambda when an event occurs; you connect the source and AWS calls your function automatically.
• API Gateway: HTTP requests → your Lambda acts as a serverless API/backend.
• S3: a file is uploaded → process images, convert formats, scan, etc.
• DynamoDB Streams: a change in the database → react (emails, statistics).
• SQS: messages in a queue → process background tasks at a sustainable pace.
• Triggers enable event-driven architectures: small functions that react to events, more flexible and cheaper than a monolith.

In the next subchapter, we'll look at a key practical aspect: how to manage your function's dependencies (libraries) and reuse code with Layers.