What reached general availability this month
Google Cloud's A5X instances, bare-metal GPU-accelerated machines built on Nvidia's Vera Rubin NVL72 platform, moved from preview to general availability during the first week of November, following an October 21 announcement at Nvidia's GTC Berlin event. The instances are aimed squarely at the agentic workloads enterprises are now trying to run at production scale: long-context reasoning, multi-turn agent sessions, and training runs that need dense GPU clusters rather than a handful of accelerators bolted onto a general-purpose instance. Google's own authors on the announcement, Mark Lohmeyer and Ankur Mehrotra, frame it as co-engineering with Nvidia rather than a simple hardware refresh, which is the right way to read a release this dense with networking and storage changes alongside the chip.
Alongside the GPUs, Google shipped Managed Lustre support for Nvidia's GPUDirect Storage on A5X, which gives the parallel file system a direct path into GPU memory and bypasses the CPU and system memory entirely. It also added extended key-value caching that pushes context memory beyond what fits in GPU high-bandwidth memory, aimed at the long-context and multi-turn agent sessions that burn through memory fastest. Individually these are infrastructure details. Together they describe a stack built specifically for the failure modes enterprise AI teams hit once a pilot moves into real production traffic.
The networking fabric is the actual headline
The GPU announcement gets the attention, but the more consequential piece is Virgo, a new non-blocking network fabric using mesh topology that Google says supports clusters of up to 80,000 Rubin GPUs within a single site and as many as 960,000 across multiple sites. GPU count gets the press release, but interconnect bandwidth is almost always the actual bottleneck once a training or inference cluster scales past a few thousand accelerators. A fabric built to avoid blocking at that scale is a direct response to the networking constraints that have slowed down large training runs across every cloud provider over the past two years.
On the Kubernetes side, Google added GKE Managed DRANET, which exposes network interface cards as native Kubernetes resources, and gave Kueue topology-aware scheduling so workloads get placed with network proximity in mind rather than just raw capacity availability. For platform teams running GPU clusters on GKE, this closes a real operational gap: scheduling decisions that ignore network topology are a common, quiet source of the performance variance that makes AI infrastructure costs hard to predict, and the kind of problem that usually only surfaces after a cluster is already in production and the bill has already arrived.
Confidential computing for GPUs finally catches up
Google also pushed G4 Confidential instances, which pair Nvidia RTX PRO 6000 Blackwell Server Edition GPUs with confidential computing, to general availability, and introduced Confidential Bare Metal on A4X Max using Nvidia GB300 NVL72 with encrypted DDR and NVLink interconnects. This matters more than it sounds, because confidential GPU computing has lagged confidential CPU computing by years. Regulated industries that wanted hardware-isolated, encrypted AI workloads have mostly had to accept that guarantee on CPU-bound tasks while running their actual GPU training and inference in a lower assurance environment.
Closing that gap removes a real architectural compromise. A bank or healthcare provider that previously had to choose between confidential computing guarantees and GPU performance can now get both on the same cloud, running the same sensitive model training job with hardware-level isolation instead of accepting a lower assurance tier as the price of using a GPU at all. We expect this to matter more to regulated-industry CTOs than the raw GPU specifications in the announcement, because it is the difference between keeping a sensitive AI workload on-premises indefinitely and finally having a credible, auditable cloud-native path to move it.
Sovereignty shipped with the compute, not after it
Google bundled sovereign cloud features directly into this release rather than treating them as a separate product track. That includes expanded EMEA data residency support, Google Distributed Cloud air-gapped deployments now running Nvidia HGX B300 systems at general availability, and partner-operated isolated clouds such as S3NS in France and Thales in Germany. Open models including Gemma, Mistral, and Nvidia's Nemotron are available within that sovereign portfolio with customers retaining custody of model weights and runtimes, which addresses a specific European enterprise complaint: that sovereignty and frontier AI performance have been treated as mutually exclusive choices.
WPP's chief technology officer, Stephan Pretorius, offered a customer view of what the combination unlocks, saying the A5X instances let his creative and production teams direct agents that perform frame-accurate quality checks and adapt brand assets at scale. That is a narrow use case, but it illustrates the pattern Google is betting on: enterprises that need both heavy GPU throughput and strict data controls, run in the same environment, rather than split across a cloud region and an on-premises fallback.
What this means for your sourcing strategy
If your organization has GPU capacity split across multiple clouds because no single provider could offer both raw compute and sovereignty guarantees, Google's bundled release is worth testing against your current architecture. The combination of confidential GPU computing, a purpose-built scale-out fabric, and sovereign deployment options in one SKU family is a genuine differentiator right now, not marketing language, and it is worth a proof-of-concept before your next GPU capacity renewal regardless of which cloud you currently favor. Ask specifically whether your workload's compliance requirements map to the Data Boundary option or the fully air-gapped Distributed Cloud option, since the two carry different cost and operational tradeoffs.
The open question is supply. Announcing general availability is not the same as having enough Vera Rubin capacity to meet demand across every region simultaneously, and Google, like every hyperscaler this cycle, has a track record of GA announcements running ahead of actual provisioning speed. Ask for a committed capacity timeline in writing before you plan a migration around this, and treat the announcement as a signal to start evaluation now rather than a guarantee you can get capacity next quarter.
