For most of the last decade, choosing cloud compute meant choosing among x86 instance families. That default no longer holds. Each of the three largest cloud providers now designs its own Arm-based processors, and 2026 brought a new generation from all of them: AWS Graviton5, Azure Cobalt 200 and Google’s expanding Axion lineup. Providers market these chips on price-performance and energy efficiency, and the software ecosystem has matured to the point where many workloads run on Arm with little or no code change.
Yet Arm adoption remains uneven. Many organizations have moved a few container workloads and stopped there, while others have never tested Arm at all. This guide explains what is new in 2026, which workloads are good candidates, what can go wrong and how to make a structured decision that fits your architecture rather than following vendor marketing.
What Changed in 2026
AWS Graviton5
AWS introduced Graviton5 in December 2025 and, in a June 2026 post, announced general availability of Graviton5-powered EC2 M9g instances and the new M9gd variant with local NVMe storage. According to AWS, Graviton5 has 192 cores, an L3 cache five times larger than the previous generation, up to 33 percent lower inter-core latency, DDR5-8800 memory and PCIe Gen6. AWS claims up to 25 percent better compute performance than Graviton4, with up to 35 percent faster web applications and machine learning inference and up to 30 percent faster databases. The instances are built on the sixth-generation Nitro System, and AWS also announced a Nitro Isolation Engine that it describes as the first formally verified cloud hypervisor. At launch, M9g was available in four regions in the United States and Europe. AWS states that Graviton powers more than 350 instance types and serves more than 120,000 customers.
Azure Cobalt 200
Microsoft announced Cobalt 200 virtual machines at Build 2026, in a post dated June 2, 2026, as an early access preview with broader availability expected later in the year. Cobalt 200 uses Arm Neoverse V3 cores in a 3nm chiplet design, with up to 128 vCPUs, 3 MB of L2 cache per core, 192 MB of system-level cache and memory encryption enabled by default. Microsoft claims up to 50 percent better CPU performance than Cobalt 100, with workload-specific gains that vary widely. The new families span general-purpose, memory-optimized, high-memory and storage-optimized series, and Microsoft states full compatibility with workloads already running on Cobalt 100. Check current regional availability before planning production use, since the preview launched in a limited set of regions.
Google Axion
Google’s Axion processors first appeared in C4A instances. In January 2026, Google announced general availability of N4A, an Axion-based family using Arm Neoverse N3 cores with up to 64 vCPUs and 512 GB of DDR5 memory. N4A is the first Axion family to offer custom machine types, letting you set vCPU and memory independently. Google claims up to twice the price-performance and 80 percent better performance per watt than comparable current-generation x86 virtual machines, based on its own benchmarks and list prices as of October 2025. Google also announced a C4A bare-metal option and support across Compute Engine, Google Kubernetes Engine, Dataproc and Batch, with GKE able to mix C4A and N4A nodes using custom compute classes.
Vendor benchmarks tell you what is possible; only your own workload tests tell you what is real. Treat every price-performance claim as a hypothesis to validate.
Why Arm Belongs in Your Architecture Standards
Even allowing for marketing optimism, the case for evaluating Arm is strong for several reasons:
- Cost: Arm instances are typically priced below comparable x86 instances, and if performance is equal or better, cost per unit of work falls.
- Efficiency and sustainability: providers emphasize performance per watt, which matters for organizations tracking cloud emissions.
- Ecosystem maturity: mainstream Linux distributions, container runtimes, language runtimes and many managed services support Arm, and new instance generations typically launch with major distributions available.
- Managed services: providers increasingly run managed databases and caches on their own Arm chips, so you may already be benefiting without noticing.
- Negotiating flexibility: supporting both architectures gives you more options when capacity is constrained or pricing changes.
Which Workloads Are Good Candidates
Workloads differ greatly in how easily they move to Arm. A simple classification helps prioritize.
Strong candidates
- Containerized microservices written in interpreted or JIT-compiled languages such as Java, Python, Node.js, Go, .NET and Ruby, where the runtime handles architecture differences.
- Web servers, reverse proxies and API gateways.
- Open-source databases and caches such as PostgreSQL, MySQL, Redis-compatible stores and search engines, where Arm builds are well established.
- Data processing frameworks such as Spark, especially in managed services that already support Arm nodes.
- CI/CD build agents for projects that already produce multi-architecture images.
Candidates that need more work
- Applications with native dependencies or compiled extensions that lack Arm builds.
- Workloads using vendor agents (security, monitoring, backup) that may not support Arm on every platform.
- CPU-based machine learning inference that relies on specific instruction set optimizations; performance should be benchmarked carefully.
Poor candidates, at least for now
- Commercial software that is licensed or certified only for x86.
- Windows workloads that depend on x86-only components.
- Legacy applications without source code or with binary dependencies that cannot be rebuilt.
Decision Criteria
For each candidate workload, assess the following criteria and record the outcome in an architecture decision record.
- Compatibility: are all dependencies, base images, agents and libraries available for Arm64? Inventory them automatically where possible by scanning container images and package manifests.
- Performance: does the workload meet its latency and throughput targets on Arm in a realistic test? Use your own load profiles, not synthetic benchmarks alone.
- Cost per unit of work: compare cost per request, transaction or job at target utilization, including any change in instance count.
- Operational impact: can your build pipelines produce multi-architecture artifacts, and can your observability and security tooling run on Arm?
- Commitments: how do existing Savings Plans, reservations or committed use discounts apply? Some commitments are flexible across instance families; others are not.
- Portability: do you want to keep x86 as a fallback for capacity or multicloud reasons? Multi-architecture images make this straightforward.
- Regional availability: is the newest generation available in the regions you need, and for preview offerings, what is the expected path to general availability?
How to model cost per unit of work
The most common mistake in Arm business cases is comparing hourly instance prices alone. A fair comparison starts from a unit of work that matters to the business, such as a thousand API requests, a processed order or a completed batch job. Run the same load test on both architectures, find the instance count and size needed to meet your latency targets at your planned utilization, and then calculate the hourly cost of that fleet divided by the units it processes. Include changes in licensing, support and any commitment discounts you would gain or lose. A workload that needs fewer instances on Arm can save more than the price difference suggests, while a workload that needs more instances may save nothing at all.
Arm and AI Workloads
Providers are increasingly positioning their Arm processors as part of AI infrastructure. Microsoft described Cobalt 200 as optimized for agentic AI workloads, and AWS highlighted machine learning inference gains for Graviton5 and noted large-scale deployments for agentic AI. The practical interpretation for architects is that much of an AI application does not run on accelerators. Agent orchestration, tool calls, retrieval pipelines, vector search, API layers, data preparation and smaller-model CPU inference all consume general-purpose compute. These components often look like ordinary microservices and data services, which makes them strong Arm candidates. Large-model training and high-throughput inference will remain on GPUs or other accelerators, but the surrounding services can benefit from the same cost and efficiency arguments as any other cloud-native workload.
A Step-by-Step Migration Approach
Step 1: Make builds multi-architecture
The single most valuable step is to build every container image for both amd64 and arm64. Modern build tools support multi-platform images, and once your registry holds both, deployment becomes a scheduling decision rather than a code change. Native compilation on Arm build agents is usually faster than emulation.
Step 2: Inventory and fix dependencies
Scan images and manifests for architecture-specific binaries. Update base images to multi-architecture versions, replace or upgrade libraries without Arm support and confirm that every agent in your environment supports Arm.
Step 3: Benchmark representative workloads
Choose a few services that represent your common patterns, such as a Java API, a Python worker and a database, and test them on Arm and x86 with production-like load. Measure latency percentiles, throughput, CPU utilization and cost per unit of work. Results can differ from vendor claims in either direction.
Step 4: Roll out gradually
In Kubernetes, add Arm node pools and use node affinity or provider-specific features to shift a share of pods to Arm. Monitor error rates and latency, then increase the share. For virtual machine workloads, use blue-green or canary deployments with an easy rollback path.
Step 5: Update standards and commitments
Once a workload class has proven itself on Arm, make Arm the default in your golden paths and adjust commitment purchases accordingly. Keep x86 available for exceptions.
A Hypothetical Example
Consider a hypothetical software-as-a-service company running about 200 microservices on Kubernetes across two clouds, mostly in Java and Go, with PostgreSQL and a Redis-compatible cache as managed services. Its FinOps team wants to reduce compute cost without a large engineering program.
The platform team first updates the CI pipeline to build multi-architecture images, which surfaces a handful of services with native dependencies and one security agent version without Arm support. After those are fixed, the team benchmarks three representative services on Arm node pools in each cloud. Two services show lower cost per request at the same latency; one memory-intensive service performs similarly but costs about the same, so it is deprioritized. The team then shifts stateless services to Arm in stages over two months, moves the managed database and cache to Arm-based tiers where the provider offers them, and updates its golden path so new services default to Arm. Commitments are adjusted at the next renewal. The documented decision records note which services remain on x86 and why.
Pitfalls to Avoid
- Trusting headline benchmarks. Vendor figures are measured under specific conditions. Test your own workloads.
- Forgetting agents and sidecars. A single unsupported agent can block a whole node pool.
- Locking commitments too early. Align commitment purchases with your migration plan to avoid paying for unused x86 capacity.
- Relying on emulation. Emulated builds and runtimes are slow and can hide incompatibilities.
- Planning production on preview offerings. Preview services may have limited regions and support; plan around general availability.
- Ignoring licensing. Some commercial software is priced or certified differently on Arm.
Governance: Making Arm a Managed Choice
Arm adoption works best when it is treated as a platform decision rather than a series of one-off team experiments. A few governance mechanisms keep it orderly:
- A default architecture per workload class, published in your golden paths, so teams do not have to research the choice themselves.
- An exception process that records why a workload stays on x86, such as a licensing restriction or a missing agent, with a review date.
- Pipeline checks that fail builds which produce single-architecture images for services expected to support both.
- FinOps reporting that shows the share of compute running on Arm and the cost per unit of work by architecture, so the benefits remain visible.
These mechanisms are light, but they prevent the common pattern in which an early Arm pilot succeeds and then stalls because nobody owns the broader rollout.
Outlook
The trend points toward Arm becoming a default rather than an alternative for many cloud-native workloads. Each provider now treats its own Arm silicon as a strategic platform, with managed services increasingly built on it. Between 2027 and 2030, expect more managed services to run on provider Arm chips by default, broader support from commercial software vendors and deeper integration of Arm into AI serving infrastructure, where CPUs handle orchestration, data preparation and agent workloads alongside accelerators. Organizations that adopt multi-architecture builds now will be able to take advantage of each new generation with minimal effort.
Conclusion
The 2026 generation of Arm processors from AWS, Microsoft and Google makes a compelling case for revisiting your compute standards. The decision does not need to be all or nothing: start with multi-architecture builds, test representative workloads against your own metrics, move the strong candidates and keep x86 for the exceptions. Treat vendor claims as hypotheses, record your decisions and fold the results into your golden paths and commitments. Done that way, Arm adoption becomes a steady, low-risk source of cost and efficiency improvement rather than a disruptive migration project.
How Hanoi Technology Can Help
Hanoi Technology helps teams assess workloads for Arm, set up multi-architecture build pipelines and roll out Arm node pools safely, through projects, dedicated teams or managed services.