From x86 EC2 to Graviton: reading a $145,000 annual gap without jumping to conclusions

The scope of the figures, before any conclusion

The starting point is an x86 EC2 budget that went from roughly $780,000 over one year to roughly $635,000 the following year, at comparable functional load. The stated annual gap is $145,000, or about $12,083 per month, with monthly figures of $65,000 before and roughly $52,917 after.

These amounts are specific to the context described: a given region, a given pricing grid, a given set of workloads. They are not a discount rate applicable elsewhere. The mention of a comparable functional load is enough to condition the reading: if the functional scope, the volumes processed or the service levels moved between the two periods, the gap no longer measures a migration effect but a scope effect.

The first technical question, before even discussing processors, is therefore whether the two periods are comparable. A cost gap only makes FinOps sense if the unit of value produced is stable.

There is no one-to-one mapping between x86 and Graviton

The migration described does not target a single processor generation: m7g relies on Graviton3, while r8g and c8g rely on Graviton4. This means the same migration approach can lead to different gains depending on the family chosen, since the underlying generation and the family profile are not identical.

Above all, there is no universal one-for-one replacement between an x86 instance and a Graviton instance. The right sizing depends on the processor, the memory, the software architecture and the load profile. In other words, the size mapping that works for a low-CPU asynchronous service does not transfer to a database, a compute engine or a network gateway.

The practical consequence is simple: a Graviton migration is not driven by a fixed conversion table, but by a measurement campaign per workload. The list price gives a direction; it does not give the sizing.

The five-step protocol, and the logic behind each step

The protocol is organised in five stages: benchmark per workload before choosing the family and the size; test the compatibility of binaries, agents and dependencies; recompile components available only on x86; switch progressively from development to staging and then production; measure cost per transaction before and after migration.

The order of the steps carries most of the reasoning. Benchmarking before choosing the family avoids anchoring the decision on an hourly price gap rather than on an actual need for resources. The compatibility test comes before recompilation because it separates what works as is from what requires engineering work. Recompilation is often the invisible cost line: it does not appear on the cloud invoice, but it consumes team time and can delay the switch.

The progressive development, staging, production sequence is a risk control rather than an optimisation. It makes it possible to detect a performance regression or unexpected behaviour on a non-critical workload before committing production. Finally, measuring cost per transaction is what protects the conclusion: it is the only metric that remains valid if volumes change after the migration.

What the price gap actually says

In the pricing grid and the region used for the comparison, m7i.4xlarge is given at about $0.80 per hour and m7g.4xlarge at about $0.64 per hour. The hourly gap is clear, but it remains a list-price gap for a given shape: it does not prove that a given x86 workload runs at equivalent performance on the corresponding Graviton shape. That is precisely what the per-workload benchmark has to establish.

The financial consolidation is as follows: $780,000 per year, or $65,000 per month, before migration; $635,000 per year, or about $52,917 per month, after; a gap of about $12,083 per month and $145,000 per year.

As an illustration, and not a forecast, a fleet dominated by memory or compute-intensive families would lead to comparing other pairs of shapes, with hourly ratios different from the one cited here. The reasoning stays the same, the amounts change. Any projection should therefore be redone on the pricing grid and region actually used, at the date of the decision.

Decision criteria that do not appear on the invoice

Cost per transaction is the best arbiter, but several criteria condition its stability. The compatibility of observability, security and backup agents must be checked: an unsupported agent can force you to keep x86 nodes and reduce the expected gain. Recompiling x86-only components must be estimated in person-days, not just in technical feasibility.

Other questions deserve to be asked: do existing savings commitments still cover the new fleet, and is the displayed gap actually realised or partly absorbed by a commitment that has become poorly calibrated? Are any licences billed per core or per socket sensitive to a change of architecture? Do the non-regression tests cover latency and not only throughput?

Finally, the opportunity cost has to be acknowledged: tying up a team on recompilation for several weeks may be less profitable than another optimisation lever, even if the hourly price looks more favourable on paper.

A working checklist, offered as a suggestion

This list is a suggested method, to be adapted to the context. Inventory the x86 instances by family, by workload, by monthly cost and by cost per transaction, in order to identify high-volume candidates. Select a small number of representative workloads rather than aiming for a global switch.

For each candidate, define a reproducible reference load, benchmark x86 and Graviton before choosing the family and the size, then recalculate the required size rather than transposing the existing one. Draw up the inventory of binaries, agents and dependencies, identify components available only on x86 and estimate the recompilation effort.

Set explicit go/no-go criteria, including performance non-regression and not only price. Run the switch through development, staging and then production, with a rollback plan. Measure cost per transaction after migration on the same scope as before, in the same region and on the same pricing grid. Finally, document the workloads that were not migrated and the reason for that choice: that is often where the next gain lies.

The question to settle before generalising

The open question raised at the end of this comparison works well as a framing device: which x86 workload has actually been benchmarked against Graviton? As long as the answer remains vague, the $145,000 gap remains an observation on a given fleet, not a transferable reference.

The protocol described provides a reasonable framework. It does not remove the need to document the comparable functional load assumption, to date the pricing grid used and to specify the region. A stated gain without those three elements is hard to replicate, and therefore hard to defend in a budget committee.