Azure Cobalt 200: what the 50% claim actually measures, and the 3 numbers that decide an Arm migration

Summary. Microsoft announced the early access preview of Azure Cobalt 200 Arm-based virtual machines at Build 2026 on 2 June 2026, with a headline of up to 50% better CPU performance. That figure is measured against Cobalt 100, Microsoft's own first-generation Arm chip, not against x86 and not against a competitor. Google's Axion-based N4A, generally available since 27 January 2026, publishes up to 2x better price-performance measured against comparable current-generation x86 VMs. AWS publishes Graviton4 gains against Graviton3. Three vendors, three baselines, zero comparability. The specifications are comparable and the marketing percentages are not: Cobalt 200 runs Arm Neoverse V3 cores on TSMC's 3nm N3P process with up to 128 vCPUs, 3 MB of L2 cache per core and 192 MB of system-level L3, while Graviton4 ships 96 Neoverse V2 cores and Google's N4A uses Neoverse N3 with up to 64 vCPUs and 512 GB of memory. Only one of the three is generally available on its newest silicon. Cobalt 200 is still preview-only, in 8 regions, with general availability described by Microsoft's own Azure Databases team as "later this year".

If you are being asked whether to move workloads to Arm this quarter, the vendor percentages are the least useful input you have.

What Microsoft actually announced on 2 June 2026

The Cobalt 200 SoC is Microsoft's second-generation Arm processor, built on Arm Neoverse V3 Compute Subsystems and fabricated on TSMC's 3nm N3P process, with a chiplet architecture, custom accelerators and a custom memory controller. Memory encryption is enabled by default through that memory controller.

Against Cobalt 100, Microsoft publishes these generational gains: up to 50% better CPU performance, 20% higher remote storage IOPS with NVMe, 10% better remote storage throughput with NVMe, and 15% higher network bandwidth. On production-shaped workloads Microsoft reports up to 135% better performance for cloud database workloads, 80% for caching, 45% for communication encryption and 40% for web serving.

Every one of those numbers has the same denominator: Cobalt 100.

That matters because Cobalt 100 is itself a strong baseline. Microsoft states that its own services running on Cobalt 100 saw up to 45% better performance while using 35% fewer compute cores than the previous compute platform, and that Microsoft Defender for Endpoint gained 40% in its cyber data curator. Cobalt 100 is deployed across 32 Azure datacenter regions with Databricks and Snowflake among the adopters. A 50% gain on top of that is a real improvement. It is simply not the number you compare against an AWS or Google figure.

The VM families, which are the part that actually constrains you

Two families are new relative to Cobalt 100, which offered only General Purpose (Dp, Dpl) and Memory Optimized (Ep). The high-memory Mpsv4 at 16:1 and the storage-dense Lpsv5 at up to 23 TB of local NVMe are the additions that open workloads Cobalt 100 could not host at all. All series deliver up to 85 Gbps of network bandwidth and 70 Gbps of remote storage throughput, except Mpsv4 and Mpdsv4, which provide up to 70 Gbps and 46 Gbps respectively.

Preview availability covers West US 3, East US 2, Central US, Sweden Central, East US, West US 2, Spain Central and Indonesia Central. No Indian region is in the preview list, which is the single most important line in this article for teams running in Central India or South India.

The baseline problem, stated plainly

Here is the same class of claim from three vendors, with the baseline each one used.

Read the table twice. Microsoft and AWS both benchmark against their own previous Arm generation. Google benchmarks against x86. A reader who lines up "50%" against "2x" against "40%" is comparing a generational delta, a cross-architecture delta and another generational delta as though they were the same measurement.

Google is at least explicit about method. The footnote under its N4A performance chart reads: "As of October 2025. Performance based on the estimated SPECrate2017_int_base, estimated SPECjbb2015, MySQL Transactions/minute (RO), and Google internal Nginx Reverse Proxy benchmark scores run in production on comparable latest-generation generally-available VMs with general purpose storage types. Price-performance claims based on published and upcoming list prices for Google Cloud." That is a disclosable methodology, including the admission that pricing inputs are partly unpublished.

