Lambda — Serverless Compute

What we're doing: See code placement determine whether it runs once (Init) or on every request (Invoke).

import boto3
s3 = boto3.client('s3')  # Init phase: runs once per execution environment

def handler(event, context):  # Invoke phase: runs on every request
    return s3.list_buckets()

1

The import runs during Init — once per execution environment, not once per request.

2

Creating the S3 client here means every subsequent warm invocation reuses the same client instead of recreating it.

4

Only code inside the handler runs during the Invoke phase, bounded by the function's configured timeout.

Why this works: Placing expensive setup (client creation, DB connections) outside the handler is what makes warm invocations fast — that code runs once during Init and is reused across every subsequent Invoke on the same execution environment.

What we're doing: See the CLI-level difference between invoking synchronously and asynchronously.

aws lambda invoke --function-name my-fn --payload '{}' out.json
# waits for the function to finish, out.json holds the real response
aws lambda invoke --function-name my-fn --invocation-type Event --payload '{}' out.json
# returns immediately with StatusCode 202, out.json is empty

1

Default invocation type is RequestResponse — synchronous. The CLI call blocks until the function finishes.

3

Event invocation type is asynchronous — the CLI call returns as soon as Lambda accepts the event into its internal queue, not when the function finishes.

Why this works: The StatusCode 202 on the async call confirms only that Lambda accepted the event for processing — it says nothing about whether the function later succeeded, which is exactly why async invocations need their own retry and failure-handling configuration.

What we're doing: See why reserved concurrency alone does not remove cold starts.

aws lambda put-function-concurrency --function-name checkout --reserved-concurrent-executions 50
# a burst of 50 concurrent requests still cold-starts each new environment

1

Reserved concurrency guarantees up to 50 concurrent execution slots exist for this function — it says nothing about whether those environments are pre-initialized.

2

Each of the 50 environments is still created on demand, so a sudden burst still pays the cold-start cost for every environment Lambda has to stand up.

Why this works: Reserved concurrency answers "how many can run at once," while provisioned concurrency answers "are they ready before the request arrives" — they solve different problems and are often used together.

What we're doing: See why a non-idempotent handler breaks under normal Lambda retry behavior.

def handler(event, context):
    charge_customer(event['order_id'], event['amount'])  # not idempotent
    return {'status': 'charged'}

2

If this invocation succeeds but the confirmation is lost (network blip, timeout), Lambda or the upstream source may redeliver the same event, charging the customer twice.

Why this works: Nothing about this handler is unusual — it is the normal, expected retry/at-least-once behavior of Lambda's invocation models that turns a non-idempotent side effect into a duplicate charge, not a rare edge case.

What we're doing: Decide between Lambda and ECS for two different workloads.

Image thumbnail generation on S3 upload, bursty, seconds per job
→ Lambda: event-driven, short-lived, scales to zero when idle.

24/7 video transcoding pipeline, sustained high throughput
→ ECS/EC2: steady utilization makes per-invocation billing costlier.

1

Bursty, event-driven, short jobs are exactly Lambda's strength — no idle cost, automatic scaling per S3 event.

3

Sustained high throughput is where a continuously-running, right-sized service usually costs less than per-invocation Lambda billing at the same volume.

Why this works: The same underlying capability (run code) is available either way — the deciding factor is whether the workload's shape (bursty vs steady, short vs long) matches what each pricing and execution model rewards.