x86 Linux EC2 instances with a same-size Graviton type at a lower On-Demand rate
What does ZopNight detect here?
ZopNight flags running x86 EC2 instances such as `m5`, `c5`, `r5` and `t3` when the same-size Graviton type, for example `m6g` or `t4g`, has a lower On-Demand rate. The saving is the rate gap applied to the instance's cost; Windows instances and self-managed databases are skipped, and gaps above 25% are discarded.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-059 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | Graviton rate lower, gap no more than 25% |
| Source | ZopNight |
| Permissions used | ec2:DescribeInstances · ec2:DescribeImages |
Where it applies
Graviton lists below comparable x86 instances
AWS says Graviton-based instances cost up to 20% less than
comparable x86-based EC2 instances. The US East (N. Virginia) On-Demand Linux rates bear that out
for common sizes: m5.large $0.096 against m6g.large $0.077, c5.large $0.085 against
c6g.large $0.068, and t3.large $0.0832 against t4g.large $0.0672.
The catch is that Graviton is ARM64. Native x86 binaries, code that depends on x86 instructions such as AVX, and third-party agents or kernel modules all need ARM64 builds. AWS keeps a Graviton getting started guide with per-language notes.
Listing x86 instances
aws ec2 describe-instances --filters Name=instance-state-name,Values=running \ --query 'Reservations[].Instances[?Architecture==`x86_64`].[InstanceId,InstanceType,PlatformDetails]' \ --output tablePlatformDetails shows Windows and SQL Server instances, which cannot make this move.
Instance families with a same-size Graviton target
| Current family | Graviton family priced against |
|---|---|
m5 | m6g |
m6i, m6a | m7g |
c5 | c6g |
c6i, c6a | c7g |
r5 | r6g |
r6i, r6a | r7g |
t3, t3a | t4g |
The size is kept exactly: c5.2xlarge is priced against c6g.2xlarge. The instance must be
running, not already ARM64, not Windows or SQL Server, and have a known monthly cost.
Instances the rule skips
Self-managed databases, message brokers and search clusters are skipped; those are the workloads where an architecture change is hardest to validate. Families outside the table have no target and produce nothing. A rate gap above 25% is treated as a catalog error and dropped rather than shown. The rule cannot see what software runs on the instance, so every finding carries the warning that ARM64 compatibility has not been verified. A same-architecture upgrade is priced separately by EC2 Older Instance Family.
Pricing the Graviton rate
saving = monthly cost x (x86 hourly rate - Graviton hourly rate) / x86 hourly rateFor m5.large to m6g.large in us-east-1 that is just under 20% of the instance’s cost.
Moving a workload to Graviton
- Build or pull ARM64 versions of your application, container images and agents.
- Launch a test instance of the Graviton type from an ARM64 AMI and run your test suite on it.
- Replace the instance: AWS requires the same processor architecture to change type in place, so an x86 instance cannot simply be stopped and switched.
- Shift traffic to the new instance, watch it for 48 hours, then terminate the old one.