Lambda: Serverless Functions

Lambda runs your code without you ever provisioning, patching, or managing a server — you upload a function, tell AWS what should trigger it, and it runs on demand, scaling automatically from zero to thousands of concurrent executions.

A minimal function

Python handler.py
def lambda_handler(event, context):
    name = event.get("name", "world")
    return {
        "statusCode": 200,
        "body": f"Hello, {name}!"
    }
Invoking it
aws lambda invoke --function-name greet --payload '{"name":"Priya"}' response.json
cat response.json
Output
{"statusCode": 200, "body": "Hello, Priya!"}

Every Lambda function has a handler function with this same shape: it receives an event (the input data, shaped differently depending on what triggered the function) and returns a result. You're billed only for the milliseconds your code actually runs, not for idle time.

Triggers

A Lambda function does nothing on its own — it needs a trigger. Common ones: an API Gateway endpoint turning it into a web API, an S3 event firing whenever a file is uploaded to a bucket, or a CloudWatch scheduled event running it on a cron-like timer.

Cold starts: when a function hasn't run recently, AWS has to initialize a fresh execution environment before running your code, adding noticeable latency (sometimes hundreds of milliseconds to a couple of seconds) to that first invocation. Frequently-invoked functions mostly avoid this by staying "warm," but a function that runs once an hour will pay the cold-start cost nearly every time — worth knowing before you build a latency-sensitive API entirely on Lambda.

When Lambda fits and when it doesn't

Lambda is a great fit for short-lived, event-driven work: processing an uploaded image, responding to an API request, running a nightly cleanup job. It's a poor fit for long-running processes (functions have a hard 15-minute maximum runtime) or workloads that need to maintain state or a persistent connection between invocations.

PreviousRDS: Managed Databases