Writing and Deploying Lambda Functions

Every Lambda function is built around a handler — the specific function AWS calls when the function is invoked. The handler receives two things: the event (data describing what triggered the invocation — the details differ depending on the event source) and a context object (information about the invocation itself, such as how much execution time remains). The handler does its work and returns a response, which the invoking service then uses however is appropriate for that integration.

This lesson deliberately doesn't walk through a specific programming language's exact syntax or a specific current runtime version — AWS supports several languages, and the specific supported runtime list changes over time. The concept that matters at a beginner level is the shape: event in, handler runs, response out.

Two configuration settings matter for every Lambda function:

• Timeout — Lambda functions have a configurable execution time limit. If a function doesn't finish within its configured timeout, AWS stops it and reports a timeout error. This lesson deliberately doesn't state a specific maximum, since that's an AWS platform detail worth checking against AWS's own current documentation rather than memorizing here.
• Memory — the amount of memory allocated to a function, which (on AWS Lambda) also proportionally affects the CPU power available to it. Under-provisioning memory can make a function slower or cause it to fail; over-provisioning wastes cost without benefit. Right-sizing this is a real, ongoing tuning decision, not a one-time setting.

Lambda supports environment variables — a convenient way to pass configuration into a function without hardcoding it into the code itself, such as a table name, a feature flag, or a target Region. This is a good fit for values that aren't sensitive.

It is not a good fit for long-lived, sensitive credentials. Storing something like a database password or a third-party API key directly as a plaintext environment variable is a real risk — anyone with permission to view the function's configuration can read it in plain text. Where a genuine secret needs to be available to a function, an appropriate secrets-management mechanism is the better fit conceptually — this lesson doesn't require building one, but flags the distinction clearly: configuration goes in environment variables; secrets belong somewhere designed to protect them.

Deploying a Lambda function means getting your code (and any dependencies it needs) into a form AWS can run — commonly a package uploaded directly, or a container image, depending on the function's needs. This lesson doesn't walk through one specific deployment tool's exact steps, since AWS supports several paths (the Console, the CLI, infrastructure-as-code tools this course revisits in Module 11) — the durable idea is that "deploying" a Lambda function is a distinct step from writing its code, and the same function code can be redeployed repeatedly as it's updated.