serverless aws faas claude-curated
AWS Lambda is a function-as-a-service runtime. You upload code, Lambda runs it on demand in ephemeral containers, and you pay only for the compute consumed. No servers to provision, patch, or scale.
Execution model
A Lambda invocation runs in a micro-VM (Firecracker) that goes through three phases:
- Init phase — the runtime starts, dependencies load, top-level module code executes. This is the cold start.
- Invoke phase — your handler runs against the event payload. Repeated invocations on the same container reuse this state (warm starts).
- Freeze / shutdown — between invocations the container is frozen (CPU paused). After idle timeout (minutes, not guaranteed) it is destroyed.
State stored outside the handler (module globals, connections opened in init) survives between warm invocations. The same code re-running on a different container starts cold again.
Cold starts
A cold start happens when no warm container is available — first invocation, scale-out, deployment, or after a long idle. Init duration depends heavily on the runtime:
| Runtime | Typical init |
|---|---|
| Node.js / Python | ~100–400 ms |
| Go / Rust | ~50–200 ms |
| Java / .NET | ~500 ms – several seconds |
Heavy runtimes pay for JVM/CLR startup and class loading. Mitigations:
- Provisioned concurrency — keep N containers pre-initialised. Eliminates cold starts at extra cost.
- SnapStart (Java) — snapshot the post-init state and restore from it. Substantially reduces JVM cold starts.
- Smaller deployment packages — fewer modules, less init code.
- Lazy initialisation — defer non-critical work out of the init path.
Memory and CPU coupling
Lambda has a single sizing knob: memory (128 MB to 10,240 MB). CPU scales linearly with memory. At 1769 MB a function gets one full vCPU; double the memory and you get roughly two vCPUs.
This means CPU-bound functions often run faster and cheaper at higher memory because the duration drops more than the per-ms cost rises. Profile and tune — the AWS Lambda Power Tuning tool automates this sweep.
Runtimes
Officially supported: Node.js, Python, Java, .NET, Ruby, Go (via custom runtime since 2024). For anything else:
- Custom runtimes via the Runtime API — bring your own language by implementing a small HTTP loop.
- Lambda Layers — shared zip archives mounted at
/opt. Useful for shared dependencies, common libraries, runtime extensions. - Container images — package as OCI images up to 10 GB, run on Lambda. Same execution model, just a different packaging format. Good fit for ML libraries that exceed the 250 MB zip limit.
Concurrency limits
- Account concurrency — region-wide cap (default 1000, raisable). All functions share this pool.
- Reserved concurrency — carve out a guaranteed slice for one function (also caps it).
- Provisioned concurrency — pre-warmed containers, billed per hour.
When you hit the concurrency limit Lambda throttles new invocations (HTTP 429 for sync, retries for async).
Cost model
Two components:
- Requests — flat per-million invocation fee.
- Duration — billed in GB-seconds: memory × execution time, rounded to the nearest millisecond.
So 512 MB × 200 ms = 0.1 GB-seconds per invocation. Provisioned concurrency adds a per-hour charge for the pre-warmed pool whether or not it’s invoked.
Ephemeral storage
Each container has a writable /tmp directory, sized from 512 MB up to 10 GB (configurable). Useful for downloading large files, intermediate processing, model artefacts. Contents persist for the lifetime of the container — survives warm invocations, gone on cold start.