Why Rust keeps our AWS bills boring

The best compliment we get on infrastructure isn’t “fast” or “elegant.” It’s silence. A client opens their AWS console three months after launch, sees a number that looks almost identical to last month’s, and closes the tab. Nothing to investigate. That boredom is the product.

A lot of that calm comes down to one decision we make early and deliberately: writing the hot paths in Rust.

Where the money actually goes

On most cloud bills, cost doesn’t track features — it tracks waste. CPU spent garbage-collecting. Memory provisioned for a runtime’s overhead rather than your data. Instances kept warm because cold starts hurt. A request that should take 8ms taking 80ms, multiplied across every request, every day.

None of that shows up in a demo. It shows up on the invoice.

Rust attacks the waste directly. No garbage collector means no GC pauses and no memory reserved to feed one. Predictable, low memory footprints mean we can pack more work onto smaller instances — or fit comfortably inside a Lambda’s lower memory tiers. Fast, consistent latency means fewer instances are needed to hold the same line on a p99 target.

A concrete example

We migrated one client’s image-processing pipeline from a Node service to a small Rust worker. The work itself didn’t change — resize, re-encode, write to S3. But the Node version needed 1GB of memory to stay comfortable and still spiked under load. The Rust version did the same job in 128MB with latency that barely moved whether it was handling one image or two hundred.

The bill didn’t drop by 10%. It dropped by roughly 70% for that workload, and — more importantly — it stopped moving. The team stopped getting paged about memory. The autoscaler stopped thrashing. The line on the cost graph went flat.

A flat cost line isn’t just cheaper. It’s predictable, and predictable is what lets you plan.

”But Rust is slow to write”

This is the real objection, and it’s fair. Rust asks more of you up front — the borrow checker is a strict reviewer that never has a good day. If we wrote everything in Rust, we’d be slower and you’d pay for it in hours.

So we don’t. We’re deliberate about it. The CRUD endpoints, the admin panels, the glue — those live in whatever language ships fastest, usually TypeScript. Rust is reserved for the parts that run hot and run constantly: the request path that fires a million times a day, the worker that chews through a queue, the service whose latency defines your p99.

That’s maybe 15% of the codebase carrying 80% of the runtime cost. Investing extra engineering hours there pays back every single month the system is alive. Investing them in a settings page does not.

The compounding part

Here’s the bit that’s easy to miss in a quote. A cheaper monthly bill isn’t a one-time saving — it compounds for the entire life of the product. A build that runs at 60% of the infrastructure cost doesn’t save you 40% once; it saves you 40% every month, for years. By the time a typical product is three years old, the running-cost gap has often dwarfed the difference in build cost.

That’s the trade we’re making on your behalf: a bit more engineering rigor in the few places that matter, in exchange for a bill so boring you forget to look at it. We think that’s a good trade. Your finance team definitely does.