Picture this: you are a retail business with a rock-solid ERP, looking to introduce an AI agent that updates product prices on your site in real time.
The agent handles the heavy lifting: tracking stock, calculating discounts, and serving up related products. On paper, it sounds like an efficiency dream. In reality, every single customer search fires off dozens of concurrent tasks, bringing your database to its knees and crawling your site to a halt.
The problem isn't your code; it is your underlying architecture. To solve this, Google has unveiled "fluid compute", an intelligent infrastructure designed to dynamically route processing power right where it is needed, seamlessly bridging legacy software with modern AI workflows.
Scalability and efficiency took centre stage at this year’s Google Cloud Next '26 in Las Vegas. Here is a breakdown of the key infrastructure updates that can streamline your performance and trim your cloud bill starting today.
Let’s go back to the retail example for a moment.
The issue is not that the website is poorly built; it is that the underlying servers were designed for an era when tasks arrive sequentially rather than all at once.
Traditional x86 processors manage workload spikes by splitting each physical core into two virtual channels, a technique known as Simultaneous Multithreading. This works well up to a point, after which both channels compete for the same resources. Performance becomes unpredictable right when you need it to stay stable.
Google's new Axion chips tackle this trade-off at the source.
Instead of virtual tricks, every single compute unit maps to a genuine physical core. There is zero resource-sharing and no hidden performance drops under stress.
What you get is a vastly more dependable system, rock-steady latency during peak hours, and a welcome drop in your overall cloud bill.
To cater to different business needs, Google built two distinct processor lines around two very different philosophies:
The N4A instances are designed for organisations managing large fleets of parallel servers that want to cut total costs without sacrificing reliability.
Compared to older x86 setups, they deliver up to 105% better price-performance alongside an 80% reduction in power consumption.
Consider a manufacturing firm running a distributed ERP system across thirty microservices, each on a separate machine. That fleet costs tens of thousands of pounds every month.
By migrating to N4A instances, often without modifying a single line of application code, that same business can expect genuine savings on its monthly invoice, compared both to x86 equivalents and to higher-cost C4A options. The savings do not come from making one individual server fly, but from making the entire fleet radically more efficient.
N4A chips really shine in horizontally scaled environments: web servers, microservices, containers on Google Kubernetes Engine (GKE), enterprise Java applications, build pipelines, and batch jobs. They are also ideal for running lightweight, pre-trained AI models directly on CPUs without paying for dedicated GPUs.
If N4A focuses on efficiency, C4A is built purely for high performance. These instances are tailored for scenarios where every millisecond counts and traffic spikes must be absorbed instantly.
Imagine a real-time payment gateway processing thousands of concurrent transactions. The database has to respond in under ten milliseconds, no matter what. C4A instances deliver up to 100 Gbps in network bandwidth and allow you to hook physical local SSDs (Titanium SSDs) straight into the server, removing the usual latency penalty of remote network storage. For single-threaded tasks, data compression, and AES encryption, they run up to 100% faster than N4A.
They make a critical difference in high-traffic transactional databases like PostgreSQL or Cloud SQL, caching layers like Redis or Memcached, online gaming servers, and AdTech platforms, where unpredictable latency leads directly to lost revenue.
Choosing between the two comes down to a simple question: is your primary bottleneck the overall fleet cost or single-process execution speed? For the former, choose N4A; for the latter, go with C4A
| C4A | N4A | |
| Primary Goal | Peak performance and low latency | Maximum efficiency and cost reduction |
| Architecture | Arm Neoverse V2 | Arm Neoverse N3 |
| Max Network Bandwidth | 100 Gbps | 50 Gbps |
| Local storage | Titanium SSD up to 6 TB | Network storage only |
| Configurations | Predefined and bare metal | Predefined and customizable |
| Relative cost | Base rate | ~14% cheaper |
Ask us how Google Cloud Platform can support and evolve your company’s infrastructure.
Some heavy-duty workloads simply do not play well with virtualisation layers. Think complex computational fluid dynamics, production-grade 3D rendering, continuous embedded firmware testing, or software engineered for hyper-specific hardware targets.
In these demanding setups, even the thinnest hypervisor layer introduces unpredictable overheads that can become frustrating bottlenecks under peak load.
The new C4A.metal instances resolve this by exposing Axion processors straight to the application, eliminating intermediate software layers entirely.
Bare metal access (direct physical hardware access) was already available on other Google Cloud families, but bringing it to the new Axion chips combines next-generation processing power with absolute hardware predictability.
For teams that have kept their most demanding workloads locked away in on-premises data centres because the cloud just could not cut it, this gives you a genuinely viable migration route with zero performance compromises.
Let’s be clear: an AI agent is not a simple chatbot. While a chatbot merely answers queries, an agent takes action. It queries databases, triggers external APIs, and generates and runs code on its own. That level of autonomy is incredibly powerful, but it introduces serious operational risks that many businesses ignore until something breaks.
Going back to our retail scenario: suppose an AI agent updates prices based on warehouse inventory levels. It works flawlessly for weeks. Then an anomaly occurs, a product with unusual formatting or an out-of-range value, and the agent generates an invalid command.
If executed directly on core business systems, that error could trigger mass incorrect price updates, lock the database, or create a severe security vulnerability.
The GKE Agent Sandbox provides a vital isolation layer. It creates a secure, sandboxed environment where the agent executes commands without direct access to production systems. If an anomaly occurs, the error is contained, the sandbox destroys itself in seconds, and the main system remains unaffected. Once verified, approved operations propagate to live systems in a controlled manner.
From a cost perspective, the sandbox leverages Axion N4A instances, making it structurally 30% faster than equivalent AWS or Azure solutions while keeping resource overhead low. For any team launching its first AI agent into production, this is the difference between a smooth release and managing a day-one outage.
Have you heard of Gemini Enterprise? It is Google's agentic platform that connects disparate systems, allowing you to build AI agents capable of generating summaries, executing tasks, providing forecasts, and triggering proactive alerts.
Intrigued? Check out our short guide at this link!
Committed Use Discounts (CUDs) allow Google to reward organisations that commit to using specific services over a fixed period, typically one or three years.
The logic is simple: you provide predictable demand, and Google lowers the unit cost.
Historically, however, this model lacked flexibility: discounts applied to narrow sets of standard servers, and moving workloads between machine types or regions often meant forfeiting active discounts.
With the updates announced at Cloud Next '26, coverage has expanded significantly. CUDs now extend to memory-optimised instances (M1 through M4 series), high-performance compute instances (H3 and H4D), and Cloud Run, Google’s platform for running containerised applications without managing underlying infrastructure.
What does this mean? A company currently paying pay-as-you-go rates for Cloud Run microservices can now commit to a baseline monthly compute volume, lock in structural discounts, and allocate the resulting savings elsewhere without losing active benefits.
For a CFO or IT leader, this shifts variable operational spend into predictable cost structures, freeing up budget for strategic technology investments.
Looking to optimise your Google Cloud infrastructure spend? Read our full guide here.
In the real world, enterprise data rarely sits neatly in one place: customer records live in Salesforce, historical sales figures rest in AWS S3, and ERP platforms run on Azure or local physical servers.
Attempting to plug Google Cloud AI into these fragmented systems presents a challenge: moving large datasets across clouds is slow, complex, and costly due to egress fees and data transfer management.
Cloud Next '26 updates address this challenge through two major innovations:
An AI agent can query data natively hosted on AWS, run inference via Google models, and write results to the required target system, eliminating the need to construct and maintain complex data pipelines. For any business managing a multi-cloud footprint, this removes a major barrier to AI adoption.
Adopting these Cloud Next '26 innovations doesn’t require an immediate infrastructure overhaul. Start by reviewing your current architecture to identify high-impact quick wins.
Want a comprehensive assessment of your Google Cloud environment? Book a session with our team to review your spend, security posture, and roadmap.
There is no need to migrate everything at once. The best approach is to target high-cost workloads first, such as microservice fleets or web servers, and benchmark them on N4A instances. Google provides phased migration tools that let you move individual services independently. Running a comparative assessment is a logical first step.
Yes, it can be integrated into existing environments. While it may require minor updates to your deployment pipeline, it is designed to work with existing Kubernetes clusters. We recommend reviewing your setup with a technical expert prior to deployment, particularly for mission-critical systems.
No. Existing commitments remain under their original terms until their expiration date. The expanded coverage applies to new contracts signed moving forward. If your current commitments are ending soon, plan your strategy ahead of auto-renewal.
It refers to the underlying technology enabling Google Cloud to establish high-speed, secure connectivity with alternative cloud providers like AWS and Azure. The main advantage is that data remains in its original location: Google AI models and agents can query remote sources directly, lowering bandwidth fees, transfer times, and engineering complexity.
Not on its own. Cloud Run is designed for running containerised workloads without managing server infrastructure. If you already use Cloud Run or are planning a migration for technical reasons, CUD eligibility adds immediate financial value. However, infrastructure decisions should always be driven by technical fit rather than discounts alone.