A few years ago, “the cloud runs on x86” was a safe approximation. It is no longer. Each of the three largest cloud providers now designs its own ARM-based server processor, and the trajectory is unmistakable: custom ARM silicon is moving from a niche price-performance option to a mainstream — in some cases default — choice for general-purpose cloud workloads. AWS’s Graviton line is the most mature, with the fourth generation now generally available; Microsoft’s Azure Cobalt and Google’s Axion are earlier on the same path. The shift has real implications for cost, efficiency, and how organizations think about the processor architecture underneath their workloads.

Why the Clouds Are Building Their Own Chips

The motivation is a combination of economics, efficiency, and control, and it is worth understanding because it explains why this is a durable trend rather than a passing experiment.

Cost. At hyperscale, designing a custom processor — even accounting for the substantial engineering investment — can be cheaper per unit of delivered compute than buying merchant silicon, because the provider captures the margin that would otherwise go to a chip vendor and can tune the design to its exact workloads. The savings are passed partly to customers (as lower instance prices) and partly retained.

Power efficiency. ARM’s architectural heritage in power-constrained devices translates into strong performance-per-watt in the server context. In an era where datacenter power is an increasingly binding constraint, a processor that delivers more useful work per watt is not just cheaper to run — it lets a power-limited facility do more within its electrical envelope. Efficiency has become a capacity question, not only a cost question.

Control and optimization. Designing the chip lets the provider tune it to the realities of its own fleet — its mix of workloads, its security requirements, its integration with custom networking and storage hardware. This vertical integration is hard for a merchant-silicon customer to match.

The Three Chips

AWS Graviton4 is the most mature of the three and sets the reference point. Graviton is in its fourth generation and is generally available, the culmination of several years in which AWS progressively expanded ARM across its instance families and made Graviton-based instances a mainstream choice rather than a curiosity. Each generation has widened the range of workloads for which ARM is the sensible default, and AWS reports a large and growing share of its new capacity running on Graviton. For an AWS customer, Graviton is no longer experimental; it is a well-supported, broadly applicable option with a track record.

Azure Cobalt 100 is Microsoft’s entry, a 64-bit ARM server processor that Microsoft has introduced into its fleet and is rolling out in preview for general-purpose workloads. It is earlier in its lifecycle than Graviton — fewer instance types, less accumulated production track record — but it signals Microsoft’s commitment to the same vertical-integration strategy, building silicon tuned to Azure’s own infrastructure.

Google Axion is the most recent of the three. Google announced Axion, its first custom ARM-based server processor, earlier in 2024, positioning it for general-purpose workloads with strong performance-per-watt claims relative to comparable instances. As of now it is announced and entering availability rather than broadly generally available across regions and instance families — it is the earliest of the three in real-world maturity, and customers should treat current claims as the provider’s own pre-broad-deployment figures rather than as settled, independently verified production results.

The common thread is more telling than the differences: all three major clouds have independently concluded that designing their own ARM silicon is strategically necessary. When three competitors converge on the same expensive bet, it is a strong signal about where the platform economics point.

What ARM Adoption Means for Workloads

For organizations consuming cloud compute, the rise of custom ARM silicon raises a practical question: should you move workloads onto it? The answer is increasingly “yes for most things, with some caveats.”

The case for moving. The headline draw is price-performance. ARM-based instances are typically offered at a lower price than comparable x86 instances for equivalent or better performance on many workloads, which translates directly into lower bills for the same work. For the large category of workloads that are not pinned to x86 — most web services, application servers, many data and caching workloads written in portable languages — the migration is often straightforward and the savings real.

The caveats. The friction lies in the cases where software is not architecture-portable. Workloads with x86-specific dependencies, binary-only components compiled for x86, or performance characteristics tuned to x86 microarchitecture need testing and sometimes rework before they will run well on ARM. The good news is that the modern software ecosystem is overwhelmingly portable: mainstream Linux distributions, container runtimes, language runtimes, and the bulk of open-source infrastructure software all support ARM as a first-class target. Multi-architecture container images make it practical to build once and run on either architecture. The remaining friction is concentrated in legacy and binary-only software.

A Distributed-Systems Footnote

There is a longer-run architectural implication worth noting on a site with this heritage. As the underlying processor architecture of the cloud diversifies — x86 and ARM coexisting, with custom accelerators alongside — the value of architecture-independent abstractions rises. Container orchestration, multi-architecture images, and workload schedulers that can place jobs across heterogeneous hardware become more important, because they let an organization treat a fleet of mixed-architecture machines as a single pool of capacity. This is, in essence, the heterogeneous-resource-federation problem that distributed-systems and grid-computing research worked on for years — matching workloads to the most suitable available resource across a pool of dissimilar machines — reappearing as a practical, everyday concern. The diversification of cloud silicon makes the case for portable, architecture-agnostic deployment stronger than it was when x86 was a safe assumption.

Practical Guidance

  • Default to evaluating ARM for new workloads. For greenfield deployments in portable languages, ARM-based instances are increasingly the sensible starting point on cost-performance grounds. Benchmark your actual workload rather than relying on generic comparisons.
  • Test before migrating existing workloads. The migration is usually straightforward for portable software, but verify with your real workload. Watch for x86-specific dependencies and binary-only components.
  • Build multi-architecture images. If you use containers, building multi-architecture images keeps your options open and lets you run the same artifact on either architecture without committing irreversibly.
  • Treat Graviton, Cobalt, and Axion as at different maturity stages. Graviton is production-proven; Cobalt and Axion are earlier. Factor that maturity difference into how much production weight you put on each, and prefer the more mature option where the workload is critical.
  • Factor efficiency into capacity planning. Where power or regional capacity is constrained, ARM’s performance-per-watt advantage can matter beyond the price sheet, by letting more work fit within a fixed power envelope.

The convergence of all three major clouds on custom ARM silicon is one of the more consequential infrastructure shifts of the past few years, precisely because it is happening quietly, underneath workloads, rather than as a headline feature. For most organizations the practical upshot is favorable: more choice, better price-performance, and improved efficiency — provided their software is portable enough to take advantage of it, which, increasingly, it is.

Further Reading

Back to Blog