Get startedGet started for free

Configuring Lambda functions

1. Configuring Lambda functions

Welcome back. We'll cover the Lambda settings that shape behavior: runtime and handler, memory and timeout, environment variables, layers, and the execution role.

2. Why configuration matters

The same code can behave very differently depending on its settings. Configuration controls performance, cost, and safety, so the goal is predictable behavior across dev and prod.

3. Code vs configuration

Your code package holds the handler logic and its dependencies — changes require a new deploy. Function configuration covers memory, timeout, environment variables, the execution role, layers, and can often change without touching code.

4. The knobs you control

Runtime and handler tell Lambda what code to run. Memory and timeout shape performance, cost, and safety. Environment variables let you configure behavior without hardcoding, the execution role sets permissions for AWS APIs, and layers share dependencies across functions.

5. Runtime and handler basics

The runtime is your language environment, like Python. The handler is the entry point Lambda calls, formatted as file dot function. For example, lambda_function dot lambda_handler tells Lambda to import that file and call that function.

6. Handler string: what can go wrong

Lambda imports the file, then calls the function you configured. If either name is wrong, the invocation fails before your logic runs.

7. The execution role (IAM)

IAM stands for Identity and Access Management — it's how AWS handles permissions. The execution role defines what your function is allowed to do by controlling which AWS APIs your code can call.

8. What is a Lambda layer?

A layer is a ZIP you attach to your function. Lambda mounts it under /opt, so shared libraries and utilities are available at runtime. Update the layer once, and every function using it picks up the change.

9. Where layers show up at runtime

Your code runs from /var/task, layers mount under /opt, and /tmp is temporary scratch space. That helps you separate package code from layer files.

10. Memory also affects CPU

More memory also gives more CPU, so CPU-bound work can finish faster. Because cost depends on memory and duration, tune with measurements.

11. Tune memory with measurements

Start with a reasonable default like 256 MB, test with realistic events, and compare duration and cost across memory sizes to find the best trade-off.

12. Timeouts and safe execution

The timeout stops runaway executions by acting as a safety timer. Check remaining time before starting long work and fail fast if needed. In Chapter 2, you'll learn about retries and destinations.

13. Walkthrough: checking remaining time

We read time_left from the context countdown, then guard on a minimum buffer. If time is low, we raise an error instead of starting risky work.

14. Environment variables

Environment variables keep configuration out of your code and let you separate dev, test, and prod settings. For sensitive values, use Secrets Manager instead.

15. Walkthrough: reading environment variables

We import os and read STAGE and LOG_LEVEL with defaults. Defaults keep the function predictable when a variable is missing.

16. Common configuration pitfalls

Avoid hardcoding stages, too-low timeouts, and secrets in plain environment variables. If you see AccessDenied, your execution role probably needs a permission.

17. Let's practice!

Now let's practice in the AWS Console by reviewing and adjusting these settings on a function.

Create Your Free Account

or

By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.