Third-party roundups have been circulating head-to-head SPECrate figures putting Cobalt 200 against specific AWS Graviton generations. Those numbers do not appear in Microsoft's announcement, and Microsoft published no cross-vendor benchmark with it. Treat any Cobalt-versus-Graviton score you see as unattributed until a vendor or an independent lab publishes the run.

Silicon specifications, which are comparable

Where the marketing percentages fail, the datasheets hold up.

The V-series versus N-series distinction is the one worth understanding. Arm's V-series cores target peak per-core performance; the N-series targets throughput per watt and density. Microsoft chose Neoverse V3, AWS chose V2 for Graviton4, and Google chose N3 for N4A while positioning C4A as its consistent-high-performance line. Google is not losing a specification race here, it is aiming N4A at a different point: its own material puts N4A at up to 80% better performance-per-watt than comparable x86 and positions C4A, with up to 100 Gbps networking and Titanium Local SSD, for latency-sensitive work.

Microsoft's per-core argument is explicit: each Cobalt 200 core is a full physical core with 3 MB of dedicated L2, which Microsoft ties to packing more agent sandboxes per VM while holding latency. If your workload is many isolated tenants per host, that cache-per-core figure is a more meaningful input than any percentage in this article.

What the customer quotes do and do not tell you

Vendor launch posts carry named quotes, and they are more useful than the headline numbers because they usually name a workload.

Microsoft's own Dataverse team is quoted by Mauktik Gandhi, VP Engineering, Agent 365 Platform: "We deployed the Power Apps platform on Cobalt 100 for its improved performance and power efficiency. We are validating Cobalt 200 now and excited by the performance gains we are seeing, up to 60% better performance for our base workload over Cobalt 100." Note the framing. This is a first-party team, still validating, against Cobalt 100.

Google's post quotes an external customer with a cross-architecture number instead. Sergei Koren, Chief Infrastructure Architect at ZoomInfo: "In our preview of the new N4A instances, we measured a 60% improvement in price-performance for these key workloads compared to their x86-based counterparts." Joe Peled, Sr. Director of Hosting and Delivery Ops at Vimeo, reports "a 30% improvement in performance for our core transcoding workload compared to comparable x86 VMs."

Two 60% figures, entirely different meanings. One is Microsoft's internal platform against Microsoft's previous Arm chip. The other is a customer's production pipeline against x86. Neither tells you what your workload will do.

On the Cobalt 200 side, the external partner quotes are notably hedged. Brandon Mincey, Engineering Fellow at Teradata, says "early testing has been encouraging". Yuvraj Gupta, Director of Product Management at Elastic, says initial testing "shows promise for further improvements". That is preview language, and it is accurate: Shireesh Thota, Corporate Vice President for Azure Databases, refers to "broader availability later this year".

The three numbers that should decide your migration

Ignore the vendor percentage. Measure these instead.

One: your rebuild and validation cost, in engineer-days. Arm compatibility is no longer the blocker it was. C++, .NET, Java, Python and Rust all ship Arm-native builds; GitHub Actions supports Arm through both self-hosted and GitHub-hosted runners; Azure Kubernetes Service supports Arm agent nodes and mixed x86 and Arm clusters. Microsoft states Cobalt 200 VMs deliver full compatibility with workloads already running on Cobalt 100, so an existing Arm estate migrates cheaply. A pure x86 estate does not. The cost lands in container images, native dependencies, agents and anything that ships a compiled binary you do not control.

Two: your price-performance on your own workload, at your own committed rate. Every published price-performance number is against list price. If you hold commitments, your effective x86 rate is already discounted and the Arm advantage shrinks by exactly that discount. Run the comparison at your rate, not the list rate. Commitment scope changes can move that baseline on their own, as we covered in our breakdown of the June 2026 Google Cloud CUD sharing default change.

Three: regional availability on the date you actually need it. This is where Cobalt 200 currently loses on the sub-continent. The preview covers eight regions and none of them is in India. Graviton4 and Axion are generally available; Cobalt 200 is not. A migration plan that depends on preview capacity in a region you do not operate in is not a plan.

