AWS Graviton5 arrived on December 4, 2025 with EC2 M9g in preview, and it’s not a minor refresh. We’re talking 192 cores per chip, a 5× larger L3 cache, up to 25% better compute performance than the prior generation, and meaningful I/O gains. If you’ve already shifted to Arm on M6g–M8g, this is your next price‑performance step. If you’re still on x86, AWS Graviton5 finally removes most excuses—there’s now enough per‑core performance, cache, and bandwidth to move mainstream application servers, web tiers, and many data platforms without heroics.
What AWS Graviton5 actually changes
Let’s get concrete. The M9g preview introduces a single‑package 192‑core design with a cache that’s five times larger than the previous generation. Compared to M8g, AWS reports up to 25% higher compute performance, and for typical workloads the deltas are even more practical: up to 30% faster for databases, up to 35% for web apps, and up to 35% for select machine learning tasks. Network bandwidth averages are up about 15% across sizes, EBS bandwidth about 20%, and the largest sizes can double network throughput. The chip uses a 3nm process and bare‑die cooling in AWS’s racks to keep clocks and thermals consistent under load.
Security also stepped forward. Graviton5 instances bring always‑on memory encryption, per‑vCPU dedicated caches, and support for pointer authentication. The new Nitro Isolation Engine applies formal verification to prove workload isolation—useful language for auditors and risk teams who ask how the cloud enforces tenant boundaries.
One more timeline detail matters for planning: M9g (general purpose) is in preview now. Compute‑optimized C9g and memory‑optimized R9g are planned for 2026. If you depend on extra memory per vCPU or tight FP/compute density, pencil those families into your 2026 refresh rather than forcing a fit today.
Should you move now or wait?
Here’s the thing: “Preview” scares some teams. But Graviton previews historically harden quickly, and the Arm software ecosystem is mature. If you run:
• Stateless web services or GraphQL/gRPC backends
• JVM workloads (Spring, Quarkus, Micronaut) or Node/Python APIs
• Caches (Redis, Memcached) and open‑source databases (PostgreSQL, MySQL)
• Analytics engines that scale horizontally (Spark executors, Flink task managers)
• EDA/simulation pipelines already proven on Graviton4
…you can start migration with low risk. Hold if you require specialized x86 instructions, niche commercial agents that lack Arm builds, or if your memory‑per‑core profile suggests waiting for R9g.
The 90‑Day Graviton5 adoption plan
This is the exact sequence we use with clients. Adjust the cadence to your release trains, but don’t skip steps.
Days 0–14: Inventory, risks, and a branch cut
• Inventory services by runtime (JVM, Node, Python, Go, Rust, C/C++). Flag anything with native extensions or custom C libraries.
• Check base images and OS support. Use multi‑arch images or build Arm64 tags for Alpine/Ubuntu/Amazon Linux 2023.
• Compile a “blockers” list: proprietary agents (APM, EDR), kernel modules, or data plane add‑ons missing Arm builds.
• Establish a long‑lived branch for Arm changes; wire CI to build Arm64 containers in parallel with x86. Sign and store both.
Outcome: a clean bill of materials for Arm, a build pipeline that produces Arm images, and a short, prioritized blocker list with owners.
Days 15–30: Baselines on your current fleet
• Capture golden metrics on production: p50/p95 latency, CPU %, RSS, GC pause times, request concurrency, EBS throughput, and network egress per service.
• Save representative traffic traces to replay later (e.g., 15–30 minute spans during peak).
• Lock tooling: same APM, same log/trace sampling, same dashboards, so you can compare apples‑to‑apples.
Outcome: baselines that will tell you whether the Graviton5 gains show up in your application, not just in vendor graphs.
Days 31–45: Port and stand up on M9g (preview)
• Turn on Arm64 builds for all services. For Java, upgrade to a current LTS JDK with Arm64 optimizations.
• Rebuild native modules. For Node, ensure all native dependencies publish prebuilt Arm64 binaries or compile during Docker build.
• Stand up a staging environment on M9g. Match instance classes and storage types to prod (gp3 parameter parity matters).
• Validate agents (APM, EDR, sidecars). Swap to Arm64 agents where needed or run dual‑arch DaemonSets in Kubernetes.
Outcome: a working staging stack on M9g with the same observability and controls you run in production.
Days 46–60: Load, profile, and tune
• Replay traffic traces against staging; scale until CPU hits 60–70% to find the knee of the curve.
• JVM tuning: re‑baseline heap sizes; Graviton5’s larger cache often shifts the optimal heap and GC parameters. Test ZGC or Shenandoah if you’re still on G1.
• Network: confirm enhanced networking (ENA) is enabled; validate pod and service MTUs to avoid fragmentation with higher throughput.
• Storage: right‑size EBS gp3 IOPS/throughput caps so the instance can exploit the average 20% EBS bandwidth uplift.
• Containers/K8s: assign CPU requests/limits realistically; on Arm, over‑constraining leads to scheduler thrash. Use topology‑aware spreading to keep hot pods local.
Outcome: a tuned staging profile and an estimate of how many M9g instances replace your current nodes per service.
Days 61–75: Controlled canary and SLO gate
• Roll canaries at 5–10% traffic behind the same load balancer.
• Use shadow reads/writes for stateful systems if feasible. For databases, start with replicas or read pools on M9g.
• Enforce SLO gates: canaries must hold or beat p95 latency and error budgets for a full business cycle.
Outcome: confidence that M9g behaves under real traffic, not just synthetic load.
Days 76–90: Ramp and retire
• Ramp to 25%, 50%, 100% while watching cost and saturation. Plan a rollback lever (feature flag or target group) at each step.
• Decommission or repurpose old nodes. Don’t strand EBS volumes; snapshot or migrate to right‑sized gp3 with proper QoS.
• Update your standard images and templates so new services default to Arm64 on M9g.
Outcome: M9g is your default for the targeted workloads. You’ve banked the performance headroom and simplified the fleet.
Performance tuning checklist for Graviton5
Not every knob matters. These consistently pay off:
• Build for Arm64 with native libs compiled in CI; avoid on‑node compiles.
• Use current compilers (GCC/Clang) and JDKs that include Arm64 optimizations.
• Right‑size EBS gp3 throughput and IOPS; don’t carry over under‑provisioned gp3 settings from x86.
• Confirm ENA is active and MTUs are consistent across pod, node, and VPC.
• Align container CPU requests to whole cores for latency‑sensitive services; noisy neighbors are rarer with per‑vCPU caches, but core packing still matters.
• Re‑measure GC and thread pools; the 5× larger cache and higher memory speeds change optimal settings.
Security and compliance: what Nitro Isolation Engine means
Risk teams love facts. With Graviton5, your fleet inherits always‑on memory encryption and per‑vCPU cache isolation. The Nitro Isolation Engine adds a formally verified code path that proves tenant isolation properties. Pair that with AWS’s zero‑operator‑access design for EC2 hosts and you have a crisp story for audits: customer data is shielded by design, not just by policy.
Translate that into controls: document isolation guarantees in your risk register, update your shared responsibility matrix, and—if you’re in regulated industries—reference Nitro’s verification claims in your control evidence. The net is less time in audit meetings, more time shipping.
How much will you actually save?
Price‑performance is the headline, but your savings depend on architecture. Here’s a pragmatic modeling approach:
• Calculate your current cost per 1,000 requests or per core‑hour at steady‑state utilization (e.g., 55–65%).
• Re‑benchmark on M9g and compute the same metric. Use production traffic traces to reflect cache and branch behavior.
• Add EBS and data transfer changes. If network bandwidth doubles on your largest sizes, you may consolidate nodes and reduce cross‑AZ chatter.
• Subtract migration cost (engineering hours × rate) amortized over 12–18 months.
If the curve bends in your favor and SLOs hold, you move. If not, you’ve paid for clarity and can revisit C9g/R9g in 2026.
People also ask: quick answers for your team
Is Graviton5 ready for production?
M9g is currently in preview. Many organizations run previews for non‑critical tiers first (stateless web/API, caches) to capture gains early while waiting for GA and for C9g/R9g in 2026. Treat preview as a safe pilot with guardrails, not a free‑for‑all.
Will my containers just work?
Most do if you publish Arm64 images. The usual snags are native modules in Node/Python, pinned x86 agent binaries, and custom images built on old distros. Solve those in CI and you’ll avoid surprises in prod.
What about Java and Python performance?
Modern JDKs perform well on Arm64, and Graviton5’s larger cache often improves tail latency under load. Python benefits from native wheels for Arm and C‑extension rebuilds; for data science stacks, test wheel availability early.
Do I need to change my autoscaling strategy?
Probably. With higher per‑node throughput, scale‑out thresholds should shift to keep headroom while avoiding over‑provisioning. Re‑tune cooldowns and target utilization to reflect the new knee in your curves.
Architecture side effects you should plan for
Graviton5’s bandwidth lifts show up in real architectures. Microservices meshes often see fewer queue spikes when network bandwidth rises ~15% on average, and storage‑heavy services stop stalling when EBS bandwidth increases around 20%. The largest sizes, with up to 2× network throughput, help chatty internal services consolidate without choking east‑west links. That’s an opportunity to simplify topologies and reduce the number of nodes you manage.
And because M9g is general purpose, you’ll want to map data paths deliberately. Keep hot working sets close (bigger cache helps), enable connection pooling across services, and confirm TLS offload behavior with your sidecars. Any bottleneck you ignore will nullify CPU gains on day one.
When not to migrate yet
• You need memory‑heavy instances now. Wait for R9g in 2026 if your in‑memory datasets push past current M9g limits.
• You rely on x86‑specific instruction sets or proprietary software that lacks Arm support.
• Your observability/security stack doesn’t publish Arm64 agents yet. Don’t amputate visibility for speed.
A realistic roadmap beyond compute
Compute upgrades work best alongside storage and networking moves. If you’re planning a data lake refresh or large object migrations, coordinate with your storage team. For example, if you’re consolidating backups or analytical artifacts, map the operational steps with a proven migration plan like our S3 50TB migration playbook. If you’re modernizing interconnects across providers, align routing and bandwidth expectations up front—we’ve outlined tradeoffs and actions in our multicloud interconnect guide. And if AI training is on your 2026 calendar, pencil how Graviton5 web and data tiers pair with the accelerators covered in our Trainium3 UltraServers plan. For teams building agentic apps, ensure your inference paths and event buses won’t be the new bottlenecks; see the launch plan in our Bedrock AgentCore guide.
The Graviton5 readiness rubric (print this)
Use this simple A/B/C rubric in your architecture review:
• A‑Tier: Stateless services, web/API tiers, streaming consumers, caches. Action: migrate in preview with canaries.
• B‑Tier: Stateful data tiers (PostgreSQL read pools, MySQL replicas), analytics workers, batch compute. Action: pilot behind read traffic or with batch windows; full move on GA.
• C‑Tier: Memory‑bound in‑memory databases, specialized x86 software, or heavy FP workloads expecting C9g. Action: wait for R9g/C9g in 2026.
Gotchas teams hit on day one
• Mixed‑arch clusters: If you run Kubernetes, segregate Arm/x86 nodes. Label and taint appropriately; let only Arm64 pods schedule to M9g.
• Multi‑arch images: Don’t rely on manifest lists alone—verify image digests deployed match Arm layers.
• Build pipelines: QEMU emulation during Docker builds is slow and flaky. Build natively on Arm runners (EC2 or modern build services) to remove that variable.
• Tiny differences in math libs: Rare, but deterministic behavior for ML pre‑/post‑processing can vary across architectures. Validate outputs and thresholds.
• EBS gp3 inertia: Many teams copied gp2 defaults years ago and never tuned gp3 throughput. Fix it or your storage stalls will mask CPU gains.
What to do next
1) Decide your pilot scope this week. Pick two A‑tier services and one B‑tier job.
2) Turn on Arm64 builds in CI. If you can’t produce Arm images by Friday, that’s your first blocker to burn down.
3) Stand up a staging stack on M9g and replay production traces. Publish results internally to build support.
4) Draft your SLO gates and canary plan now so approvals don’t stall rollout later.
5) Plot your 2026 checkpoints for C9g/R9g and align with any AI or data platform upgrades you’ve scheduled.
AWS didn’t just add cores; they reshaped the compute, memory, and isolation story to make default cloud choices better. Move pragmatically, measure relentlessly, and you’ll feel the gains where it counts—slimmer bills, steadier tail latency, simpler fleets.
If you want help scoping a pilot or validating your stack on Arm, our team has done this across startups and large enterprises. See what we build in our portfolio, explore services, or just reach out via contact.
