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.
Cristian Magherusan-Stanciu, who leads LeanerCloud, was an AWS Specialist Solutions Architect for Spot and Graviton, covering EMEA and later Germany and DACH. Helping customers adopt Graviton was part of the day job, and he now does the same for LeanerCloud clients.
Why Arm is both cheaper and faster
It sounds like a contradiction, so here's the short version. Think of a chip as two parts, one that manages instructions and one that executes them. x86 instructions come in many different sizes, so the managing part of the chip does a lot of work just to figure out where each instruction starts and ends, and that logic takes up chip area and burns power.
Arm instructions have a fixed size, so that management logic is much simpler, and the chip area and power budget go into more execution units instead. That's why Graviton can be both cheaper to run and faster, 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, since managed services and mainstream language runtimes already support Arm, so the change is usually a configuration one rather than 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, anonymized and 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 and look at real utilization, typically 30-minute averages of CPU and memory over the last 30 days. That way the target instance is sized for the actual load rather than for how it was originally provisioned, which is where most of the idle spend is.
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'll actually run, so you aren't locking in a commitment on the oversized x86 instances we're 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 scoped implementation project.
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 save?
Thinking about Graviton?
Get started and we'll show you which of your instances are worth converting first, and what it's worth.
Move to Graviton, keep the savings
An ex-AWS Graviton specialist converts your RDS, ElastiCache, OpenSearch and EC2, on a flat fee, a retainer, or a share of what it saves.