The Cheap Cloud Chip with the Expensive Exit Route

6 min read

Up to two-thirds better price-performance, less energy per compute operation, and custom hardware without Nvidia markups: AWS, Microsoft, and Google are pushing their self-developed cloud chips with these promises. The advantage is real and measurable. What the bill doesn’t mention is the price of the exit.

Key Takeaways

• The price advantage is real: The hyperscalers’ custom ARM chips deliver significantly better price-performance than classic x86 instances depending on the workload-up to two-thirds in peak cases. The gap is widest for scale-out services.
• It doesn’t apply to everything: Legacy x86 software, HPC workloads with specialized libraries, and ISV products without ARM licenses erase the advantage. The discount comes with strings attached.
• Lock-in just changes shape: Every chip is proprietary. A workload optimized for Graviton won’t run one-to-one on Axion or Cobalt. Switching means rebuilding and retesting from scratch.

Related:Cloud Repatriation: When Bringing Workloads Back In-House Makes Sense  /  800-Volt HVDC in the Data Center

Why the hyperscalers are suddenly building their own chips

Booking a compute instance today is no longer just a choice between providers-it’s a choice between processor architectures that no competitor shares: AWS’s Graviton, Azure’s Cobalt, Google Cloud’s Axion. Three custom ARM designs, three proprietary ecosystems. For cloud architects, this shifts an old question one layer deeper in the stack.

The motivation behind these in-house chips is purely economic. Custom silicon reduces reliance on Intel, AMD, and above all Nvidia, whose margins otherwise land squarely on the cloud bill. It slashes energy per compute operation, and with data centers running at full tilt, energy is now the tighter bottleneck than capital. It also locks customers into instance types that only one vendor offers. Industry estimates put AWS’s custom-chip business at a double-digit billion-euro annual run rate.

Generations are rolling out on an annual cadence. In June AWS launched Graviton5, an ARM processor with 192 cores on TSMC’s 3-nanometer process and, per the vendor, roughly 25 percent faster than its predecessor. For AI training AWS pairs it with Trainium2 as an alternative to Nvidia GPUs, operating dedicated clusters in the six-figure chip range.

Microsoft is pushing Maia 200, a custom AI accelerator with 216 GB of HBM3e memory, and Cobalt 200, an ARM CPU for traditional server loads. Google has brought Axion, its first custom ARM processor, into production in the C4A and N4A instance families. Three vendors, one playbook: own the silicon, own the stack, own the service.

Where the discount is real-and where it topples

The savings aren’t a blanket discount. They materialise only where software is cleanly compiled for ARM and scales horizontally. In web servers, microservices, Java and MySQL workloads, container sidecars and stateless services, ARM wins in almost every benchmark. Google cites up to 50 % more performance and 60 % better energy efficiency for general workloads versus comparable x86 machines. SAP reported tangible performance gains for its HANA database on Graviton.

The flip side rarely appears in the marketing brochures. Specialised HPC libraries, legacy x86 binaries without ARM builds, and commercial ISV software whose licences don’t cover the new architecture can erase the advantage overnight. Running a database engine under an x86-only licence saves on the instance price but inflates support bills.

Between the decision and the savings sits a transition phase that never shows up on any price sheet. Teams migrating operate both architectures in parallel for a while: duplicated test matrices, duplicated base images, duplicated monitoring profiles. That dual maintenance is temporary, yet it pushes the break-even point further out. Teams that plan for it admit the real savings only from the quarter in which the old x86 legacy is finally switched off.

Before any migration, run a workload inventory-not a price list. Which service is stateless and ARM-ready, and which still clings to an undocumented x86 dependency? The business case is decided by that classification, not by the list price per vCPU.

The lock-in that isn’t in the contract

This is the real twist. The lock-in isn’t only in the contract anymore; it’s in the build. The old cloud lock-in was about data egress and managed services. Custom silicon adds a second binding layer, one level deeper in the stack. An image tuned for Graviton will run on Axion or Cobalt, but rarely with the same efficiency. The three ARM designs differ in vector extensions, cache hierarchy and memory topology; compiler flags, optimised libraries and load profiles are calibrated per chip family.

Switching providers means rebuilding, re-measuring and re-tuning. In practice a small team is tied up for weeks, and at the end the same application runs on different silicon-just as before. Those switching costs give the provider the negotiating leverage that the entry discount seemed to surrender.

The cheap chip costs nothing on the way in. It costs on the way out.

ARM in the cloud remains the right choice for large parts of the portfolio. The danger lies only in assuming that cheaper automatically means freer. Taking the discount without factoring in exit costs merely swaps one architecture dependency for another. How that shift plays out on the capacity side is already visible in the parallel rush for GPUs, which is putting entire platform teams under pressure.

How teams lock in savings without tying themselves down

Discipline in the pipeline is the way out. Five steps separate a robust business case from an expensive failure.

1. Pull ARM compatibility into CI early. Multi-architecture builds belong in the pipeline before the first production workload is migrated. Retrofitting later doubles the cost.
2. Classify workloads instead of moving everything at once. Tackle stateless and ARM-ready workloads first; legacy and ISV-bound workloads last or not at all.
3. Factor exit costs into the business case. Don’t just count the monthly savings-include the effort to move a workload later to a different chip or back to x86.
4. Apply FinOps tagging per architecture. Without clean cost allocation per instance type, the real impact stays buried in the catch-all.
5. Keep standard images portable. Write containers and infrastructure as code so switching architectures becomes a configuration choice, not a complete rebuild.

For most teams the math is simple: ARM instances pay off immediately for the scale-out slice of the portfolio, and the savings justify the porting effort. Yet if migration is treated as a one-way street, you surrender the very bargaining power that hyperscaler competition is supposed to give you.

Frequently Asked Questions

What is custom silicon in the cloud?

This refers to processors designed in-house by a cloud provider rather than purchased from Intel, AMD, or Nvidia. Examples include AWS Graviton, Microsoft Cobalt, and Google Axion for CPUs, as well as AWS Trainium and Microsoft Maia for AI accelerators.

Are ARM chips in the cloud always cheaper?

No. The cited price advantage applies only to ARM-compatible workloads such as web servers, microservices, and Java. Legacy x86 software, HPC with specialized libraries, and ISV products without an ARM license can become more expensive because porting or support may offset the discount.

What does switching between Graviton, Axion, and Cobalt cost?

Each chip is proprietary. A workload optimized for one family requires new builds, new tests, and often new performance tuning when switching. The effort is comparable to a small migration project, not a configuration change.

Is custom silicon worthwhile for SMEs?

For modern, containerized services usually yes, because ARM porting is minimal and savings materialize quickly. In established x86 environments, a workload inventory is advisable first to identify which share can migrate without friction.

Will x86 disappear from the cloud?

Not in the short term. ARM is becoming the standard for scale-out loads, while specialized HPC and legacy workloads will continue to favor x86. Most companies will run both architectures in parallel for the foreseeable future.

More from the MBF Media Network

Image source: AI-generated (Juni 2026)