Migrate RDS to Graviton (ARM)

AWS Graviton is an ARM-based processor AWS builds in-house and sells through its own instance families; for RDS that means classes like db.r6g and db.m6g. The same managed database engines (Postgres, MySQL, Aurora) run identically on ARM; applications don't change a line of code. The unit economics shift because ARM silicon is cheaper to run: AWS prices Graviton classes at roughly 10% less per hour than the equivalent x86, and throughput benchmarks show about 20% more work per dollar, so the effective price-performance improvement lands around 20%.

From a cost model the change is clean: same vCPU count, same memory, same storage, lower hourly rate. There's no renegotiation, no discount program to qualify for, and no commitment required. The saving shows up on the very first billing period after the instance class changes and recurs every month indefinitely. On a large production database that's thousands of dollars a year per instance.

The complication that matters for finance is Reserved Instance coverage. RIs are scoped to an instance family, not just a size, so a db.r5 RI does not apply to a db.r6g instance. Migrating to Graviton without addressing an active RI strands the reservation and puts the new instance on full on-demand rates, which can more than wipe out the saving for the remainder of the RI term. The pre-migration RI audit is not optional.

Dana is the FinOps lead reviewing the monthly Cost Optimization Hub output. Graviton migration candidates are listed for twelve RDS databases across three teams, with a combined estimated saving of $4,200/month at list rates. Before approving any migrations, Dana runs the RI audit: five of the twelve are covered by active x86 Reserved Instances, two of which expire within ninety days. She separates the work into two buckets: migrate the seven on-demand databases now for immediate savings, and schedule the five RI-covered databases to coincide with their RI renewal dates.

For the seven on-demand databases, Dana works with each team to confirm engine eligibility and assign a migration quarter. She models the saving per database using the current instance class price delta and adds the expected post-migration cost to each team's cloud budget, not as a new line, but as a planned reduction to the existing RDS line. The migrations are tracked as a cost initiative with a target save date and an expected monthly delta once done.

Dana's quarterly report shows $2,800/month realised from the first seven migrations, with the remaining $1,400/month gated on RI expiry. The CFO sees a specific, trackable number (not a vague 'we're working on it') and the engineering teams have a clear rationale for why five migrations are intentionally deferred rather than missed.

Staying on x86 RDS is not a neutral decision; it's a recurring, compounding overpayment. The Graviton price-performance delta is roughly 20% per database per month, which means every month a migration is deferred is another month of that margin flowing to AWS rather than the business. On a single large production database the monthly delta is hundreds to thousands of dollars; across a fleet of twenty or thirty databases it adds up to a material, forecastable cost line that simply should not exist.

The RI dimension makes the calculus more nuanced but not more favourable. If an x86 RI covers the database, the question is not whether to migrate but when, because an RDS Reserved DB Instance can't be cancelled, sold, or transferred, so migrating early simply means paying the stranded RI out alongside the new on-demand instance. The optimal timing is at RI expiry: buying a Graviton RI at that point captures both the ~20% class-level saving and the RI commitment discount, which typically stacks to 30-40% off on-demand rates. Every renewal cycle spent re-buying an x86 RI is a missed opportunity to lock in the lower baseline.

There is also a compounding generation tax. Graviton generations are released on roughly a two-year cycle: m7g and r7g already show another 10-15% gain over m6g and r6g. An estate stuck on db.r5 is two generations behind on price-performance and falls further back each cycle. The longer the migration is deferred, the wider the gap, and the larger the backlog when the organisation eventually acts.

The right framing for the finance pack is a migration pipeline: a dated list of every x86 database, its current monthly cost, the estimated post-Graviton cost, and the RI renewal date that gates the timing. That turns Graviton from a vague recommendation into a trackable cost initiative with a target realisation date and a named accountable owner per database.

AWS has a newer generation of server processors (ARM-based, called Graviton) that run the same managed databases at roughly 20% better price-performance than the previous x86 hardware. Migrating an RDS instance to Graviton means choosing the Graviton-class equivalent when changing the instance type; the database engine, the data, and the application all stay exactly the same. AWS handles the hardware switch during a maintenance window.

This is a rare category of cloud optimisation: the saving is structural and permanent, requires no application change, and compounds across every database in the fleet. The main leadership question is whether the organisation has a deliberate policy for moving databases to current-generation hardware, or whether it happens ad hoc when someone notices a recommendation. The Cost Optimization Hub flags eligible databases; the governance question is whether there is a standing process to act on those flags.

At one company the head of infrastructure, Priya, used to treat Graviton recommendations as a backlog item that got actioned whenever an engineer had spare time. Savings happened, but unpredictably, and the RI interaction caused two incidents where migrations accidentally increased the bill for several months. The problem wasn't technical competence; it was the absence of a process.

After establishing a quarterly database hardware review, the picture changed. Graviton candidates were triaged against RI coverage and engine eligibility on a fixed cadence. Migrations were batched by team and quarter, coordinated with RI renewal dates, and reported as a cost initiative with a named owner and a target realisation date. The saving became foreseeable and the RI trap became a checklist item, not a surprise.

The governance shift was small: one recurring review and a two-column spreadsheet. The outcome was that Graviton savings were realised consistently and on schedule rather than sporadically, and no migration ever accidentally increased the bill again. That is the difference between reacting to recommendations and managing the fleet by policy.

The cost case for Graviton is well-established: roughly 20% better price-performance, permanent, requiring no application changes. The leadership question is not whether to migrate (the economics are clear) it's whether the organisation has a systematic process for doing it, or whether it happens sporadically when an engineer finds time. The difference between those two states is typically tens of thousands of dollars a year in unrealised savings.

The second issue is the Reserved Instance interaction. Graviton migrations that ignore active RIs can temporarily increase costs for months, which damages confidence in the FinOps programme and creates a chilling effect on future migrations. A mature programme handles this by tying Graviton migrations to RI renewal dates, turning a potential trap into a scheduled event. That requires cross-functional coordination (FinOps, engineering, and procurement aligned on a calendar) which is an organisational outcome, not just a technical one.

The governance signal to look for is a Graviton migration pipeline: a standing view of eligible databases, their migration status, and their target completion quarter. That is the difference between reacting to Cost Optimization Hub recommendations and proactively managing the compute estate. An estate running on current-generation Graviton hardware, on a planned cadence, is a signal of process maturity, not just cost efficiency.