x86 EC2 instances with a cheaper same-shape Graviton sibling actually in the catalog
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-059 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | graviton_migration.go |
Where it applies
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 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 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
aws ec2 describe-instances \ --filters Name=instance-state-name,Values=running \ --query 'Reservations[].Instances[].[InstanceId,InstanceType,Architecture]' \ --output tableThe mechanical swap itself is stop → change instance type → start; the engineering is everything before it.