AWS Graviton migration, done safely.
Arm-based Graviton instances are usually cheaper and faster than the x86 ones you run today. We move your databases, caches and compute over, through your own review process, and you pay out of the savings.
Cristian Magherusan-Stanciu was an AWS Specialist Solutions Architect for Spot and Graviton, covering EMEA and later Germany and DACH, where helping customers adopt Graviton was part of the day job. He now does the same for LeanerCloud clients.
Why Arm is both cheaper and faster
It sounds like a contradiction, so here is the plain-English version. Picture a chip as two teams working together: one that manages instructions and one that executes them. On x86, instructions come in many different sizes, so the managing team has to do a lot of work just to figure out where each instruction starts and ends. That management logic takes up space on the chip and burns power.
Arm instructions are a fixed size, so the managing team's job is far simpler. That frees up chip area and power budget, which Arm spends on more execution units instead. Same silicon, more of it doing actual work. That is why Graviton can be cheaper to run and faster at the same time, and why Graviton chips are about 2.5x more power efficient than comparable x86 chips, which also cuts the carbon footprint of the workload.
For most teams the software side is a non-issue. Managed services and mainstream language runtimes already support Arm, so the change is usually a configuration one, not a rewrite.
Start with the managed services
The easiest wins are the managed services that expose the underlying instance type: RDS, ElastiCache and OpenSearch. There, moving to Graviton is often just changing the instance type, with no application changes at all. Managed services alone can give you up to 40% better price/performance from that one change.
EC2 is the next step. It carries a bit more to check, container images and any native dependencies need Arm builds, but the payoff is the same, and modern build pipelines produce multi-architecture images with little effort. We handle both.
Real before-and-after numbers
From actual client conversions. Anonymised, measured against the cost before the change.
RDS, single instance
~81%
$148 to $27 a month
An oversized, mostly idle m5.large database, under 3% CPU and using under 2GB of its memory, converted to a right-sized t4g.small Graviton instance.
ElastiCache cluster
~90%
roughly 10x cheaper
A cache provisioned at 20x to 300x the capacity it actually needed. Right-sizing plus Graviton brought it down to about a tenth of the original cost.
RDS fleet
60-90%
stacked, per database
Oversized m5.2xlarge production databases moved to a mix of r6g.large and t4g.xlarge Graviton instances: 60-70% at first, reaching about 83% with further downsizing and close to 90% with Reserved Instances.
Graviton on its own is typically a 10-15% saving on RDS. The larger numbers come from stacking it with right-sizing, query optimization and reserved capacity, which together often reach 50-80% off the original database cost. The same conversions cut the carbon footprint of those databases by 80-90%.
How we migrate without surprises
We start read-only. We look at real utilization, typically 30-minute averages over the last 30 days of CPU and memory, so the target instance is sized for how the workload actually behaves, not how it was originally provisioned. That is where most of the idle spend hides.
Every conversion then ships as a pull request through your own review and rollout process. Changes are low-risk and reversible: if a target ever proves too small, moving back up is another one-line change. We sequence the managed services first, prove the pattern, then take on EC2 and containers.
We size any Reserved Instances after the migration, against the Graviton footprint you will actually run, so you are not locking in a commitment on the oversized x86 instances we are about to remove.
Related
Graviton is one lever in our wider AWS cost optimization work, delivered the FinOps consulting way. See the cost and performance optimization service or start with a free audit.
Graviton migration questions
Which services should we move first?
Is Graviton risky for production databases?
Will our application code need changes?
How much can we actually save?
Thinking about Graviton?
Book a discovery call and we will show you which of your instances are worth converting first, and what it is worth.
Move to Graviton, keep the savings
An ex-AWS Graviton specialist converts your RDS, ElastiCache, OpenSearch and EC2. You pay out of what it saves.