Google Cloud spent October 7, 2026 telling Wall Street something it has wanted to hear for a decade: you can finally run high-frequency trading inside a public cloud and keep the latency, timing precision, and determinism that colocation cages have guarded for years. The announcement, made at Google Cloud Next ’26, introduced the Ultra Low Latency (ULL) Solution alongside a new U4 machine family built specifically for exchange operators and the trading firms that plug into them. Both went generally available the same day, though “generally available” comes with an asterisk: access is gated behind an allowlist, and most of the people reading about it this week still cannot sign up.
That gate is the story as much as the hardware is. Google built a product aimed at a tiny, extraordinarily demanding slice of the cloud market, one measured in nanoseconds rather than milliseconds, and it did so in partnership with CME Group, the derivatives exchange operator that is migrating listed markets onto Google’s infrastructure. For a company that has spent years trailing AWS and Azure in enterprise cloud share, landing a workload this specialized is as much a credibility play as a revenue one.
What Google Cloud Just Announced
According to Google Cloud’s own announcement, the ULL Solution and the U4 machine family both reached general availability on October 7, 2026. The company describes U4 as “network-optimized” hardware purpose-built so that exchange matching engines and the firms trading against them can run inside Google Cloud rather than in a privately leased data center near an exchange floor.
Google frames the launch around three audiences: exchange operators who run the matching engine itself, exchange participants who send and receive order flow, and service providers who build tools on top of both. Each gets a different slice of the U4 family, and Google has structured eligibility so operators and participants get dedicated bare-metal machines while everyone else is pointed toward a more flexible virtual-machine tier.
Documentation tied to the launch kept updating through mid-October, with Google’s release notes showing changes as recent as October 14 and 16, 2026, including expanded Hyperdisk Throughput support for the virtual-machine tier. That cadence suggests Google is still actively shaping the product even after calling it generally available, a pattern common with allowlisted, early-access infrastructure.
Inside the U4 Machine Family: U4P, U4C, and U4S
Google split U4 into three distinct products rather than one configurable instance type, and the split maps directly onto who is allowed to buy what. U4P and U4C are bare-metal machines, meaning the customer gets direct access to physical hardware with no hypervisor sitting between the application and the silicon. U4P is reserved for exchange operators running the actual matching engine; U4C is reserved for exchange participants, the trading firms and brokers sending orders into that engine.
Both bare-metal variants run on Intel’s 5th Gen Xeon Scalable processors, code-named Emerald Rapids, with 120 physical cores and either 512 GB or 768 GB of memory depending on configuration. The defining feature isn’t the core count, though: it’s the networking. Each U4P and U4C machine ships with three physical network interface cards, one standard NIC for management traffic and two dedicated ULL NICs for trading traffic, a separation Google says keeps latency-sensitive packets away from anything that could introduce jitter.
The third tier, U4S, is a virtual machine rather than bare metal, built on newer Intel 6th Gen Xeon Scalable (“Granite Rapids”) silicon and scaling from 2 to 288 vCPUs with up to 2,232 GB of memory. U4S supports multiple virtual NICs with networking specified up to 200 Gbps, and Google positions it for operators, participants, and service providers who need elastic capacity for workloads adjacent to the trading path rather than the matching engine itself.
U4 Machine Family Specs at a Glance
The table below pulls together the specifications Google has published across its U4 documentation and launch materials.
| Spec | U4P | U4C | U4S |
|---|---|---|---|
| Deployment type | Bare metal | Bare metal | Virtual machine |
| Intended user | Exchange operators | Exchange participants | Operators, participants, service providers |
| CPU | Intel 5th Gen Xeon Scalable (Emerald Rapids) | Intel 5th Gen Xeon Scalable (Emerald Rapids) | Intel 6th Gen Xeon Scalable (Granite Rapids) |
| Cores / vCPUs | 120 physical cores | 120 physical cores | 2 to 288 vCPUs |
| Memory | 512 GB or 768 GB | 512 GB or 768 GB | Up to 2,232 GB |
| Networking | 3 physical NICs (1 standard, 2 ULL) | 3 physical NICs (1 standard, 2 ULL) | Multi-vNIC, up to 200 Gbps |
| Local storage | 12 TiB Titanium SSD | 12 TiB Titanium SSD | 18 TiB Titanium SSD |
| Hyperdisk support | Yes | Yes | Yes, including Hyperdisk Throughput |
Google has not published a fourth, cheaper tier, which underlines the point that U4 is not meant to compete with general-purpose compute. Every configuration assumes the customer already knows exactly how many nanoseconds of jitter their strategy can tolerate.
The Ultra-Low-Latency Networking Stack
The compute specs matter less here than the network underneath them. Google built dedicated ULL VPC networks that carry both unicast traffic, the normal point-to-point packets most cloud networking relies on, and multicast traffic, which is how exchanges distribute market data to many recipients simultaneously without sending a separate copy to each one. Google’s own release documentation says the ULL VPC networking layer targets specific latency, jitter, and multicast-variance thresholds, rather than offering the best-effort networking typical of standard Compute Engine instances.
That multicast support is a meaningful technical commitment. Conventional cloud virtual networks route multicast traffic awkwardly, if at all, because virtualized switching layers were never designed around trading-floor data distribution patterns. Google says U4’s physical NIC separation and hardware-level multicast handling let market data move through the network without passing through a standard virtual switch, which is typically where latency and jitter creep in.
Google also ships public RHEL and Rocky Linux images configured specifically for the ULL environment, so customers aren’t left tuning a generic Linux kernel for a use case where microseconds of scheduler jitter can matter.
Sub-10-Nanosecond Timestamps and Hardware Multicast
Timing precision is the other pillar of the pitch. Reporting on the launch describes network-level timestamping below 10 nanoseconds, a figure that matters enormously to regulators and exchanges alike, since trade sequencing and best-execution rules often hinge on provable order of events down to fractions of a microsecond. Without precise, trustworthy timestamps, a cloud-hosted matching engine would struggle to meet the audit standards exchanges already operate under in physical data centers.
Hardware multicast and nanosecond-level timestamping are the two features that most clearly distinguish U4 from an ordinary high-performance VM. Plenty of cloud instances offer fast CPUs and generous memory; almost none offer a network stack engineered around the specific failure modes of trading infrastructure, where a single out-of-order packet or late timestamp can translate into a compliance incident, not just a slow page load.
Access, Regions, and Pricing: What We Actually Know
Despite the general-availability label, Google’s own release notes are blunt about who can actually use this: “GA with allowlist,” restricted to approved exchange operators and their exchange participants, with access requests routed through a dedicated email address rather than the normal Google Cloud console sign-up flow. That is a sharp departure from how Google typically ships new machine types, and it signals that U4 is closer to a managed partnership program than a self-service product, at least for now.
Geographically, U4 documentation currently lists us-south1 and its zones, us-south1-d and us-south1-e, as the initial footprint. Google’s announcement describes the broader offering as living in “select private Google Cloud regions” rather than the standard public-region map customers see for Compute Engine generally, which fits a product built around proximity to specific exchange infrastructure rather than broad geographic coverage.
On price, Google has disclosed nothing. No hourly bare-metal rate, no reserved-capacity figure, no network egress schedule has appeared in any public document tied to the launch. Given the allowlist model, it is plausible that commercial terms are negotiated per exchange relationship rather than published as a standard price sheet, which would track with how colocation deals have traditionally worked between exchanges and their biggest trading partners.
CME Group: Google’s First Named Trading Partner
The only financial institution Google names in connection with the launch is CME Group, the Chicago-based operator of futures and options markets. Google’s announcement describes an ongoing collaboration under which CME Group is migrating listed derivatives markets onto Google Cloud infrastructure, a relationship that predates the U4 launch and gives the new machine family an immediate, credible anchor tenant rather than a purely theoretical use case.
No other exchange, bank, hedge fund, or market-data vendor is named in the available documentation. The allowlist structure means Google could already be onboarding additional partners quietly, but nothing in the public record confirms that yet. For a launch this technically significant, the short partner list is worth noting: Google is proving the model with one of the most demanding customers available before opening the door wider.
How This Compares to AWS and Azure
Neither AWS nor Microsoft Azure has announced a directly comparable product, an allowlisted, bare-metal machine family built specifically around exchange multicast, sub-10-nanosecond timestamping, and dedicated ULL networking for trading workloads. That does not mean either company is absent from financial services infrastructure; both have long-standing enterprise relationships with banks and exchanges. But as of this launch, Google is the only hyperscaler publicly marketing a named product this specialized for exchange-grade, latency-deterministic trading.
That gap matters strategically. High-frequency trading infrastructure has historically lived in colocation facilities physically adjacent to an exchange’s matching engine, not in general-purpose public cloud regions, precisely because virtualization overhead and shared-tenant networking introduce exactly the kind of jitter that trading firms spend enormous sums trying to eliminate. By building bare-metal machines with physically separated NICs and hardware multicast, Google is trying to close that gap rather than compete on general compute price, which is the battlefield AWS and Azure have mostly fought on until now.
Whether AWS or Azure respond with their own exchange-grade offering, or instead lean further into their existing financial-services partnerships, is an open question. What’s clear is that Google has staked out a technical position its two largest rivals have not yet matched in public documentation.
Maintenance Windows and What They Reveal
One of the more revealing details sits in Google’s own maintenance documentation for ULL private zones, and it underscores just how different U4P and U4C are from ordinary cloud instances. Where most Compute Engine VMs live-migrate transparently during planned maintenance, U4P and U4C bare-metal machines simply terminate.
| Machine type | Advance notice | Maintenance action | Additional notice | Live migration |
|---|---|---|---|---|
| U4P | 14 days | Terminate | 14 days | No |
| U4C | 14 days | Terminate | 14 days | No |
| U4S | 28 days | Live migrate | 7 days | Yes |
That split tells a technical story on its own. Live migration, the process of moving a running virtual machine to different physical hardware without the customer noticing, is simply incompatible with bare-metal access and the kind of NIC-level determinism U4P and U4C are built to deliver. Google chose to terminate rather than migrate, accepting a scheduled outage over the latency variance that live migration would otherwise introduce. For a VM-based tier like U4S, where elasticity matters more than nanosecond determinism, live migration remains available with a longer notice window.
Exchange operators and participants evaluating U4P and U4C will need to build their own failover and redundancy plans around that 14-day termination cycle, since Google is explicitly not promising to keep a matching engine running transparently through its own infrastructure maintenance.
The Historical Context: From Colocation Cages to Cloud Racks
High-frequency trading has spent roughly two decades building physical infrastructure specifically to shave nanoseconds off order execution: colocation cages built meters from an exchange’s matching engine, custom fiber runs measured and cut to equal lengths so no participant gets a timing advantage, and specialized network hardware that bypasses standard switching layers entirely. That infrastructure exists because the economics of trading reward speed in a way almost no other industry does, and because public cloud networking, built for elastic, multi-tenant web and data workloads, was never designed to meet those demands.
Google’s ULL Solution is effectively an attempt to rebuild those colocation guarantees, physical NIC separation, hardware multicast, deterministic timing, inside a cloud operating model. It is also part of a broader pattern of Google Cloud courting financial services customers over the past two years, pairing infrastructure announcements with enterprise deals aimed at banks and exchanges that have traditionally been among the most conservative, latency-sensitive, and compliance-bound cloud customers in any industry.
The CME Group relationship fits that pattern directly: migrating listed derivatives markets off privately operated infrastructure and onto a public cloud provider is not a decision exchanges make quickly, given the regulatory scrutiny applied to market infrastructure. That Google secured this relationship before opening U4 more broadly suggests the company understood it needed a marquee reference customer before asking other exchanges to follow.
Market Impact: Google’s Financial-Services Cloud Bet
Google Cloud remains the smallest of the three major hyperscalers by overall market share, which makes specialized, high-value verticals like exchange infrastructure strategically important in a way they might not be for a company with a larger base of general-purpose workloads to fall back on. Winning CME Group’s listed derivatives business, and building a named product category around it, gives Google a reference case it can point to when courting other exchanges, clearinghouses, and trading firms that have historically kept this kind of infrastructure entirely in-house or in dedicated colocation facilities.
There is also a defensive angle. If exchange infrastructure migrates to public cloud at all over the next several years, whichever provider establishes the first credible technical foothold, with named hardware, documented networking guarantees, and a live exchange partner, has a real advantage in capturing the rest of that migration. Google appears to be betting that being first with a purpose-built, publicly documented offering matters more right now than matching AWS or Azure on price or general-purpose scale.
The allowlist model also limits how quickly that bet can pay off. Because U4 isn’t self-service, Google can’t simply let demand scale the way it would with a standard Compute Engine instance type. Growth depends on Google actively qualifying and onboarding each exchange relationship, a slower, more hands-on process than typical hyperscaler product launches.
What the Experts Are Saying
Google Cloud’s own framing of the launch leans heavily on positioning U4 as infrastructure built for a narrow, uncompromising set of customers rather than a general-purpose product. In Google’s official announcement, Disha Chopra, a Product Manager at Google Cloud, said: “We developed the U4 machine family to enable the world’s most technically demanding markets to run within Google Cloud and benefit from cloud services and scale.”
That framing, cloud elasticity applied to a market segment that has historically rejected shared infrastructure on principle, is the clearest articulation of Google’s bet: that exchanges and trading firms will trade some of the control they’ve kept through colocation for the operational flexibility a hyperscaler can offer, as long as the latency and determinism guarantees hold up. A Google Cloud executive separately confirmed the launch publicly at Google Cloud Next ’26, describing the ULL Solution as a showcase of innovation spanning every layer of Google’s cloud infrastructure, from the networking fabric up through the compute layer.
What Happens Next: Five Predictions
- AWS and Azure will respond within 12 to 18 months. Neither hyperscaler can afford to cede exchange-grade trading infrastructure to Google without at least a competing pilot program, even if it starts with a single partner exchange.
- More exchanges will quietly join the allowlist before Google advertises them. Expect Google to confirm new named partners gradually, mirroring how it introduced CME Group ahead of the broader U4 launch.
- Pricing will stay opaque for the foreseeable future. As long as access runs through a manual allowlist and direct email requests, Google has little incentive to publish a standard rate card.
- Additional regions will open only as exchange demand justifies them. Given the
us-south1-only footprint today, expect Google to expand one region at a time, tied to specific exchange relationships rather than broad geographic coverage. - Market-data vendors will build new products around Google’s multicast layer. Hardware-level multicast distribution is exactly the kind of primitive that third-party data and analytics vendors tend to build on top of once a hyperscaler exposes it.
Checking U4 Availability: A Quick Example
For engineers already working with Google Cloud who want to see how U4 machine types surface in standard tooling once access is granted, the lookup follows the same pattern as any other Compute Engine machine type:
gcloud compute machine-types describe u4p-standard \
--zone=us-south1-d \
--project=YOUR_PROJECT_IDUntil an organization is approved through Google’s exchange allowlist, that call, and any attempt to provision a U4 instance, will simply fail with a permissions error, regardless of billing status or quota. That restriction is itself a useful signal: unlike nearly every other Compute Engine machine type, U4 access is gated by relationship, not by budget.
Frequently Asked Questions
What is Google Cloud’s Ultra Low Latency Solution?
It’s a combination of specialized compute, the U4 machine family, and dedicated networking that Google Cloud announced on October 7, 2026, designed to let exchange operators and trading firms run high-frequency trading workloads inside Google Cloud instead of in private colocation facilities.
What are U4P, U4C, and U4S?
U4P and U4C are bare-metal machines built on Intel 5th Gen Xeon Scalable processors with 120 physical cores, reserved for exchange operators and exchange participants respectively. U4S is a virtual machine tier on newer Intel 6th Gen Xeon Scalable silicon, scaling from 2 to 288 vCPUs, for operators, participants, and service providers who need more elastic capacity.
Can any Google Cloud customer sign up for U4 today?
No. Access is restricted to an allowlist of approved exchange operators and their exchange participants. Approved participants must contact Google directly to request access rather than provisioning instances through the standard console.
Which exchange is using the Ultra Low Latency Solution?
CME Group is the only named partner so far. Google says it is migrating listed derivatives markets onto Google Cloud as part of an ongoing collaboration.
How fast is Google Cloud’s U4 networking?
Google and independent reporting describe network-level timestamping below 10 nanoseconds and hardware-level multicast for market-data distribution, alongside dedicated ULL VPC networking with specific latency, jitter, and multicast-variance targets. Google has not published an end-to-end order-to-wire latency figure.
Where is U4 available?
Only in the us-south1 region, specifically the us-south1-d and us-south1-e zones, as of October 2026. Google describes the broader offering as living in select private regions rather than its standard public footprint.
How much does U4 cost?
Google has not published pricing for any U4 machine type. Given the allowlist access model, commercial terms are likely negotiated directly between Google and each approved exchange or participant.
Do AWS or Azure offer a comparable product?
Not as a named, publicly documented offering. As of this launch, Google is the only major hyperscaler marketing a bare-metal machine family built specifically around exchange-grade multicast networking and sub-10-nanosecond timestamping for trading workloads.