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.
The Setup
For this experiment I used Cargo Lambda, a brilliant Rust crate that simplifies running, building, and deploying Rust code to Lambda. As the HTTP library I chose Axum, from the team behind Tokio, which is considered one of the fastest and most efficient libraries for building REST APIs.
To measure how long the API takes to complete a cold start and serve a request, I implemented a single health endpoint that returns HTTP 200 and a "healthy" string. This proves the bare minimum needed to load the Lambda runtime and start serving requests.
Why This Approach Is Worth Considering
The most immediate benefit is the dramatic simplification of infrastructure decisions. There are no Docker images to build, no container registry to manage, no orchestration layer to configure, and no load balancer to provision. You go from code to a publicly reachable endpoint in a fraction of the time compared to a containerized service.
Scenarios Where This Shines
- You need an API service running within a few hours. The scaffolding overhead is minimal:
cargo lambda new, write your handler, deploy. - Your service is self-contained and relatively small. Lambdas excel when a function has a clear, bounded responsibility.
- You want to avoid container complexity. No Dockerfile, no image build pipeline, no ECS/EKS cluster to reason about.
- Cost matters. Rust’s low memory footprint and fast execution time translate directly to lower Lambda bills. Because Lambda pricing is based on GB-seconds, a Rust function that runs in 2 ms and uses 64 MB is dramatically cheaper than a Node or Python equivalent for the same workload.
- Latency is user-perceptible. Rust’s cold start times on Lambda are among the lowest of any runtime. The TechEmpower benchmarks consistently place Rust frameworks at the top, and that efficiency carries into Lambda invocations.
Where This Approach Struggles
- Long-running request/response cycles. API Gateway has a 29-second integration timeout, and Lambda has a configurable maximum execution duration. If your handler can legitimately take minutes, Lambda is the wrong primitive. Consider Pub/Sub, step functions, or a fire-and-forget pattern instead.
- Long-running background threads. Lambda’s execution model is invocation-scoped. Any background work started during a handler may be suspended or killed between invocations. It does not run continuously the way a long-lived process would.
- High concurrency on slow requests. Each concurrent in-flight request consumes one Lambda execution environment. AWS applies per-function and per-account concurrency limits, so if many slow requests arrive simultaneously and exhaust the concurrency pool, new requests will be throttled and fail. For workloads with genuinely high concurrency and slow handlers, a containerized service with a proper connection pool is a safer fit. I will cover concurrency strategies in a separate post.
Caveats
Cross-compilation can be frustrating to configure initially. In my case, building for the aarch64-unknown-linux-gnu target (Lambda’s ARM64 runtime on Amazon Linux) from an Apple M3 Mac produced linker errors. In my case I had to use cargo lambda build --compiler cross --release --arm64 and set up Colima as the container runtime so the cross-compiler could do its job.
What’s Next
This post is just the starting point. In upcoming posts I plan to go deeper into benchmarking cold start times, handling concurrency limits in practice, and structuring a real-world Rust Lambda service beyond a simple health check. Stay tuned.