Migrate Lambda functions to Graviton (ARM)

Lambda is the "serverless" line on the cloud bill — you pay per invocation and per millisecond of run time, with no servers to manage. AWS offers two underlying chip types for it, and the cheaper one (called Graviton, AWS's own ARM processor) lists at about 20% less for the same work. Most functions are running on the more expensive default chip purely because that's what they got when they were first deployed, not because of any technical requirement.

The reason this is worth more than a flat 20% is that functions tend to finish faster on the cheaper chip, and Lambda charges by the millisecond. So you get the lower rate and you're billed for fewer milliseconds — the two stack. In practice a clean migration often lands a 25-30% reduction on the affected functions' compute cost, which is unusually generous for a change that, on simpler functions, is a configuration toggle rather than a rewrite.

From a budgeting standpoint the useful framing is that this is a rate optimisation, not a usage cut — the work the functions do is identical, you're just paying less per unit. That makes it clean from a chargeback perspective (no team loses capability, no SLA changes) and easy to forecast: take current Lambda compute spend, identify the share still on the expensive chip, and the recoverable amount is roughly a fifth of that, often more. The number to ask for at the monthly review is "what percentage of our Lambda compute is still on x86?"

Sam is the finance partner embedded with the platform team. At the monthly cost review the Lambda line is $6,200 and roughly flat. Sam asks the question that's now standard on the agenda: "What share of our Lambda compute is still on the old, more expensive chip?" The answer is about 80%. Sam does the back-of-envelope: 80% of $6,200 is ~$4,960; a 20% rate cut on that is ~$990 a month, and engineering thinks the faster-execution effect pushes the realised number closer to $1,300 — call it $15k a year, on a change that's mostly configuration for the bulk of the functions.

The conversation isn't technical. Sam doesn't ask about wheels or aliases. She asks three things: how much of the spend is the easy pure-interpreted group versus the harder native-dependency group, what's the rollout plan, and how will we know it's done. Engineering splits it: ~70% of the dollars are easy flips landing this sprint, the rest needs build work over the following month. Sam adds "% of Lambda compute on arm64" as a standing line on the cost pack so the migration's progress is visible and can't quietly stall.

Two months later the line reads 90% arm64 and Lambda compute has dropped to ~$4,900. Sam notes the realised saving slightly beat the projection because right-sizing memory after the switch added a few points — a reminder that this category usually pays back a bit more than the headline 20%. The metric she keeps watching isn't the dollar total, it's the arm64 percentage: as long as new functions default to arm64, the number stays healthy without anyone chasing it.

The direct line-item impact is a clean rate saving: roughly a fifth of whatever Lambda compute is still on the expensive chip, often a little more once the faster execution is counted. For most organisations Lambda is a small-to-moderate slice of total cloud spend, so this won't move quarterly numbers alone — but it's one of the highest-confidence savings on the menu, because the work doesn't change and there's no capability trade-off to negotiate. When budgets are tight, high-certainty rate cuts are exactly what you want to bank first.

The forecasting story is unusually clean. Unlike usage-reduction initiatives — where the saving depends on behaviour change that may or may not stick — this is a rate change on identical work, so the projection is reliable: identify the x86 share, take ~20% of that compute spend, and add a modest uplift for the execution-speed effect. You can put that number in the forecast with confidence and expect actuals to meet or slightly beat it, which is the opposite of most optimisation line items.

It interacts with right-sizing in a way finance should track as one initiative, not two. Because the optimal memory setting shifts after the move, the full saving requires re-tuning memory afterwards — if engineering reports "we migrated to Graviton" but the realised saving is only the rate cut, the right-sizing half is still on the table. The metric to watch is realised saving versus the rate-only projection: beating it slightly is the sign the right-sizing was done too.

And it's a leading indicator of engineering hygiene. A high and persistent x86 share usually means new functions are deploying on the default architecture with no one minding the efficient option, which tends to correlate with other defaulted-and-forgotten waste. The healthy end state isn't a one-time migration; it's that arm64 becomes the default for everything new, so the percentage stays high without anyone running a campaign.

AWS sells Lambda on two chip types; its own ARM chip (Graviton) is about 20% cheaper for identical work and frequently runs faster, so the realised saving is often higher. Most functions are on the pricier default chip by inertia, not by need. Moving them is a rate optimisation: nothing the business depends on changes, the bill just goes down.

The one question to ask is "what share of our Lambda spend is still on the old architecture, and what's the plan to move it?" A large share signals an easy, low-risk saving left on the table; a small and shrinking share signals an engineering culture that defaults to the efficient option. The dollars are real but modest — the more important signal is whether the org captures obvious, low-risk savings as a matter of routine.

At one company the quarterly review used to carry a Lambda cost line that drifted upward with usage and never got questioned — it was "just serverless, it scales with the business." Then someone surfaced that four-fifths of it was running on the more expensive of two interchangeable chip options, for no reason beyond the default. The exec sponsor didn't ask for a cost-cutting project; she asked one question: "Why isn't the cheaper, faster option the default for anything new we build?"

Within a quarter the answer had changed the engineering norm, not just the bill. New functions shipped on arm64 by default, the existing fleet was migrated function-by-function behind safe traffic-shifting, and the Lambda compute line dropped by roughly a quarter even as usage grew. The saving was real but modest in absolute terms; the more valuable outcome was that the team now reached for the efficient option automatically.

That's the right outcome state. The goal was never "migrate every function" as a heroic push — it was making the cheap, fast default the path of least resistance so the saving compounds quietly as the business scales. The cost line became a confidence signal: if the arm64 share is high and rising, the team is capturing obvious wins without being told to.

The absolute dollars here are usually modest, so this isn't tracked for its size — it's tracked because it's a textbook example of a free, low-risk saving and the org's capture rate is the real signal. A cheaper, often-faster chip option sits one configuration flag away for most functions; if a large share of spend is still on the expensive default, the question isn't really about Lambda, it's about whether the engineering culture reaches for obvious efficiency wins without being told.

The second-order point is forecasting confidence. Because this is a rate optimisation on identical work — nothing the business depends on changes — it's one of the most predictable savings available, which makes it a good proof point for the FinOps operating model. An org that captures it cleanly and defaults new work to the efficient option is demonstrating the discipline that compounds across every other, larger spend category.