Lambda and Serverless

1Lambda execution model

Lambda runs your function in response to events without you provisioning servers. Each simultaneous in-flight invocation can get its own execution environment; concurrency is how many of those environments are running at once. You write the handler, set memory and timeout, and AWS scales the environments up and down with arrival rate — subject to the account concurrency limit (default 1,000 concurrent executions per Region, a soft limit you can raise).

Figure. Each concurrent event can get its own execution environment — scale is invocation concurrency, not one long VM.

How an invocation runs

1. Event arrivesA trigger (API call, queue message, upload, schedule) targets the function.
2. EnvironmentLambda places the call in an execution environment — new or reused.
3. Scale with concurrencyMore overlapping calls mean more environments, up to the concurrency limit.

2Cold starts and Provisioned Concurrency

A cold start is the extra latency when Lambda must initialise a new execution environment before your handler runs. Warm environments reuse a previous init and skip that cost. Provisioned Concurrency keeps a chosen number of environments initialised and ready so latency-sensitive APIs avoid cold starts — you pay to hold them warm. Spiky background work usually stays on on-demand concurrency; steady low-latency APIs are the Provisioned Concurrency cue.

Figure. Cold starts pay init latency; warm reuses the environment; provisioned concurrency keeps warm capacity ready.

When to buy warmth

1. Measure the painIf init latency breaks an interactive SLA, cold starts matter.
2. Steady API trafficProvisioned Concurrency holds environments ready for that floor of load.
3. Spiky batchOn-demand concurrency is usually cheaper when occasional cold starts are fine.

3Event sources: push and poll

Lambda integrates with S3, DynamoDB Streams, SQS, SNS, API Gateway, EventBridge and more. Some sources push events to Lambda (API Gateway synchronous invoke, SNS/EventBridge asynchronous invoke). Others are poll-based: Lambda's event-source mapping pulls from SQS or a stream at a controlled rate. Putting SQS in front of a bursty producer lets Lambda drain the queue without being overwhelmed by a thundering push.

Figure. Burst lands on SQS; Lambda polls at a controlled rate instead of taking every push at once.

How to buffer bursts

1. Producer spikesUploads or messages arrive faster than you want to invoke.
2. QueueLand them on SQS so the burst becomes backlog, not concurrent stampede.
3. PollLambda's event-source mapping pulls at a rate shaped by batch size and concurrency.

4Memory, timeout and package limits

Configurable memory runs from 128 MB to 10,240 MB; CPU power scales up with the memory setting. Maximum timeout is 15 minutes (900 seconds) per invocation — longer work needs Step Functions chunking or a different compute service such as ECS/Fargate. Deployment packages: 50 MB zipped for direct upload, 250 MB unzipped, or up to 10 GB as a container image.

Lambda ceilings: memory 128 MB–10 240 MB, timeout up to 15 minutes, deployment package 50 MB zipped / 250 MB unzipped (or container image). The numbers are the concept; proportional bars would invent a false continuous trade-off.

5Pricing: requests and GB-seconds

Lambda bills per request plus compute time measured in GB-seconds: memory in GB multiplied by duration in seconds, with duration rounded up to the nearest 1 ms. Raising memory also raises CPU, so a higher memory setting can shorten duration enough that total GB-seconds — and cost — fall. Tune memory to minimise GB-seconds for the workload, not only to "add RAM".

Figure. Price tracks GB-seconds: memory setting × duration. More memory can finish sooner — compare the product.

How one invocation's compute bill is shaped

1. Convert memoryExpress the configured memory in GB (512 MB → 0.5 GB).
2. Measure durationUse the billed duration in seconds (after 1 ms rounding).
3. MultiplyGB-seconds = memory(GB) × duration(s); requests add their own line item.

6API Gateway in front of Lambda

API Gateway fronts Lambda with REST or HTTP APIs. It terminates HTTPS, can authorise callers, throttle, cache, and transform request/response shapes so the function stays a thin handler. Synchronous invoke means the caller waits on Lambda's response; design timeouts and error mapping at the gateway as carefully as in the function.

Figure. API Gateway is the HTTPS front door: routing, auth, throttling — then an integration invoke to Lambda or HTTP.

What the gateway absorbs

1. Edge concernsTLS, auth, throttling and caching sit at API Gateway.
2. InvokeGateway calls Lambda (commonly synchronous for request/response APIs).
3. Map the resultStatus codes and bodies are shaped for HTTP clients before leaving the gateway.

7Step Functions orchestration

Step Functions coordinates multiple Lambda functions (and other AWS integrations) as a state machine: Task states call workers, Choice branches on data, Retry/Catch handle transient failure. Standard workflows are long-running with exactly-once execution semantics and a full execution history — the durable business-process cue. Express workflows are for high-volume, short event processing with at-least-once semantics.

Figure. Step Functions orchestrates tasks and branches; Standard vs Express is durability/duration, not a different shape.

How to model an order flow

1. One Task per stepValidate payment, reserve inventory, send confirmation — each a Task (often Lambda).
2. Retry / CatchAttach backoff and failure routing on Tasks that can flake.
3. Pick Standard vs ExpressDurable audited business process → Standard; high-volume short pipeline → Express.

8S3 thumbnail pipeline pattern

A classic serverless pipeline: ObjectCreated on an uploads prefix invokes Lambda; the function reads the object, writes a thumbnail to a different prefix or bucket, and uses a dead-letter queue for failures. Writing thumbnails back into the same watched prefix is the recursive-invocation trap — the new object fires the trigger again. IAM on the execution role needs s3:GetObject on the source and s3:PutObject on the destination only.

Figure. Write thumbs outside the trigger prefix so ObjectCreated does not loop; DLQ captures poison events.

How the pipeline is wired

1. TriggerS3 event notification on ObjectCreated for the uploads prefix.
2. TransformLambda reads, resizes, writes the thumbnail elsewhere.
3. Isolate failureAttach an SQS DLQ so poison events are not silently lost.

Destination must differ from the trigger prefix

# trigger: s3://bucket/uploads/*
# output:  s3://bucket/thumbs/*   # NOT uploads/
aws s3 cp thumbs/out.jpg s3://bucket/thumbs/out.jpg