# Graviton Migration Opportunity

> Graviton pricing runs to roughly 20% below equivalent x86 families, but ZopNight only recommends the swap when a shape-preserving ARM sibling exists (r5 to r6g, not wishful thinking), both live rates resolve, and the delta is plausible; a computed saving above 25% reads as bad catalog data and abstains.

Source: https://zop.dev/integrations/aws/recommendations/graviton-migration-opportunity
Updated: 2026-08-19

---

## The recommendation names a real target or stays quiet

"Move to Graviton" is only advice when a matching ARM instance exists. The rule derives the
sibling by family-token swap, r5.xlarge to r6g.xlarge, and abstains when no [shape-preserving ARM
equivalent](https://aws.amazon.com/ec2/instance-types/) exists: memory-optimized exotics like x2idn have no ARM twin, and a generic
"migrate to r7g" there would be advice the instance cannot follow. Both the source and
target [on-demand rates](https://aws.amazon.com/ec2/pricing/) must resolve from the live catalog, the target must actually be
cheaper, and the saving is the real rate delta applied to the instance's measured cost.

## The plausibility ceiling

Genuine x86-to-Graviton deltas top out around 20–25%. When the computed fraction exceeds
that, the likeliest explanation is a stale or mismatched catalog row, not a miracle
discount, and the rule abstains rather than clamping and shipping the bad number. What
does get emitted always shows the per-instance percentage computed from the same rates as
the dollar figure, so the badge and the amount cannot disagree.

## Who is excluded before price enters it

Windows and SQL Server instances abstain, because those workloads cannot re-platform to ARM.
Instances already on arm64 (checked by the authoritative architecture field, not just the
name) are skipped. And self-managed stateful data platforms (database, broker, and
search-cache boxes identified by engine metadata or name) abstain too: the same
classification that vetoes Spot and off-hours schedules for them applies with more force to
a binary-incompatible re-platform, where enterprise software frequently has no ARM build at
all.

## What no gate can verify for you

ARM compatibility of *your* stack is an assumption the operator must confirm: x86-only
binaries, AVX/SIMD-dependent code paths, and third-party agents or kernel modules without
ARM builds do not show up in instance metadata. Interpreted and JIT-compiled workloads such as
Java, Python, Node, Go and .NET 6+ migrate most cleanly; validate the full stack on one test
instance before touching a fleet.

## Survey your x86 estate

```bash
aws ec2 describe-instances \
  --filters Name=instance-state-name,Values=running \
  --query 'Reservations[].Instances[].[InstanceId,InstanceType,Architecture]' \
  --output table
```

The mechanical swap itself is stop → change instance type → start; the engineering is
everything before it.