Google Cloud’s latest updates for AI, storage, and GKE

Google Cloud’s May 2026 roundup adds storage automation, worker pools, and AI agent tooling.

Google Cloud packed a lot into its May 23, 2026 update page, and the common thread is pretty clear: the company is trying to make AI infrastructure less fragile and easier to operate. The headline items span Google Kubernetes Engine, Cloud Run, Apigee, and the Google AI Edge stack.

There are also some concrete numbers worth paying attention to: 120+ Android devices in AI Edge Portal testing, three new GPU slice sizes for Fractional G4 VMs, and a May 23 publish date for the roundup itself. Taken together, this is less about flashy demos and more about removing day-to-day friction for teams shipping AI systems.

GKE storage gets a smarter default

The most immediately practical update in the roundup is GKE Dynamic Default Storage Classes. Google says the feature automatically chooses between storage classes when clusters mix VM generations, which matters because storage planning gets messy fast once you start running heterogeneous infrastructure.

If you run Kubernetes at scale, you already know the pain: one storage class works well on newer nodes, another fits older hardware better, and the wrong default can create performance hiccups or wasted capacity. This update aims to reduce that decision-making overhead by letting GKE pick the right default more intelligently.

• Designed for mixed-generation VM clusters
• Automatically selects between storage classes
• Targets simpler storage operations for GKE admins

That matters because storage is usually the part of Kubernetes people remember only after something breaks. A feature like this won’t replace storage planning, but it can cut down on the number of manual tweaks teams make every time they expand or refresh a cluster.

Cloud Run now has a better fit for background work

Cloud Run worker pools are now generally available, and that changes how people can use serverless compute for non-HTTP workloads. Google describes worker pools as a fit for pull-based jobs, background processing, and large-scale AI inference rather than request/response services.

That distinction matters. Traditional serverless services are great when traffic arrives as web requests. They are less convenient when the real work is sitting in a queue, waiting for a Kafka lag to shrink, or chewing through inference tasks in the background. Worker pools fill that gap.

“Cloud Run worker pools provide a new resource type designed specifically for pull-based, non-HTTP workloads.”

Google also open-sourced CREMA, the Cloud Run External Metrics Autoscaler. Built on KEDA, it scales worker pools using external signals such as Pub/Sub backlog or Kafka lag. That is a useful detail because queue-aware autoscaling is exactly the kind of thing teams end up custom-building when the platform does not give them enough control.

• Cloud Run worker pools are GA
• CREMA is open source and built on KEDA
• Autoscaling can react to Pub/Sub backlog and Kafka lag

Compared with plain Cloud Run services, worker pools are a better match for systems that spend more time processing than serving. For AI teams, that can mean inference pipelines; for platform teams, it can mean fewer one-off autoscalers stitched together from scripts and alerts.

Google is pushing harder on agent governance

The other big theme in this roundup is AI governance, especially around the Model Context Protocol, or MCP. Google Cloud is using Apigee to expose enterprise APIs as MCP tools, which lets developers turn existing services into agent-ready endpoints without standing up separate local MCP servers.

That is a strong signal about where Google thinks enterprise AI is going. The company is not treating agents as isolated chat interfaces. It is treating them as software that needs policy, authorization, audit logs, and controlled access to internal systems.

Google’s own event copy for an upcoming session says the goal is to manage governed MCP endpoints, tool access to enterprise data, and audit logs on Google Cloud. That framing is important because the hard part of agent adoption is rarely the model itself. It is permissions, traceability, and the mess of connecting agents to real business systems without opening too many doors.

• Apigee MCP is now generally available
• Managed endpoints remove the need for local MCP servers
• API hub adds semantic search for enterprise tools

For teams building internal copilots or transaction-heavy assistants, this is likely the most strategic update in the whole roundup. An agent that can call tools is useful. An agent that can call the right tools, under policy, with logs you can audit is what enterprises will actually deploy.

Edge AI and developer tooling keep getting more practical

Google Cloud also used the roundup to show it is still investing in the developer workflow around AI. The AI Edge Portal now has new benchmarking and debugging features for LLMs on 120+ Android devices, which is a big deal if you are trying to ship models that behave well across low-end, mid-range, and high-end phones.

That kind of testing matters because on-device AI is brutally sensitive to hardware variation. A model that looks fine on a flagship phone can fall apart on a cheaper device with less memory, weaker thermals, or a different chip vendor. Google is trying to make that variability visible earlier in the process.

There is also a new Google Cloud Workbench Notebooks extension for Visual Studio Code. It lets developers connect local notebooks to managed cloud environments from inside the editor, and Google says the extension is open-sourced on GitHub.

• AI Edge Portal now tests on 120+ Android devices
• Workbench Notebooks brings managed cloud notebooks into VS Code
• The extension is open source for community contributions

That combination points to a familiar Google Cloud strategy: keep the heavy compute in the cloud, but make the developer experience feel local. It is a sensible move, especially for teams that want to iterate quickly without constantly switching between browser tabs, notebooks, and cloud consoles.

What this roundup says about Google Cloud’s direction

This May update page is less about one huge launch and more about a pattern. Google Cloud is tightening the boring but important parts of modern infrastructure: storage defaults, queue-driven autoscaling, API governance, on-device benchmarking, and notebook workflows.

If I had to make one prediction, it is this: the next wave of Google Cloud announcements will keep focusing on operational control for AI systems rather than raw model demos. The companies that care about agents in production are asking the same question over and over, and Google is clearly trying to answer it: how do you connect AI to real systems without losing control of cost, access, and reliability?

That is the question worth watching in the next round of updates, because the vendors that make AI easier to govern will win more enterprise deployments than the ones that only make it easier to prototype.