SysPad › Lessons › serverless lessons › AWS Lambda
How AWS Lambda works
Event-driven serverless compute. Scales automatically from 0 to 1,000+ concurrent executions. Billed per invocation and duration (GB-s). Watch out for cold starts and concurrency limits.
Lambda flips the model: instead of running a server that waits for work, you hand AWS a function and it runs only when an event fires, scaling from zero to thousands of copies on its own. You pay for the milliseconds it runs and nothing while it’s idle. The two things that trip everyone up: cold starts and the one-event-per-instance rule.
What you will learn
- How does Lambda run with "no servers", and what are you actually billed for?
- What’s a cold start, why does it happen, and when does it stop?
- If one instance handles one event at a time, how does Lambda handle a thousand at once?
- Where does Lambda stop being the right tool?
Functions, not servers
With Lambda you upload a function and connect it to an event source(an API request, a file landing in S3, a message on a queue, a schedule). AWS provisions the compute, runs your code, and tears it down. There’s no server for you to manage, patch, or keep running.
Billing matches that: you pay per request plus GB-seconds(memory × run time). Idle costs nothing.
Cold starts and warm reuse
The first time an event hits a new execution environment, Lambda must create it and load your code, a cold start (extra latency). After the function finishes, Lambda keeps that environment warm for a while, and subsequent events reuse it with no startup cost.
Scaling: one event per instance
A single Lambda environment processes one event at a time. To handle many simultaneous events, Lambda simply runs many environments in parallel, this is concurrency. Ten concurrent requests means ten environments.
You don’t configure a fleet; scaling is automatic. But concurrency has account limits, and each instance opening its own database connection is exactly why connection poolers (RDS Proxy) exist.
⚓ APIs, event processing, cron tasks, glue between services, anything bursty and stateless.
Where Lambda stops fitting
Lambda functions are short-lived (up to 15 minutes per invocation), stateless, and have memory/package limits. Memory is the main dial, and it also scales CPU, more memory means a faster function, even if it doesn’t need the RAM.
Flashcards
- What are you billed for with Lambda, and what does idle cost?
- Per request plus GB-seconds (memory × run time). Idle costs nothing, there’s no always-on server.
- Why is the first request to a fresh Lambda environment slower?
- A cold start: Lambda must create the execution environment and load your code. Reused (warm) environments skip this.
- One Lambda instance handles one event at a time. So how does it serve 1,000 at once?
- It runs 1,000 environments in parallel (concurrency). Scaling is automatic, up to account concurrency limits.
- Your Lambda is CPU-bound but barely uses its RAM. How do you speed it up?
- Increase its memory setting, Lambda scales CPU with memory, so more memory gives more CPU even if you don’t need the RAM.
- Name workloads that DON’T fit Lambda.
- Jobs over 15 minutes, steady high-throughput services, or anything needing persistent local state, use containers (Fargate/ECS) or EC2.