Three relatively small event handlers became a useful test of how much runtime overhead we could remove by moving from Java to Rust.
A small workload with a meaningful cost
The functions processed events originating from SNS messages sent by another service. Their responsibilities were relatively focused. They were originally implemented in Java, and I wanted to understand whether a native implementation could reduce the time and resource overhead around that work.
The delivery topology and processing details are confidential. For background on the public service interface, AWS documents how SNS notifications can invoke Lambda functions. [1]
The proof of concept
I led the effort from the initial assessment through the rewrite and leadership demonstration. We ported three event handlers from Java to Rust, using AI-assisted development to help move through the rewrite.
The comparison showed an 80% reduction in runtime for the workloads we evaluated. The result gave us a concrete reason to pursue the migration for these handlers.
The reported improvement measures time taken to execute the workload. Absolute timings, sample sizes, traffic characteristics, and the internal benchmark methodology remain confidential.
Why Rust was worth considering
For a lightweight handler, the surrounding runtime and framework can represent a meaningful portion of the work. A compiled native implementation gave us an opportunity to reduce that overhead while keeping the handler’s actual responsibility focused.
Rust was attractive because of the performance and resource characteristics we observed. AWS’s documentation for running Rust functions on Lambda is a useful starting point for understanding the execution model. [2]
We also considered Go
Go was part of the assessment, in part because developer familiarity is a real engineering advantage. A language decision affects maintenance, debugging, onboarding, and the supporting tools, not only the first benchmark.
For these handlers and the constraints we assessed, Rust’s advantages justified moving forward with it. Developer familiarity remained part of the decision, along with the work needed to make the new implementation maintainable.
From demonstration to a migration effort
I demonstrated the proof of concept to L7 and L8 leadership. The work was greenlit to go further. The broader migration is now being carried forward, alongside work to build and expand the organization’s Rust toolkit.
The demonstration established the result for the three handlers we evaluated. Expanding the migration and supporting toolkit is the ongoing effort.
The lesson was to measure the fit
A small, well-defined workload gave us a useful way to evaluate a different execution model against the work it actually needed to perform.
Starting with three handlers gave us a concrete comparison and something tangible to demonstrate. The next challenge is turning that result into a maintainable path for other engineers, with the tooling and conventions that make adoption practical.
Public technical references
- Amazon Web Services. Invoking Lambda functions with Amazon SNS notifications. This describes the public service interface, not the internal project’s architecture.
- Amazon Web Services. Building Lambda functions with Rust. This describes the public Rust execution model, not the internal performance measurements.
The project narrative and 80% figure above are my first-person account. User counts, business impact, and internal implementation details are withheld; further technical disclosure depends on internal approval.