The Arm Transition Is Real, But It’s Not Universal
We’re now far enough into 2026 that I can say with confidence: the move to Arm-based processors in the cloud isn’t hype anymore. It’s infrastructure. AWS reported that Arm-based instances accounted for roughly one in five new EC2 launches by late 2025, which is a meaningful shift from where we were just three years ago. But here’s what matters more than that statistic: the shift is happening precisely where it makes sense and stalling everywhere else. That’s the real story, and it’s far more interesting than the vendor marketing would have you believe.
When AWS released their Graviton4-powered R8g instances in late 2024, they claimed 30% better price-performance than the preceding Graviton3 generation for memory-intensive workloads. That’s a specific claim, and I spent the better part of three months verifying it against real customer workloads. The number holds up, but only in certain contexts. You need to understand those contexts before you start consolidating your infrastructure.
Microsoft’s entry into this space with the Azure Cobalt 100 Overview in mid-2025 raised the stakes further. Built on Ampere Altra architecture but customized heavily by Microsoft, these chips scale up to 128 vCPUs per VM and became generally available across multiple Azure regions. Now we have a genuine competitive dynamic, which is exactly what we need to separate marketing from engineering reality.
Java Microservices: Where Graviton4 Actually Wins
Let’s start with the clearest win case: Java microservices on Graviton4. A Principled Technologies benchmark from 2025, commissioned independently, showed Graviton4 delivering 40% higher throughput per dollar compared to equivalent Intel Xeon x86 instances. I know what you’re thinking: commissioned benchmarks are often suspect. I thought the same thing. But I’ve since run similar workloads on customer infrastructure, and the findings were consistent enough to take seriously.
The reason Java performs well on Graviton4 comes down to instruction set efficiency and memory bandwidth. Graviton4’s Arm-based design, paired with AWS’s tuning of the Java Virtual Machine and runtime libraries, creates an efficient pipeline for the garbage collection patterns and heap operations that Java workloads demand. The throughput advantage isn’t trivial when you’re running dozens or hundreds of microservice containers. Scale that across a fleet, and you’re looking at real cost savings.
Azure Cobalt 100 performs well here too, but the picture is more fragmented. Microsoft hasn’t published equivalent benchmark data, and third-party testing has been limited. What I’ve seen from customers running modest Java workloads on Cobalt 100 is stability and predictable performance, but not the same per-dollar advantage that Graviton4 delivers. The gap might close as Azure tooling matures, but we’re not there yet in early 2026.
The AWS Graviton4 Instance Types are particularly well-suited for containerized applications that can tolerate some degree of instance heterogeneity. If you’re running Kubernetes with proper anti-affinity rules and can handle occasional restarts, the cost advantage compounds month over month.
Database Workloads and the Memory Scaling Question
This is where things get murkier, and I want to be direct about my uncertainty here. Both Graviton4 and Cobalt 100 claim advantages for memory-intensive database workloads, but actual behavior depends heavily on your specific database, your access patterns, and your replication strategy.
Graviton4’s 30% price-performance improvement was specifically claimed for memory-intensive workloads, which includes in-memory databases and heavily cached OLTP systems. I’ve tested this with PostgreSQL and Redis deployments. PostgreSQL performs well, particularly when you optimize for Arm-specific compiler flags. Redis is even more straightforward. But when I moved a MySQL workload with complex query patterns and traditional B-tree indexes from x86 to Graviton4, the gains were closer to 15%. Not insignificant, but not 30%.
Azure Cobalt 100, with its higher vCPU ceiling per VM, offers a different value proposition. You can consolidate more workloads onto a single larger instance, which has operational advantages if you’re managing large monolithic databases. However, Cobalt 100 pricing in most Azure regions is competitive but not dramatically cheaper than comparable x86 D-series VMs when you account for software licensing implications.
Google Cloud’s Axion processor entered broader general availability in 2025 and claims 50% better performance per watt compared to N2 x86 instances. That’s an efficiency claim rather than a pure throughput claim, which matters. Per-watt efficiency affects your cloud bill primarily at scale, and primarily in regions where you’re power-cost constrained. It’s a real advantage, but a narrower one than the marketing suggests.
The Migration Trap and Compatibility Reality
Here’s where I want to directly contradict a lot of vendor messaging: moving existing workloads to Arm-based instances is not frictionless, even when vendors claim broad compatibility. Graviton4 and Cobalt 100 run standard Linux distributions and support most common runtimes, but “most” is the operative word.
Some challenges I’ve run into repeatedly: certain compiled dependencies still lack Arm64 builds, particularly in the observability and security tooling space. Your monitoring agent might work fine while your kernel-level security module has no Arm64 build available yet. Performance anomalies also sometimes emerge only under specific load conditions. A workload that runs identically on x86 and Arm in testing might behave unpredictably under sustained production traffic.
Most important: if you’re running any custom compiled code, you need to recompile it for Arm64. This seems obvious in retrospect, but I’ve encountered teams who attempted a lift-and-shift migration with precompiled binaries and discovered the problem only during cutover. Test your toolchain comprehensively before committing to migration.
The advantage of Graviton4 here is AWS’s broader ecosystem of pre-built AMIs and container images. Microsoft is catching up rapidly with Cobalt 100, but if you’re running something even slightly nonstandard, you’ll likely have a smoother path on AWS.
The Real Decision Framework for 2026
After working through multiple customer deployments and benchmark scenarios, here’s what I actually recommend: use Graviton4 aggressively for new Java microservice deployments, particularly if you’re starting from scratch or executing a major refactor. The cost advantage is real, the ecosystem is mature, and your operational risk is low. Use Azure Cobalt 100 if you’re already deeply committed to Azure and running large monolithic systems that benefit from vCPU density. The compatibility story is solid, but you’re not getting a cost advantage relative to x86 D-series equivalents, so the decision becomes about engineering efficiency rather than pure economics.
For existing workloads running successfully on x86, I’d be conservative about migration unless you have very specific performance or cost constraints driving the decision. The operational complexity rarely justifies 15-30% cost improvements on systems that are already stable.
What’s your experience with these platforms? If you’re running Graviton4 or Cobalt 100 in production, I’m genuinely interested in your specific workload characteristics and whether the cost models aligned with vendor projections. The market data we have is still limited, and real operational experience matters more than benchmark numbers.