AWS Graviton5 is generally available. 192 cores, up to 35% faster ML inference, and a memory bandwidth bump that makes previous Graviton generations look slow. If you run batch ML jobs on EC2, the upgrade path is clear.
But hardware specs are not the interesting part of this launch.
The interesting part is the Nitro Isolation Engine.
What Nitro Does
Every EC2 instance sits on a physical host alongside other instances. The thing preventing your workload from touching another customer's memory is the Nitro hypervisor. It handles I/O, enforces resource limits, and maintains the security boundary between VMs.
AWS has been iterating on Nitro since 2017. With Graviton5, they made a claim they have never made before: the isolation properties of the Nitro Isolation Engine are formally verified.
What "Formally Verified" Actually Means
Formal verification is not testing. Testing checks that a system behaves correctly for a set of inputs. Formal verification uses mathematical proofs to show a system behaves correctly for all possible inputs.
AWS used automated reasoning tools to prove that the Nitro Isolation Engine cannot allow a guest VM to read or write memory belonging to another VM. Not "we tested this extensively." Not "we have never seen a breach." A mathematical proof that the boundary holds.
This matters because the failure mode for hypervisor escapes is catastrophic. A bug in VM isolation is not a performance issue or a data corruption risk. It is a complete security boundary collapse. Formal verification is the only way to make a meaningful claim that the boundary holds.
What This Means for Your Architecture
If you are running multi-tenant workloads on EC2 and security posture matters to your compliance team, this is a concrete answer to the "is shared hardware safe?" question. The answer is now "yes, and here is the proof."
For ML inference workloads specifically, Graviton5 changes the cost model. 35% faster throughput at the same instance cost means you can either cut instance count or handle more load at the same budget. For teams running large inference fleets, run the numbers before your next capacity review.
The migration path from Graviton4 is straightforward if you are already ARM-compatible. The main friction point is typically native dependencies in your container images. Check for x86-specific binaries before you schedule the migration.