A practical sequencing: move a stateless, horizontally scaled service first, on whichever Arm platform is already GA in your region, and measure cost per request rather than cost per vCPU-hour. The real cost is usually the migration, not the compute.

India-specific considerations

Cobalt 200's preview region list excludes India entirely, which settles the question for Azure-resident Indian workloads in the short term: you evaluate, you do not migrate. Google's N4A GA region list is also worth reading closely, since it covers us-central1, us-east4, us-east1, us-west1, asia-southeast1, europe-west1, europe-west2, europe-west3 and europe-west4. The nearest N4A region to India in that list is Singapore, not Mumbai or Delhi.

For Indian teams the practical consequence is that Arm migration in 2026 is mostly an AWS conversation, because Graviton has the longest-standing regional footprint of the three, or a cross-region conversation you probably do not want given data residency expectations under the Digital Personal Data Protection Act 2023. Routing production traffic to Singapore to chase a compute discount is a data governance decision wearing a FinOps costume.

Where Indian teams can act now is preparation: get container images building multi-architecture, remove x86-only dependencies, and get CI producing Arm artifacts. That work is portable across all three vendors and it is the part that takes months. Teams running Kubernetes can stage this through mixed-architecture node pools, an approach we go into in our guide to managed Kubernetes and AI platform operations, and the broader cost framing sits alongside our FinOps guidance for Indian teams on AWS, Azure and GCP and our look at Azure Copilot and Graviton4 in agentic FinOps tooling.

What to do this quarter

Request Cobalt 200 early access if you already run Cobalt 100, because your migration cost is close to zero and the generational numbers are the ones that apply to you. If you are on x86 and in an Indian region, do the multi-architecture build work now and re-evaluate when Cobalt 200 reaches general availability and an Indian region, neither of which Microsoft has dated beyond "later this year". In all cases, benchmark your own workload at your own committed rate, because none of the three vendors published a number that answers your question.

FAQ

How eCorpIT can help

eCorpIT runs Arm migration assessments that start with your build pipeline rather than a vendor benchmark: multi-architecture container images, dependency audits, and a measured cost-per-request comparison at your actual committed rates. We plan staged migrations through mixed-architecture Kubernetes node pools so nothing moves before it is proven, and we design data placement aligned with Digital Personal Data Protection Act 2023 expectations when regional availability pushes workloads across borders. To scope an assessment against your estate, talk to our cloud infrastructure team.

References

1. New Azure Cobalt 200 VMs deliver 50% performance improvement, fully optimized for modern agentic AI workloads — Microsoft Azure Blog, 2 June 2026, preview announcement, generational figures, VM families, regions and customer quotations.

1. Announcing Cobalt 200: Azure's next cloud-native CPU — Microsoft Community Hub, Cobalt 200 silicon architecture.

1. Unlock 2x better price-performance with Axion-based N4A VMs, now generally available — Google Cloud Blog, 28 January 2026, N4A specifications, benchmark methodology footnote, regions and customer quotations.

1. Try C4A, the first Google Axion Processor — Google Cloud Blog, C4A launch, October 2024.

1. Arm VMs on Compute Engine — Google Cloud documentation, Arm machine series on Compute Engine.

1. Join the preview for new memory-optimized AWS Graviton4-powered Amazon EC2 instances (R8g) — AWS News Blog, Graviton4 and R8g instance family.

1. AWS Graviton4-based Amazon EC2 R8g instances: best price performance in Amazon EC2 — AWS Blog, Graviton4 performance figures against Graviton3.

1. Performance gains with AWS Graviton4: a DevitoPRO case study — AWS HPC Blog, Graviton4 workload results.

1. AWS Graviton4 benchmarks — Phoronix, independent Graviton4 testing and core configuration.

1. Benchmarks of Google's Axion Arm-based CPU — Phoronix, independent Axion C4A testing and cache configuration.

1. Azure Kubernetes Service — Microsoft, Arm agent node and mixed-architecture cluster support.

1. Dynamic Resource Management — Google Cloud documentation, technology underpinning N4A.

Last updated: 21 July 2026.