Microsoft used the second day of Build 2026 to push two pieces of its custom silicon roadmap from announcement to availability. Azure Cobalt 200, the second generation of its Arm CPU, opened in early access preview across eight regions, and the Maia 200 AI accelerator is now described as in production in Iowa and Arizona. The combination matters for European Azure customers because, for the first time, both a competitive Arm general purpose tier and a Microsoft-designed accelerator are visible on the same roadmap, with concrete dates rather than slideware. The reporting from DataCenterDynamics from the keynote floor gives the cleanest specification rundown so far, and it is worth walking through what is real today versus what is still marketing.
Cobalt 200 lands in Sweden Central and Spain Central with 132 active cores
Cobalt 200 is a meaningful step up from the first generation part Microsoft began shipping in 2024. The new SoC carries 132 active cores, 3MB of L2 cache per core and a 192MB L3 system cache, and supports per-core dynamic voltage and frequency scaling, meaning each core can sit at a different operating point depending on the workload mix on the socket. Microsoft says it evaluated more than 350,000 configuration candidates during the design process, and quotes a 50% generational uplift in aggregate performance. VMs scale up to 128 vCPUs in this preview window. The eight launch regions are West US3, East US2, Central US, Sweden Central, East US, West US2, Spain Central and Indonesia Central, with more regions promised over the rest of the year. For European workloads, Sweden Central and Spain Central are the relevant pins on the map; both have been short of native Arm options inside Azure, which forced cost-sensitive teams onto AWS Graviton or kept them on x86.
What the 135% database number actually represents
Microsoft is leading with two workload-specific figures: a 135% improvement on cloud database workloads and an 80% improvement on caching workloads, both measured against Cobalt 100. Those numbers are not generic SPEC scores. They reflect Microsoft's internal Azure SQL and Azure Cache for Redis test rigs, which sit inside the same fleet that Cobalt 200 is being optimised for. That makes them credible as a directional signal for managed Azure data services, and a much weaker signal for self-managed PostgreSQL or MariaDB running on Cobalt 200 general purpose VMs. The honest read is that Microsoft has tuned the chip and the firmware for its own database business first, and that customers running their own engines should expect a smaller uplift until they tune buffer pool sizes, NUMA pinning and JIT settings for the new core layout. Binary compatibility with Cobalt 100 means no recompile, but it also means no automatic gain on code that was never optimised for the new cache hierarchy.
Maia 200 is in production, but only in two US regions
The Maia 200 announcement is louder than Cobalt 200 and should be read more carefully. The accelerator is built on TSMC 3nm, delivers about 10 petaflops at FP4 and 5 petaflops at FP8 inside a 750W SoC envelope, and carries 216GB of HBM3e at 7Tbps plus 272MB of on-chip SRAM, with a redesigned memory subsystem and dedicated data movement engines. Microsoft explicitly claims Maia 200 offers three times the FP4 performance of Amazon Trainium3 and Google's seventh generation TPU, Ironwood. Vendor benchmarks at that scale almost always shrink under third-party load, so treat the 3x figure as a ceiling, not a planning number. More importantly, production today means Iowa and Arizona only. Italy, Australia and South Korea are queued but not live. For any European inference workload bound by GDPR data residency, Maia 200 is not yet an option in 2026 Q3 planning.
Where Cobalt 200 fits against Graviton4, Axion and Ampere
The competitive context is sharper than it has been in years. AWS Graviton4 has the maturity advantage and a four-year head start on customer recompilation work. Google Cloud's Axion processors are now widely available across European regions, and Oracle continues to lean on Ampere parts for its OCI A1 and A2 shapes. With Cobalt 200, Azure finally has a credible third option in the room. Pricing is the open question: Microsoft has not yet published list pricing for Cobalt 200 VMs, but the historical pattern across AWS and Google is a 20% to 40% discount over equivalent x86 instances. Anything inside that band is enough to justify the recompile, container rebuild and CI matrix expansion that an Arm migration actually costs. A discount below 15% would not move most CFO conversations.
We are booking a Cobalt 200 pilot in Sweden Central by 30 June for the Redis tier
For our portfolio, the migration calculus on Cobalt 200 is straightforward, and the Maia 200 calculus is to wait. Workloads already on Cobalt 100 inherit binary compatibility, so the preview is effectively a free performance refresh once general availability lands. The first concrete pilot is the Redis caching tier in front of the product catalogue: Microsoft's own 80% caching number gives us a defensible expected uplift, and Redis is the lowest risk workload to migrate because state is ephemeral. We are booking a Sweden Central preview pilot by 30 June, with a four-week comparison against the current D-series x86 fleet. Decision threshold is a 25% reduction in cost per million GET operations at p99 latency parity; anything below that and we hold for general availability and renegotiate. The Java estate, .NET 9 services and PostgreSQL flexible server tiers move into the second wave only after the Redis pilot reports.
The 30-day checklist for Arm readiness
The bigger picture is that hyperscaler-designed silicon is no longer a curiosity. Custom CPUs and accelerators now anchor the cost structure of every major cloud, and teams that never bother to switch silicon will gradually pay a premium relative to those who do. Inside the next thirty days, three artefacts should exist for any serious Azure tenant: a service catalogue tagged for Arm readiness against the .NET, Java, Python and Node.js runtimes; a CI matrix that builds and tests arm64 container images for every service shipped to production; and a measured baseline of current x86 cost per request for the top ten services by spend. Without those three, the Cobalt 200 preview is just a press release. With them, the path to a 25% to 30% compute line reduction by Q4 2026 is a sequencing problem, not a research problem. The next checkpoint that matters is Cobalt 200 general availability and pricing, which on Microsoft's usual cadence should land within ninety days of preview; if list pricing comes in below a 25% discount to equivalent Ddsv6 x86 instances, the migration plan stays on the shelf and we revisit at Ignite.
