Serverless is sold as a system that scales itself: you write the function, and as traffic grows AWS Lambda provisions whatever capacity it takes to keep up. That is true for the majority of workloads, and it is one of the better reasons to reach for Lambda. It is not unbounded. Lambda’s autoscaling is limited on two independent axes, and both are easy to miss until real traffic hits them: ...
AWS Lambda forwards everything you write to stdout into CloudWatch for free, and it keeps doing so even after your handler has returned. The moment you want richer signals than text logs, or you want to send them anywhere other than CloudWatch, that free path stops being enough: you have to push the data over the network yourself. On a function that freezes between invocations, every way of doing that trades off against one of two things. You either pay Lambda’s per-millisecond billing for the time spent waiting on a remote endpoint, or you risk dropping the telemetry entirely when the environment is suspended out from under you. This post walks the approaches from simplest to most reliable and names where each one bills you or loses signals. The problem is not specific to CloudWatch; it applies to any serverless environment that scales to zero. ...
The previous four posts (Part 1, Part 2, Part 3, Part 4) covered Rust on Lambda from cold starts to architectural fit. This one is a sibling rather than a sequel, focused on a specific AWS gotcha that bites anyone wiring an LLM behind API Gateway: HTTP API v2 does not support response streaming. The modern, recommended Gateway flavor is the wrong tool for streaming LLM tokens. The older REST API got streaming support in November 2025. If you reach for HTTP API v2 by reflex (and most “use the modern one” guides will tell you to), your token stream silently collapses into a single buffered response. ...
In Part 1, Part 2, and Part 3 I argued for Rust on Lambda and measured where the gains come from. This post draws the other edge of that fence: the shapes of work where Lambda is the wrong architectural choice, however lean the binary, and whichever language you wrote it in. The common thread across every case below is a single billing fact: Lambda charges you for wall-clock duration, including the time your handler spends waiting on IO. ...
In Part 2 I measured the cold start of a minimal Rust Lambda at 18 to 22 ms. This post breaks down what that init window is actually paying for, and which parts you can move. The short version: out of the four phases that make up a cold start, only two are under your control. The rest is AWS infrastructure that you inherit whether you like it or not. The Four Phases ...
In Part 1 I covered why Rust on AWS Lambda is worth exploring and laid out the project setup. This post measures the one number that matters most for serverless latency: cold start time. To get a clean floor measurement, I used the simplest possible endpoint with no database, no external calls, and no middleware. The Benchmark Setup The handler is a single health endpoint built with Axum and Cargo Lambda: ...
After watching Benjamen Pyle’s talk on Rust and AWS Lambda at QCon 2025, I got curious enough to try it myself. Rust is known to be one of the best languages for building high-performing services, used across different industries where performance and stability are non-negotiable. One would expect these services to run on dedicated instances (either in the cloud or on bare-metal machines) in order to take full advantage of its benefits. However, in this post I explore whether Rust can be efficiently used in AWS Lambda. ...