Networking

Migrating to Google Cloud’s Application Load Balancer: A practical guide

Fri, 10 Apr 2026 16:00:00 +0000

Migrating your existing application load balancer infrastructure from an on-premises hardware solution to Cloud Load Balancing offers substantial advantages in scalability, cost-efficiency, and tight integration within the Google Cloud ecosystem. Yet, a fundamental question often arises: "What about our current load balancer configurations?"

Existing on-premises load balancer configurations often contain years of business-critical logic for traffic manipulation. The good news is that not only can you fully migrate existing functionalities, but this migration also presents a significant opportunity to modernize and simplify your traffic management.

This guide outlines a practical approach for migrating your existing load balancer to Google Cloud’s Application Load Balancer. It addresses common functionalities, leveraging both its declarative configurations and the innovative, event-driven Service Extensions edge compute capability.

A simple, phased approach to migration

Transitioning from an imperative, script-based system to a cloud-native, declarative-first model requires a structured plan. We recommend a straightforward, four-phase approach.

Phase 1: Discovery and mapping

Before commencing any migration, you must understand what you have. Analyze and categorize your current load balancer configurations. What is each rule's intent? Is it performing a simple HTTP-to-HTTPS redirect? Is it engaged in HTTP header manipulation (addition or removal)? Or is it handling complex, custom authentication logic?

Most configurations typically fall into two primary categories:

Common patterns: Logic that is common to most web applications, such as redirects, URL rewrites, basic header manipulation, and IP-based access control lists (ACLs).
Bespoke business logic: Complex logic unique to your application, like custom proprietary token authentication, advanced header extraction / replacement, dynamic backend selection based on HTTP attributes, or HTTP response body manipulation.

Phase 2: Choose your Google Cloud equivalent

Once your rules are categorized, the next step involves mapping them to the appropriate Google Cloud feature. This is not a one-to-one replacement; it's a strategic choice.

Option 1: the declarative path (for ~80% of rules)
For the majority of common patterns, leveraging the Application Load Balancer's built-in declarative features is usually the best approach. Instead of a script, you define the desired state in a configuration file. This is simpler to manage, version-control, and scale.

Common patterns to declarative feature mapping:

Redirects/rewrites -> Application Load Balancer URL maps
ACLs/throttling -> Google Cloud Armor security policies
Session persistence -> backend service configuration

Option 2: The programmatic path (for complex, bespoke rules)
When dealing with complex, bespoke business logic, you have a programmatic equivalent: Service Extensions, a powerful edge compute capability that allows you to inject custom code (written in Rust, C++ or Go) directly into the load balancer's data path. This approach gives you flexibility in a modern, managed, and high-performance framework.

This flowchart helps you decide the appropriate Google Cloud feature for each configuration

Phase 3: Test and validate

Once you’ve chosen the appropriate path for your configurations, you are ready to deploy your new Application Load Balancer configuration in a staging environment that mirrors your production setup. Thoroughly test all application functionality, paying close attention to the migrated logic. Use a combination of automated testing and manual QA to validate the redirects, security policies, and that the custom Service Extensions logic are behaving as expected.

Phase 4: Phased cutover (canary deployment)

Don't flip a single switch for all your traffic; instead, implement a phased migration strategy. Start the transitioning process by routing a small percentage of production traffic (e.g., 5-10%) to your new Google Cloud load balancer. During this initial period, be sure to monitor key metrics like latency, error rates, and application performance. As you gain confidence, you can progressively increase the percentage of traffic routed to the Application Load Balancer. Always have a clear rollback plan to revert back to the legacy infrastructure in the event you encounter critical issues.

Best practices for a smooth migration

Drawing from our practical experience, we have compiled the following recommendations to assist you in planning your load balancer migrations.

Analyze first, migrate second: A thorough analysis of your existing configurations is the most critical step. Don't "lift and shift" logic that is no longer needed.
Prefer declarative: Always default to Google Cloud's managed, declarative features (URL Maps, Cloud Armor) first. They are simpler, more scalable, and require less maintenance.
Use Service Extensions strategically: Reserve Service Extensions for the complex, bespoke business logic that declarative features cannot handle.
Monitor everything: Continuously monitor both your existing load balancers and Google Cloud load balancers during the migration. Watch key metrics like traffic volume, latency, and error rates to detect and address issues instantly.
Train your team: Ensure your team is trained on Cloud Load Balancing concepts. This will empower them to effectively operate and maintain the new infrastructure.

Migrating from the existing on-premises load balancer infrastructure is more than just a technical task, it's an opportunity to modernize your application delivery. By thoughtfully mapping your current load balancing configurations and capabilities to either declarative Application Load Balancer features or programmatic Service Extensions, you can build a more scalable, resilient, and cost-effective infrastructure destined for future demands.

To get started, review the Application Load Balancer and Service Extensions features and advanced capabilities to come up with the right design for your application. For more guidance and complex use cases, contact your Google Cloud team.

Experimenting with GPUs: GKE managed DRANET and Inference Gateway AI Deployment

Wed, 08 Apr 2026 10:05:00 +0000

Building and serving models on infrastructure is a strong use case for businesses. In Google Cloud, you have the ability to design your AI infrastructure to suit your workloads. Recently, I experimented with Google Kubernetes Engine (GKE) managed DRANET while deploying a model for inference with NVIDIA B200 GPUs on GKE. In this blog, we will explore this setup in easy to follow steps.

What is DRANET

Dynamic Resource Allocation (DRA) is a feature that lets you request and share resources among Pods. DRANET allows you to request and allocate networking resources for your Pods, including network interfaces that support TPUs & Remote Direct Memory Access (RDMA). In my case, the use of high-end GPUs.

How GPU RDMA VPC works

The RDMA network is set up as an isolated VPC, which is regional and assigned a network profile type. In this case, the network profile type is RoCEv2. This VPC is dedicated for GPU-to-GPU communication. The GPU VM families have RDMA capable NICs that connect to the RDMA VPC. The GPUs communicate between multiple nodes via this low latency, high speed rail aligned setup.

Design pattern example

Our aim was to deploy a LLM model (Deepseek) onto a GKE cluster with A4 nodes that support 8 B200 GPUs and serve it via GKE Inference gateway privately. To set up an AI Hypercomputer GKE cluster, you can use the Cluster Toolkit, but in my case, I wanted to test the GKE managed DRANET dynamic setup of the networking that supports RDMA for the GPU communication.

This design utilizes the following services to provide an end-to-end solution:

VPC: Total of 3 VPC. One VPC manually created, two created automatically by GKE managed DRANET, one standard and one for RDMA.
GKE: To deploy the workload.
GKE Inference gateway: To expose the workload internally using a regional internal Application Load Balancers type gke-l7-rilb.
A4 VM’s: These support RoCEv2 with NVIDIA B200 GPU.

Putting it together

To get access to the A4 VM a future reservation was used. This is linked to a specific zone.

Begin: Set up the environment

Create a standard VPC, with firewall rules and subnet in the same zone as the reservation.
Create a proxy-only subnet this will be used with the Internal regional application load balancer attached to the GKE inference gateway

Next: Create a standard GKE cluster node and default node pool.

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create $CLUSTER_NAME \\\r\n --location=$ZONE \\\r\n --num-nodes=1 \\\r\n --machine-type=e2-standard-16 \\\r\n --network=${GVNIC_NETWORK_PREFIX}-main \\\r\n --subnetwork=${GVNIC_NETWORK_PREFIX}-sub \\\r\n --release-channel rapid \\\r\n --enable-dataplane-v2 \\\r\n --enable-ip-alias \\\r\n --addons=HttpLoadBalancing,RayOperator \\\r\n --gateway-api=standard \\\r\n --enable-ray-cluster-logging \\\r\n --enable-ray-cluster-monitoring \\\r\n --enable-managed-prometheus \\\r\n --enable-dataplane-v2-metrics \\\r\n --monitoring=SYSTEM'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fc880>)])]>

Once that is complete you can connect to your cluster:

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE --project $PROJECT'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fcd30>)])]>

Create a GPU node pool (this example uses, A4 VM with reservation) and additionals flags:

---accelerator-network-profile=auto (GKE automatically adds the gke.networks.io/accelerator-network-profile: auto label to the nodes)

--node-labels=cloud.google.com/gke-networking-dra-driver=true (Enables DRA for high-performance networking)

code_block: <ListValue: [StructValue([('code', 'gcloud beta container node-pools create $NODE_POOL_NAME \\\r\n --cluster $CLUSTER_NAME \\\r\n --location $ZONE \\\r\n --node-locations $ZONE \\\r\n --machine-type a4-highgpu-8g \\\r\n --accelerator type=nvidia-b200,count=8,gpu-driver-version=latest \\\r\n --enable-autoscaling --num-nodes=1 --total-min-nodes=1 --total-max-nodes=3 \\\r\n --reservation-affinity=specific \\\r\n--reservation=projects/$PROJECT/reservations/$RESERVATION_NAME/reservationBlocks/$BLOCK_NAME \\\r\n --accelerator-network-profile=auto \\\r\n--node-labels=cloud.google.com/gke-networking-dra-driver=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fca60>)])]>

Next: Create a ResourceClaimTemplate, which will be used to attach the networking resources to your deployments. The deviceClassName: mrdma.google.com is used for GPU workloads:

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-mrdma\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-mrdma\r\n exactly:\r\n deviceClassName: mrdma.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fcd90>)])]>

Deploy model and inference

Now that a cluster and node pool is setup, we can deploy a model and serve it via Inference gateway. In my experiment I used DeepSeek but this could be any model.

Deploy model and services

The nodeSelector: gke.networks.io/accelerator-network-profile: auto is used to assign to the GPU node
The resourceClaims: attaches the resource we defined for networking

Create a secret (I used Hugging Face token):

code_block: <ListValue: [StructValue([('code', 'kubectl create secret generic hf-secret \\\r\n --from-literal=hf_token=${HF_TOKEN}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fc850>)])]>

Deployment

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: deepseek-v3-1-deploy\r\nspec:\r\n replicas: 1\r\n selector:\r\n matchLabels:\r\n app: deepseek-v3-1\r\n template:\r\n metadata:\r\n labels:\r\n app: deepseek-v3-1\r\n ai.gke.io/model: deepseek-v3-1\r\n ai.gke.io/inference-server: vllm\r\n examples.ai.gke.io/source: user-guide\r\n spec:\r\n containers:\r\n - name: vllm-inference\r\n image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:20250819_0916_RC01\r\n resources:\r\n requests:\r\n cpu: "190"\r\n memory: "1800Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n limits:\r\n cpu: "190"\r\n memory: "1800Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n claims:\r\n - name: rdma-claim\r\n command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]\r\n args:\r\n - --model=$(MODEL_ID)\r\n - --tensor-parallel-size=8\r\n - --host=0.0.0.0\r\n - --port=8000\r\n - --max-model-len=32768\r\n - --max-num-seqs=32\r\n - --gpu-memory-utilization=0.90\r\n - --enable-chunked-prefill\r\n - --enforce-eager\r\n - --trust-remote-code\r\n env:\r\n - name: MODEL_ID\r\n value: deepseek-ai/DeepSeek-V3.1\r\n - name: HUGGING_FACE_HUB_TOKEN\r\n valueFrom:\r\n secretKeyRef:\r\n name: hf-secret\r\n key: hf_token\r\n volumeMounts:\r\n - mountPath: /dev/shm\r\n name: dshm\r\n livenessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n initialDelaySeconds: 1800\r\n periodSeconds: 10\r\n readinessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n initialDelaySeconds: 1800\r\n periodSeconds: 5\r\n volumes:\r\n - name: dshm\r\n emptyDir:\r\n medium: Memory\r\n nodeSelector:\r\n gke.networks.io/accelerator-network-profile: auto\r\n resourceClaims:\r\n - name: rdma-claim\r\n resourceClaimTemplateName: all-mrdma\r\n---\r\napiVersion: v1\r\nkind: Service\r\nmetadata:\r\n name: deepseek-v3-1-service\r\nspec:\r\n selector:\r\n app: deepseek-v3-1\r\n type: ClusterIP\r\n ports:\r\n - protocol: TCP\r\n port: 8000\r\n targetPort: 8000\r\n---\r\napiVersion: monitoring.googleapis.com/v1\r\nkind: PodMonitoring\r\nmetadata:\r\n name: deepseek-v3-1-monitoring\r\nspec:\r\n selector:\r\n matchLabels:\r\n app: deepseek-v3-1\r\n endpoints:\r\n - port: 8000\r\n path: /metrics\r\n interval: 30s'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fcbb0>)])]>

Deploy GKE Inference Gateway

This install needed Custom Resource Definitions (CRDs) in your GKE cluster:

For GKE versions 1.34.0-gke.1626000 or later, install only the alpha InferenceObjective CRD:

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f https://github.com/kubernetes-sigs/gateway-api-inference-extension/raw/v1.0.0/config/crd/bases/inference.networking.x-k8s.io_inferenceobjectives.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fc910>)])]>

Create Inference pool

code_block: <ListValue: [StructValue([('code', 'helm install deepseek-v3-pool \\\r\n oci://registry.k8s.io/gateway-api-inference-extension/charts/inferencepool \\\r\n --version v1.0.1 \\\r\n --set inferencePool.modelServers.matchLabels.app=deepseek-v3-1 \\\r\n --set provider.name=gke \\\r\n --set inferenceExtension.monitoring.gke.enabled=true'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fcc70>)])]>

Create the Gateway, HTTPRoute and InferenceObjective

code_block: <ListValue: [StructValue([('code', '# 1. The Regional Internal Gateway (ILB)\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: Gateway\r\nmetadata:\r\n name: deepseek-v3-gateway\r\n namespace: default\r\nspec:\r\n gatewayClassName: gke-l7-rilb\r\n listeners:\r\n - name: http\r\n protocol: HTTP\r\n port: 80\r\n allowedRoutes:\r\n namespaces:\r\n from: Same\r\n---\r\n# 2. The HTTPRoute (Routing to the Pool)\r\napiVersion: gateway.networking.k8s.io/v1\r\nkind: HTTPRoute\r\nmetadata:\r\n name: deepseek-v3-route\r\n namespace: default\r\nspec:\r\n parentRefs:\r\n - name: deepseek-v3-gateway\r\n rules:\r\n - matches:\r\n - path:\r\n type: PathPrefix\r\n value: /\r\n backendRefs:\r\n - group: inference.networking.k8s.io\r\n kind: InferencePool\r\n name: deepseek-v3-pool\r\n---\r\n# 3. The Inference Objective (Performance Logic)\r\napiVersion: inference.networking.x-k8s.io/v1alpha2\r\nkind: InferenceObjective\r\nmetadata:\r\n name: deepseek-v3-objective\r\n namespace: default\r\nspec:\r\n poolRef:\r\n name: deepseek-v3-pool'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fcd00>)])]>

Once complete, you can create a test VM in your main VPC and make a call to the IP address of the GKE Inference Gateway:

code_block: <ListValue: [StructValue([('code', 'curl -N -s -X POST "http://$GATEWAY_IP/v1/chat/completions" \\\r\n -H "Content-Type: application/json" \\\r\n -d \'{\r\n "model": "deepseek-ai/DeepSeek-V3.1",\r\n "messages": [{"role": "user", "content": "Box A: red. Box B: blue. Box C: empty. Move A to C, Move B to A, Swap B and C. Where is red?"}],\r\n "stream": true\r\n }\' | stdbuf -oL grep "data: " | sed -u \'s/^data: //\' | grep -v "\\[DONE\\]" | \\\r\n jq --unbuffered -rj \'.choices[0].delta | (.reasoning_content // .reasoning // .content // empty)\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17446fca30>)])]>

Next Steps

Take a deeper dive into GKE managed DRANET and GKE Inference Gateway, review the following.

Blog: DRA: A new era of Kubernetes device management with Dynamic Resource Allocation
Document set: DRANET
Documentation: AI Hypercomputer

Want to ask a question, find out more or share a thought? Please connect with me on Linkedin.

See beyond the IP and secure URLs with Google Cloud NGFW

Tue, 07 Apr 2026 17:30:00 +0000

In a cloud-first world, traditional IP-based defenses are no longer enough to protect your perimeter. As services migrate to shared infrastructure and content delivery networks, relying on static IP addresses and FQDNs can create security gaps.

Because single IP addresses can host multiple services, and IPs addresses can change frequently, we are introducing domain filtering with a wildcard capability in Cloud Next Generation Firewall (NGFW) Enterprise. This new capability provides increased security and granular policy controls.

Why domain and SNI filtering matters

The Cloud NGFW URL filtering service performs deep inspections of HTTP payloads to secure workloads against threats from both public and internal networks. This service elevates security controls to the application layer and helps restrict access to malicious domains.

Key use cases include:

Granular egress control: This capability enables the precise allowing and blocking of connections based on domain names and SNI information found in egress HTTP(S) messages. By inspecting Layer 7 (L7) headers, it offers significantly finer control than traditional filtering based solely on IP addresses and FQDNs, which can be inefficient when a single IP hosts multiple services.
Control access without decrypting: For organizations that prefer not to perform full TLS decryption on their traffic, Cloud NGFW can still enforce security policies by controlling traffic based on SNI headers provided during the TLS handshake. This allows for effective domain-level filtering while maintaining end-to-end encryption for privacy or compliance reasons.
Reduced operational overhead: Implementing domain-based filtering helps reduce the constant maintenance typically required to track frequently changing IP addresses and DNS records. By focusing on stable domain identities rather than dynamic network attributes, security teams can minimize the manual effort involved in updating firewall rulebases.
Flexible matching: The service utilizes matcher strings within URL lists, supporting limited wildcard domains to define criteria for both domains and subdomains. For example, using a wildcard like *.example.com allows a single filter to cover all associated subdomains, providing a more scalable solution than defining thousands of individual FQDN entries.
Improved security: URL filtering significantly enhances the security posture by protecting against sophisticated flaws like SNI header spoofing. By evaluating L7 headers before allowing access to an application, Cloud NGFW ensures that attackers cannot bypass security controls by simply spoofing lower-layer identifiers.

How Cloud NGFW URL filtering works

The URL filtering service functions by inspecting traffic at L7 using a distributed architecture.

Cloud NGFW URL filtering service

You can get started with URL filtering in three simple steps.

Deploy Cloud NGFW endpoints:

The first step is to create and deploy a Cloud NGFW endpoint in a zone. The NGFW endpoint is an organization level resource. Please ensure you have the right permission before deploying the endpoint.
Once the endpoint is deployed you can associate it to one or more VPCs of your choice.

Create security profiles and security profile groups:

The URL filtering security profile holds the URL filters with matcher strings and an action (allow or deny).
The security profile group acts as a container for these security profiles, which is then referenced by a firewall policy rule. Create URL filtering security profiles with desired URLs, wildcard FQDNs and add them to a security profile group.
Once the security profile group is created, you will need to reference the security profile group in firewall policies.

Policy enforcement:

You enable the service by configuring a hierarchical or global network firewall policy rule using the apply_security_profile_group action, specifying the name of your security profile group.

For more information about configuring a firewall policy rule, see the following:

Getting started

Get started with Cloud NGFW URL filtering by visiting our documentation and codelab.

Envoy: A future-ready foundation for agentic AI networking

Fri, 03 Apr 2026 16:00:00 +0000

In today's agentic AI environments, the network has a new set of responsibilities.

In a traditional application stack, the network mainly moves requests between services. But as discussed in a recent white paper, Cloud Infrastructure in the Agent-Native Era, in an agentic system the network sits in the middle of model calls, tool invocations, agent-to-agent interactions, and policy decisions that can shape what an agent is allowed to do. The rapid proliferation of agents, often built on diverse frameworks, necessitates a consistent enforcement of governance and security across all agentic paths at scale. To achieve this, the enforcement layer must shift from the application level to the underlying infrastructure. That means the network can no longer operate as a blind transport layer. It has to understand more, enforce better, and adapt faster. This shift is precisely where Envoy comes in.

As a high-performance distributed proxy and universal data plane, Envoy is built for massive scale. Trusted by demanding enterprise environments, including Google Cloud, it supports everything from single-service deployments to complex service meshes using Ingress, Egress, and Sidecar patterns. Because of its deep extensibility, robust policy integration, and operational maturity, Envoy is uniquely suited for an era where protocols change quickly and the cost of weak control is steep. For teams building agentic AI, Envoy is more than a concept: it's a practical, production-ready foundation.

Agentic AI changes the networking problem

Agentic workloads still often use HTTP as a transport, but they break some of the assumptions that traditional HTTP intermediaries rely on. Protocols such as Model Context Protocol (MCP) and Agent2agent (A2A) use JSON-RPC or gRPC over HTTP, adding protocol-level phases such as MCP initialization, where client and server exchange their capabilities, on top of standard HTTP request/response semantics. The key aspects of agentic systems that require intermediaries to adapt include:

Diverse enterprise governance imperatives. The primary challenge is satisfying the wide spectrum of non-negotiable enterprise requirements for safety, security, data privacy, and regulatory compliance. These needs often go beyond standard network policies and require deep integration with internal systems, custom logic, and the ability to rapidly adapt to new organizational rules or external regulations. This demands a highly extensible framework where enterprises can plug in their specific governance models.
Policy attributes live inside message bodies, not headers. Unlike traditional web traffic where policy inputs like paths and headers are readily accessible, agentic protocols frequently bury critical attributes (e.g., model names, tool calls, resource IDs) deep within JSON-RPC or gRPC payloads. This shift requires intermediaries to possess the ability to parse and understand message contents to apply context-aware policies.
Handling diverse and evolving protocol characteristics. Agentic protocols are not uniform. Some, like MCP with Streamable HTTP, can introduce stateful interactions requiring session management across distributed proxies (e.g., using Mcp-Session-Id). The need to support such varied behaviors, along with future protocol innovations, reinforces the necessity of an inherently adaptable and extensible networking foundation.

These factors mean enterprises need more than just connectivity. The network must now serve as a central point for enforcing the crucial governance needs mentioned earlier. This includes providing capabilities like centralized security, comprehensive auditability, fine-grained policy enforcement, and dynamic guardrails, all while keeping pace with the rapid evolution of protocols and agent behaviors. Put simply, agentic AI transforms the network from a mere transit path into a critical control point.

Why Envoy fits this shift

Envoy is a strong fit for agentic AI networking for three reasons. Envoy is:

Battle-tested. Enterprises already rely on Envoy in high-scale, security-sensitive environments, making it a credible platform to anchor a new generation of traffic management and policy enforcement.
Extensible. Envoy can be extended through native filters, Rust modules, WebAssembly (Wasm) modules, and external processing patterns. That gives platform teams room to adopt new protocols without having to rebuild their networking layer every time the ecosystem changes.
Operationally useful today. Envoy already acts as a gateway, enforcement point, observability layer, and integration surface for control planes. That makes it a practical choice for organizations that need to move now, not after the standards settle.

Building on these core strengths, Envoy has introduced specific architectural advancements to meet the unique demands of agentic networking:

1. Envoy understands agent traffic

The first requirement for agentic networking is simple: The gateway needs to understand what the agent is actually trying to do.

That’s harder than it sounds. In protocols such as MCP, A2A, and OpenAI-style APIs, important policy signals may live inside the request body. Traditional HTTP proxies are optimized to treat bodies as opaque byte streams. That design is efficient, but it limits what the proxy can enforce. For protocols that use JSON messages, a proxy may need to buffer the entire request body to locate attribute values needed for policy application — especially when those attributes appear at the end of the JSON message. Business logic specific to gen AI protocols, such as rate limiting based on consumed tokens, may also require parsing server responses.

Envoy addresses this by deframing protocol messages carried over HTTP and exposing useful attributes to the rest of the filter chain. The extensibility model for gen AI protocols was guided by two goals:

Easy reuse of existing HTTP extensions that work with gen AI protocols out of the box, such as RBAC or tracers.
Easy access to deframed messages for gen-AI-specific extensions, so that developers can focus on gen AI business logic without needing to deal with HTTP or JSON envelopes.

Based on these goals, new extensions for gen AI protocols are still built as HTTP extensions and configured in the HTTP filter chain. This provides flexibility to mix HTTP-native business logic, such as OAuth or mTLS authorization, with gen AI protocol logic in a single chain. A deframing extension parses the protocol messages carried by HTTP and provides an ambient context with extracted attributes, or even the entirety of parsed messages, to downstream extensions via well-known filter state and metadata values.

Instead of forcing every policy component to parse JSON envelopes or protocol-specific message formats on its own, Envoy makes those attributes available as structured metadata. Once the gateway has deframed protocol messages, existing Envoy extensions such as ext_authz or RBAC can read protocol properties to evaluate policies using protocol-specific attributes such as tool names for MCP, message attributes for A2A, or model names for OpenAI.

Access logs can include message attributes for enhanced monitoring and auditing. The protocol attributes are also available to the Common Expression Language (CEL) runtime, simplifying creation of complex policy expressions in RBAC or composite extensions.

Buffering and memory management
Envoy is designed to use as little memory as possible when proxying HTTP requests. However, parsing agentic protocols may require an arbitrary amount of buffer space, especially when extensions require the entire message to be in memory. The flexibility of allowing extensions to use larger buffers needs to be balanced with adequate protection from memory exhaustion, especially in the presence of untrusted traffic.

To achieve this, Envoy now provides a per-request buffer size limit. Buffers that hold request data are also integrated with the overload manager, enabling a full range of protective actions under memory pressure, such as reducing idle timeouts or resetting requests that consume the most memory for an extended duration. These changes pave the way for Envoy to serve as a gateway and policy-enforcement point for gen AI protocols without compromising its resource efficiency.

2. Envoy enforces policy on things that matter

Understanding traffic is only useful if the gateway can act on it.

In agentic systems, policy is not just about which service an agent can reach. It’s about which tools an agent can call, which models it can use, what identity it presents, how much it can consume, and what kinds of outputs require additional controls. Those are higher-value decisions than simple layer-4 or path-based controls, and they are exactly the kinds of controls enterprises care about when agents are allowed to take action on their behalf.

Envoy is well-positioned here because it can combine transport-level security with application-aware policy enforcement. Teams can authenticate workloads with mTLS and SPIFFE identities, then enforce protocol-specific rules with RBAC, external authorization, external processing, access logging, and CEL-based policy expressions.

This capability is crucial because it lets platform teams decouple agent development from enforcement. Developers can focus on building useful agents, while operators enforce a consistent zero-trust posture at the network layer, even as tools, models, and protocols continue to change.A prime example of this zero-trust decoupling is the critical "user-behind-agent" scenario, where an AI agent must execute tasks on a human user's behalf. Traditionally, handing user credentials directly to an application introduces severe security risks — if the agent is compromised or manipulated via prompt injection, an attacker could exfiltrate or misuse those credentials. By offloading identity management to Envoy, the proxy can automatically insert user delegation tokens into outbound requests at the infrastructure layer. Because the agent never directly holds the sensitive credential, the risk of a compromised agent misusing or leaking the token is completely neutralized, ensuring actions remain strictly bound to the user's actual permissions.

Case study: Restricting an agent to specific GitHub MCP tools
Consider an agent that triages GitHub issues.

The GitHub MCP server may expose dozens of tools, but the agent may only need a small read-only subset, such as list_issues, get_issue, and get_issue_comments. In most enterprises, that difference matters. A useful agent should not automatically become an unrestricted one.

With Envoy in front of the MCP server, the gateway can verify the agent identity using SPIFFE during the mTLS handshake, parse the MCP message via the deframing filter, extract the requested method and tool name, and enforce a policy that allows only the approved tool calls for that specific agent identity. RBAC uses metadata created by the MCP deframing filter to check the method and tool name in the MCP message:

code_block: <ListValue: [StructValue([('code', 'envoy.filters.http.rbac:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBACPerRoute\r\n rbac:\r\n rules:\r\n policies:\r\n github-issue-reader-policy:\r\n permissions:\r\n - and_rules:\r\n rules:\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "method" }]\r\n value: { string_match: { exact: "tools/call" } }\r\n - sourced_metadata:\r\n metadata_matcher:\r\n filter: envoy.http.filters.mcp\r\n path: [{ key: "params" }, { key: "name" }]\r\n value:\r\n or_match:\r\n value_matchers:\r\n - string_match: { exact: "list_issues" }\r\n - string_match: { exact: "get_issue" }\r\n - string_match: { exact: "get_issue_comments" }\r\n principals:\r\n - authenticated:\r\n principal_name:\r\n exact: "spiffe://cluster.local/ns/github-agents/sa/issue-triage-agent"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f172251c8e0>)])]>

That’s the real value: Policy is enforced centrally, close to the traffic, and in terms that match the agent's actual behavior.

Beyond static rules: External authorization
A complex compliance policy that can’t be expressed using RBAC rules can be implemented in an external authorization service using the ext_authz protocol. Envoy provides MCP message attributes along with HTTP headers in the context of the ext_authz RPC. It can also forward the agent's SPIFFE identity from the peer certificate:

code_block: <ListValue: [StructValue([('code', 'http_filters:\r\n - name: envoy.filters.http.ext_authz\r\n typed_config:\r\n "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz\r\n grpc_service:\r\n envoy_grpc:\r\n cluster_name: auth_service_cluster\r\n include_peer_certificate: true\r\n metadata_context_namespaces:\r\n - envoy.http.filters.mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f172251c820>)])]>

This allows external services to make authorization decisions based on the full combination of agent identity, MCP method, tool name, and any other protocol attributes, without the agent or the MCP server needing to be aware of the policy layer.

Protocol-native error responses
When Envoy denies a request, the error should be meaningful to the calling agent. For MCP traffic, Envoy can use local_reply_config to map HTTP error codes to appropriate JSON-RPC error responses. For example, a 403 Forbidden can be mapped to a JSON-RPC response with isError: true and a human-readable message, ensuring the agent receives a protocol-appropriate denial rather than an opaque HTTP status code.

3. Envoy supports stateful agent interactions at scale

Not all agent traffic is stateless. Some protocols, including Streamable HTTP for MCP, can rely on session-oriented behavior. That creates a new challenge for intermediaries, especially when traffic flows through multiple gateway instances to achieve scale and resilience. An MCP session effectively binds the agent to the server that established it, and all intermediaries need to know this to direct incoming MCP connections to the correct server.

If a session is established on one backend, later requests in that conversation need to reach the right destination. That sounds straightforward for a single-proxy deployment, but it becomes more complicated in horizontally scaled systems, where multiple Envoy instances may handle different requests from the same agent.

Passthrough gateway
In the simpler passthrough mode, Envoy establishes one upstream connection for each downstream connection. Its primary use is enforcing centralized policies, such as client authorization, RBAC, rate limiting, and authentication, for external MCP servers. The session state transferred between intermediaries needs to include only the address of the server that established the session over the initial HTTP connection, so that all session-related requests are directed to that server.

Session state transfer between different Envoy instances is achieved by appending encoded session state to the MCP session ID provided by the MCP server. Envoy removes the session-state suffix from the session ID before forwarding the request to the destination MCP server. This session stickiness is enabled by configuring Envoy's envoy.http.stateful_session.envelope extension.

Aggregating gateway
In aggregating mode, Envoy acts as a single MCP server by aggregating the capabilities, tools, and resources of multiple backend MCP servers. In addition to enforcing policies, this simplifies agent configuration and unifies policy application for multiple MCP servers.

Session management in this mode is more complicated because the session state also needs to include mapping from tools and resources to the server addresses and session IDs that advertised them. The session ID that Envoy provides to the agent is created before tools or resources are known, and the mapping has to be established later, after the MCP initialization phases between Envoy and the backend MCP servers are complete.

One approach, currently implemented in Envoy, is to combine the name of a tool or resource with the identifier and session ID of its origin server. The exact tool or resource names are typically not meaningful to the agent and can carry this additional provenance information. If unmodified tool or resource names are desirable, another approach is to use an Envoy instance that does not have the mapping, and then recreate it by issuing a tools/list command before calling a specific tool. This trades latency for the complexity of deploying an external global store of MCP sessions, and is currently in planning based on user feedback.

This matters because it moves Envoy beyond simple traffic forwarding. It allows Envoy to serve as a reliable intermediary for real agent workflows, including those spanning multiple requests, tools, and backends.

4. Envoy supports agent discovery

Envoy is adding support for the A2A protocol and agent discovery via a well-known AgentCard endpoint. AgentCard, a JSON document with agent capabilities, enables discovery and multi-agent coordination by advertising skills, authentication requirements, and service endpoints. The AgentCard can be provisioned statically via direct response configuration or obtained from a centralized agent registry server via xDS or ext_proc APIs. A more detailed description of A2A implementation and agent discovery will be published in a forthcoming blog post.

5. Envoy is a complete solution for agentic networking challenges

Building on the same foundation that enabled policy application for MCP protocol in demanding deployments, Envoy is adding support for OpenAI and transcoding of agentic protocols into RESTful HTTP APIs. This transcoding capability simplifies the integration of gen AI agents with existing RESTful applications, with out-of-the-box support for OpenAPI-based applications and custom options via dynamic modules or Wasm extensions. In addition to transcoding, Envoy is being strengthened in critical areas for production readiness, such as advanced policy applications like quota management, comprehensive telemetry adhering to OpenTelemetry semantic conventions for generative AI systems, and integrated guardrails for secure agent operation.

Guardrails for safe agents
The next significant area of investment is centralized management and application of guardrails for all agentic traffic. Integrating policy enforcement points with external guardrails presently requires bespoke implementation and this problem area is ripe for standardization.

Control planes make this operational

The gateway is only part of the story. To achieve this policy management and rollout at scale, a separate control plane is required to dynamically configure the data plane using the xDS protocol, also known as the universal data plane API.

That is where control planes become important. Cloud Service Mesh, alongside open-source projects such as Envoy AI Gateway and kube-agentic-networking, uses Envoy as the data plane while giving operators higher-level ways to define and manage policy for agentic workloads.

This combination is powerful: Envoy provides the enforcement and extensibility in the traffic path, while control planes provide the operating model teams need to deploy that capability consistently.

Why this matters now

The shift towards agentic systems and gen AI protocols such as MCP, A2A, and OpenAI necessitates an evolution in network intermediaries. The primary complexities Envoy addresses include:

Deep protocol inspection. Protocol deframing extensions extract policy-relevant attributes (tool names, model names, resource paths) from the body of HTTP requests, enabling precise policy enforcement where traditional proxies would only see an opaque byte stream.
Fine-grained policy enforcement. By exposing these internal attributes, existing Envoy extensions like RBAC and ext_authz can evaluate policies based on protocol-specific criteria. This allows network operators to enforce a unified, zero-trust security posture, ensuring agents comply with access policies for specific tools or resources.
Stateful transport management. Envoy supports managing session state for the Streamable HTTP transport used by MCP, enabling robust deployments in both passthrough and aggregating gateway modes, even across a fleet of intermediaries.

Agentic AI protocols are still in their early stages, and the protocol landscape will continue to evolve. That’s exactly why the networking layer needs to be adaptable. Enterprises should not have to rebuild their security and traffic infrastructure every time a new agent framework, transport pattern, or tool protocol gains traction. They need a foundation that can absorb change without sacrificing control.

Envoy brings together three qualities that are hard to get in one place: proven production maturity, deep extensibility, and growing protocol awareness for agentic workloads. By leveraging Envoy as an agent gateway, organizations can decouple security and policy enforcement from agent development code.

That makes Envoy more than just a proxy that happens to handle AI traffic. It makes Envoy a future-ready foundation for agentic AI networking.

^{Special thanks to the additional co-authors of this blog: Boteng Yao, Software Engineer, Google and Tianyu Xia, Software Engineer, Google and Sisira Narayana, Sr Product Manager, Google.}

Introducing multi-cluster GKE Inference Gateway: Scale AI workloads around the world

Tue, 17 Mar 2026 16:00:00 +0000

The world of artificial intelligence is moving fast, and so is the need to serve models reliably and at scale. Today, we're thrilled to announce the preview of multi-cluster GKE Inference Gateway to enhance the scalability, resilience, and efficiency of your AI/ML inference workloads across multiple Google Kubernetes Engine (GKE) clusters — even those spanning different Google Cloud regions.

Built as an extension of the GKE Gateway API, the multi-cluster Inference Gateway leverages the power of multi-cluster Gateways to provide intelligent, model-aware load balancing for your most demanding AI applications.

Why multi-cluster for AI inference?

As AI models grow in complexity and users become more global, single-cluster deployments can face limitations:

Availability risks: Regional outages or cluster maintenance can impact service.
Scalability caps: Hitting hardware limits (GPUs/TPUs) within a single cluster or region.
Resource silos: Underutilized accelerator capacity in one cluster can’t be used by another
Latency: Users far from your serving cluster may experience higher latency

The multi-cluster GKE Inference Gateway addresses these challenges head-on, providing a variety of features and benefits:

Enhanced high reliability and fault tolerance: Intelligently route traffic across multiple GKE clusters, including across different regions. If one cluster or region experiences issues, traffic is automatically re-routed, minimizing downtime.
Improved scalability and optimized resource usage: Pool and leverage GPU/TPU resources from various clusters. Handle demand spikes by bursting beyond the capacity of a single cluster and efficiently utilize available accelerators across your entire fleet.
Globally optimized, model-aware routing: The Inference Gateway can make smart routing decisions using advanced signals. With GCPBackendPolicy, you can configure load balancing based on real-time custom metrics, such as the model server's KV cache utilization metric, so that requests are sent to the best-equipped backend instance. Other modes like in-flight request limits are also supported.
Simplified operations: Manage traffic to a globally distributed AI service through a single Inference Gateway configuration in a dedicated GKE "config cluster," while your models run in multiple "target clusters."

How it works

In GKE Inference Gateway there are two foundational resources, InferencePool and InferenceObjective. An InferencePool acts as a resource group for pods that share the same compute hardware (like GPUs or TPUs) and model configuration, helping to ensure scalable and high-availability serving. An InferenceObjective defines the specific model names and assigns serving priorities, allowing Inference Gateway to intelligently route traffic and multiplex latency-sensitive tasks alongside less urgent workloads.

With this release, the system uses Kubernetes Custom Resources to manage your distributed inference service. InferencePool resources in each "target cluster" group model-server backends. These backends are exported and become visible as GCPInferencePoolImport resources in the "config cluster." Standard Gateway and HTTPRoute resources in the config cluster define the entry point and routing rules, directing traffic to these imported pools. Fine-grained load-balancing behaviors, such as using CUSTOM_METRICS or IN_FLIGHT requests, are configured using the GCPBackendPolicy resource attached to GCPInferencePoolImport.

This architecture enables use cases like global low-latency serving, disaster recovery, capacity bursting, and efficient use of heterogeneous hardware.

For more information about GKE Inference Gateway core concepts check out our guide.

Get started today

As you scale your AI inference serving workloads to more users in more places, we're excited for you to try multi-cluster GKE Inference Gateway. To learn more and get started, check out the documentation:

The AI-native core: Highly resilient telco architecture using Google Kubernetes Engine

Wed, 04 Mar 2026 08:00:00 +0000

The telecommunications industry has reached a critical tipping point. Traditional, on-premises-heavy data center models are struggling under the weight of escalating infrastructure costs and an under utilization due to availability and compliance requirements. But the AI era demands exponential scale and beyond-nines reliability. The question for operators is no longer if they should modernize, but which architectural path will help them do that fastest.

Modernization isn't a "rip and replace" event; it’s a strategic choice. Today, we’re showcasing how Google Kubernetes Engine (GKE) can serve as a high-performance foundation for two versatile deployment strategies: cloud-centric evolution and strategic hybrid modernization.

The two paths to network modernization

Every operator has a unique appetite for risk, regulatory landscape, and investment base, with some prioritizing agility, and others emphasizing the need for local control. You can use GKE to support both approaches:

1. Cloud- centric modernization: Agility at scale

This path is for operators looking to fully harness the cloud's elasticity. Whether you’re migrating your own containerized network functions (CNFs) or building a cloud-native service like Ericsson-on-Demand, the goal is the same: move the heavy lifting to Google Cloud.

The benefit: By running mission-critical workloads like Voice Core or Policy Control Functions on Google's global fiber backbone, operators can scale instantly for peak events and move toward "zero-human-touch" operations.
The economics: Transition from heavy upfront CAPEX to a "pay-as-you-grow" model. You no longer need to over-provision hardware that sits idle; the cloud absorbs the bursts for you.
Time to market: Accelerate time to market for new services like fixed wireless access, IoT and private 5G.

2. Strategic hybrid modernization: Cloud agility, local control

For many telcos, a hybrid approach offers a better balance. Here, operators can selectively move agile control plane components and data analytics to the cloud while keeping latency-sensitive user-plane functions on premises or at the edge.

The benefit: Optimize for ultra-low latency and meet strict data sovereignty requirements by keeping data plane traffic local, while still gaining the AI-driven insights and orchestration power of the cloud.
The versatility: Using GKE, you can run your control plane workloads in the cloud and data plane services directly in your own data centers or at the network edge, enjoying a unified operational model across your environments.

Engineering the "telco-grade" foundation

Today, we are proud to showcase how GKE has evolved into the industry's most specialized platform for containerized network functions (CNFs), backed by massive momentum from operators and equipment vendor partners.

It’s achieved this thanks to a variety of capabilities.

Connectivity and isolation

Standard Kubernetes wasn't designed for the complex traffic separation that telcos require. GKE bridges this gap with:

Multi-networking API: A native Kubernetes way to manage multiple interfaces per Pod, bringing standard Network Policies to every interface.
Simulated L2 networking: A "migration superpower" that allows legacy applications to maintain their Layer-2 operational model while running on a modern cloud-native stack.
The telco CNI: Support for Multus, IPvlan, and Whereabouts on specialized Ubuntu images. This allows operators to isolate management, control, and user planes with surgical precision.

Persistent reachability

In a world of ephemeral containers, telco functions need stability. GKE enables this through:

GKE IP route: We’ve integrated equal-cost multi-path (ECMP)-like functionality directly into the GKE dataplane. If a workload fails, it is automatically and rapidly removed from the service path, providing high availability without complex external router configurations.
Persistent IP: GKE provides the static IP support that 5G core functions require for consistent reachability across their lifecycle without NAT that isn't available on standard Kubernetes.

Sub-second convergence

For telcos, every millisecond of downtime is a lost connection. GKE’s dataplane via HA Policy is optimized for near-zero downtime with ultra-fast failure detection and convergence, offering operators the choice between self-managed recovery or fully Google-managed failure detection.

Shifting from "saving" to "solving" with AI

For operators, the ultimate goal of modernization is to transition to an autonomous network. By running the core network functions on a platform adjacent to Google Cloud AI and data platforms such as Vertex AI and BigQuery, they can turn telemetry into actionable changes to optimize the network. Some use cases and benefits that modernization enables include:

Predictive AIOps: Use AI to identify performance degradation and trigger automated healing before a call ever drops. Use the cloud for on-demand burst capacity during sporting events or service launches. Or use the data from your GKE-hosted 5G core to fuel AI-powered automation that anticipates issues before they impact subscribers.
Intent-driven programmability: Shift from expensive, reactive operations and cut down new deployment setup times from several weeks to a couple of hours.
Monetize insights: Leverage AI on cloud-native data to identify and capture entirely new revenue opportunities in addition to rightsizing your networks.

Your journey, your terms

The future of telco is intelligent, resilient, and incredibly flexible. Whether you are taking your first step into a hybrid deployment or launching a fully cloud-hosted core, Google Cloud is your strategic partner.

Join us at MWC: Visit booth #2H40 in Hall 2 to see these solutions in action, including live demonstrations of mobile core running on GKE.

Designing private network connectivity for RAG-capable gen AI apps

Mon, 02 Mar 2026 17:00:00 +0000

The flexibility of Google Cloud allows enterprises to build secure and reliable architecture for their AI workloads. In this blog we will look at a reference architecture for private connectivity for retrieval-augmented generation (RAG)-capable generative AI applications. This architecture is for scenarios where communications of the overall system must use private IP addresses and must not traverse the internet.

The power of RAG

RAG is a powerful technique used to optimize the output of large language models (LLMs) by grounding them in specific, authoritative knowledge bases outside of their original training data. RAG allows an application to retrieve relevant information from your documents, datasources, or databases in real time. This retrieved context is then provided to the model alongside the user’s query, helping to ensure that the AI’s responses are accurate, verifiable, and highly relevant to your business. This improves the quality of responses and reduces hallucinations.

This approach is helpful because it allows you to direct generative AI to use a designated source of truth, rather than relying solely on the model's pre-existing knowledge, and without needing to retrain or fine-tune the model itself.

Design pattern example

To understand how to think about setting up your network for private connectivity for a RAG application in a regional design, let's look at the design pattern.

The setup comprises an external network (on-prem and other clouds) and Google Cloud environments consisting of a routing project, a Shared VPC host project for RAG, and three specialized service projects: data ingestion, serving, and frontend.

This design utilizes the following services to provide an end-to-end solution:

Cloud Interconnect or Cloud VPN: To securely connect from your on-premises or other clouds to the routing VPC network
Network Connectivity Center: Used as an orchestration framework to manage connectivity between the routing VPC network and the RAG VPC network via VPC spokes and hybrid spokes
Cloud Router: In the routing project, facilitates dynamic BGP route exchange between the external network and Google Cloud
Private Service Connect: Provides a private endpoint in the routing VPC network to reach the Cloud Storage bucket for data ingestion without traversing the public internet
Shared VPC: Host project architecture that allows multiple service projects to use a common, centralized VPC network
Google Cloud Armor and Application Load Balancer: Placed in the frontend service project to provide security and traffic management for user interaction
VPC Service Controls: Creates a managed security perimeter around all resources to mitigate data exfiltration risks

The traffic flow

RAG population flow

In the diagram, the green dashed line shows the RAG population flow, which describes how data travels from data engineers to vector storage.

From the external network, data travels over Cloud Interconnect or Cloud VPN.
In the routing projects it uses the Private Service Connect endpoint to get to the Cloud Storage bucket.
From the Cloud Storage bucket in the Data Ingestion service project, the data ingestion subsystem processes the raw data.
The AI model creates vectors from the chunks, returns them to the data ingestion subsystem, which writes them to the RAG datastore in the serving service project.

Inference flow

In the diagram, the orange dashed line shows the inference flow, which describes customer or user requests.

The request travels over Cloud Interconnect or Cloud VPN to the routing VPC network and then over the VPC spoke to the RAG VPC network.
The request reaches the Application Load Balancer protected by Cloud Armor; once allowed, it passes it to the frontend subsystem.
The frontend subsystem forwards the request to the serving subsystem, which augments the prompt with data from the RAG datastore and generates a response via the AI model.
The system generates a response via the AI model, and the grounded response is returned along the same path to the requestor.

Management and routing

In the diagram, the blue dotted lines represent the Network Connectivity Center hybrid and VPC spokes that manage the control plane and route orchestration between the routing network and the RAG VPC network. This ensures that routes learned from the external network are appropriately propagated across the environment.

Please read the entire architecture document Private connectivity for RAG-capable generative AI applications to understand the specific including IAM permissions, VPC Service Controls, and deployment considerations.

Next steps

Take a deeper dive into the Cross-Cloud Network, and other guides about generative AI with RAG:

Document set: Generative AI with RAG
Document: Cross-Cloud Network for distributed applications
Blog: Build Your First ADK Agent Workforce

Want to ask a question, find out more or share a thought? Please connect with me on Linkedin.

Firefly: Illuminating the path to nanosecond-level clock sync in the data center

Mon, 23 Feb 2026 17:00:00 +0000

From the high-frequency trading floors of Wall Street to orchestrating cloud data centers, the ability to synchronize events with nanosecond accuracy is critical. Yet, achieving this level of temporal precision across thousands of interconnected devices in a modern data center is fraught with challenges like clock drift, network jitter, and path asymmetries. And doing so on cloud-hosted infrastructure has traditionally been impossible, preventing a certain class of applications from running there.

This is where Firefly, a clock synchronization system developed by researchers and engineers at Google, comes in. Firefly isn't just a clock synchronization protocol; it's a software-driven approach that combines theoretical insights and practical engineering to deliver ultra-accurate, scalable, and cost-effective time synchronization on commodity hardware within a demanding data center environment.

The nanosecond race: Why precise timing matters

Precise clock synchronization is the foundation of distributed systems. It is non-negotiable in financial exchanges, where regulatory requirements mandate sub-100µs external synchronization to Coordinated Universal Time, or UTC, and fairness demands sub-10ns internal clock synchronization. In high-frequency trading, a minuscule timing advantage can translate to significant financial gains, making accurate timestamping critical for market integrity. Beyond finance, numerous data center operations, including database consistency, distributed logging, virtual machine management, and network telemetry, rely on accurate temporal ordering of events. And as data centers scale, the need for a robust, scalable synchronization solution becomes even more important.

But achieving nanosecond-level synchronization in a dynamic data center environment is difficult. Several factors conspire to undermine precision:

Clock drift: Crystal oscillators, which are fundamental to all clocks, have inherent imperfections that cause them to gradually deviate over time. Although these deviations were considered minor previously, they are substantial when targeting sub-10ns.
Jitter: Network components such as switches and network interface cards (NICs) introduce unpredictable delays. These delays, often stemming from queuing in network buffers or the intricate processing of packets, can manifest as jitter, disrupting the timing of synchronization messages.
Asymmetry: The network path between two devices is rarely symmetrical. Differences in cable lengths, the number of hops, or the internal workings of network equipment can cause signals to take different amounts of time to travel in opposite directions. This asymmetry can introduce significant errors when estimating one-way delays and clock offsets.
Scalability: As data centers expand to house tens of thousands of servers, any synchronization solution must be able to scale efficiently without becoming a bottleneck or requiring disproportionate resources.
Fault tolerance: In a distributed system, failures are inevitable. A synchronization protocol must be resilient to the loss or misbehavior of individual nodes or network links, so that the overall synchronization accuracy is not compromised.

Firefly: Bridging software and theory

Firefly uses a multi-faceted strategy to tackle these challenges, distinguishing itself from prior synchronization protocols. Its core innovations lie in its architectural design and its theoretical underpinnings.

1. Layered synchronization: Firefly employs a novel layered synchronization technique. Instead of relying on a central clock, which can be a single point of failure or introduce delays, it first establishes tight internal synchronization amongst NICs within the data center. Each NIC in the network constantly communicates with a set of its peers, comparing times and making adjustments. From this "swarm" of devices emerges a highly stable and accurate consensus time that the entire group agrees upon. This internal synchronization is rapid and robust, effectively shielding it from external timing disturbances. Concurrently, Firefly synchronizes the entire swarm to UTC. Decoupling of these two processes is crucial, as it prevents external factors like time-server jitter or drift from directly impacting internal synchronization.

2. Distributed consensus over Random graphs: Unlike traditional hierarchical approaches that can be brittle and susceptible to single points of failure, Firefly uses a distributed consensus algorithm built on a d-regular random graph. This means each NIC communicates with a randomly selected set of 'd' peers. Theoretical analysis, as presented in the Firefly research paper, demonstrates that such random graphs offer significant advantages:

Faster convergence: Random graphs promote a more rapid dissemination of clock information across the network, leading to quicker synchronization.
Scalability: The theoretical bounds show that random graphs can maintain synchronization accuracy even as the size of the network grows, provided the number of peers ('d') scales logarithmically with the total number of nodes.
Resilience to asymmetry: The diverse probing paths inherent in random graphs help to average out and mitigate the impact of path asymmetries.

3. Mitigating jitter and asymmetry in practice: Beyond the theoretical advantages of random graphs, Firefly incorporates practical techniques to further refine accuracy:

RTT filtering: By analyzing round-trip time (RTT) measurements, Firefly can identify and discard probe samples that are likely affected by queuing jitter, thereby improving the accuracy of delay estimations.
Path profiling: Firefly actively probes network paths to identify and favor those with minimal asymmetry. This proactive approach helps to select the most reliable paths for synchronization.
Leveraging hardware: Where available, Firefly can utilize features like Transparent Clock (TC) in network switches to accurately account for in-switch delays, further reducing measurement error.

4. Robustness and fault tolerance: Firefly’s use of distributed consensus, combined with its averaging mechanisms, makes it inherently resilient to failures. By not relying on a single time server or a fixed hierarchical structure, the system can gracefully handle the loss or misbehavior of individual nodes.

Performance in the real world

The results discussed in our Firefly research paper are compelling:

Internal synchronization: Firefly consistently achieves sub-10ns NIC-to-NIC synchronization when used in conjunction with Google's latest data center fabric technology. This can be used to determine order of events like packets, logs, remote procedure calls (RPCs) across machines.
External synchronization: The system also delivers significantly better synchronization to UTC than the 100µs regulatory requirement for financial exchanges.

The offset between a pair of clocks that are six hops away in a Firefly-synced network, measured by an oscilloscope via 1 pulse per second.

The accompanying video illustrates the accuracy of NIC-to-NIC synchronization, as quantified by an oscilloscope utilizing a one-pulse-per-second (1PPS) signal from the NICs. Each row corresponds to a NIC clock, with the rising edge indicating the precise moment the NIC clock attains an integer second. The oscilloscope observations confirm that all measured NICs exhibit close synchronization, maintaining alignment within a few nanoseconds.

These results are particularly impressive given that Firefly operates purely in software on commodity hardware, avoiding the need for expensive, specialized synchronization equipment. This makes ultra-accurate time synchronization accessible to a broader range of data center applications.

A foundation for future applications

Firefly's success in delivering nanosecond-level accuracy in a scalable and cost-effective manner has far-reaching implications:

Democratizing high-precision timing: Firefly allows cloud-hosted financial services that traditionally rely on expensive dedicated hardware, to achieve the required precision using standard cloud infrastructure.
Enabling new applications: The availability of precise, synchronized clocks across data center devices can unlock new possibilities in areas like fine-grained network telemetry and congestion control, time-coordinated distributed systems, and deterministic fabric for ML workloads.
Transforming data center operations: By creating a tightly integrated and precisely timed computing entity, Firefly can enhance data centers’ overall efficiency, reliability, and performance.

In conclusion, Firefly represents a significant advancement in the field of clock synchronization. By ingeniously combining theoretical insights into graph theory and consensus algorithms with practical network engineering techniques, it overcomes the long-standing challenges of achieving nanosecond-level precision in complex, distributed environments. As data centers continue to evolve, systems like Firefly will be instrumental in building the high-performance, reliable, and fair infrastructure of the future.

aside_block: <ListValue: [StructValue([('title', '2026 AI Agent Trends in Financial Services'), ('body', <wagtail.rich_text.RichText object at 0x7f17442e2550>), ('btn_text', 'Read it now.'), ('href', 'https://cloud.google.com/resources/content/ai-agent-trends-financial-services-2026'), ('image', <GAEImage: FSI_Confirmation email_500x450>)])]>

Google Distributed Cloud brings public-cloud-like networking to air-gapped environments

Tue, 10 Feb 2026 17:00:00 +0000

Organizations in highly regulated industries often struggle to balance the rigid security of air-gapped environments with the need for the agility and flexibility that the cloud provides. To address this, Google Distributed Cloud (GDC) air-gapped 1.15 introduces new networking features in preview that give you more direct control and visibility without compromising your security posture, as well as a new IPAM feature in general availability that simplifies subnet management. These preview features are Cloud NAT, enhanced connectivity for standard clusters, and advanced HTTP and HTTPS health checks in load balancers. Together, they make it easier for you to manage complex workloads in a secure environment.

Manage outbound traffic with Cloud NAT

Cloud NAT for GDC air-gapped replaces previous egress solutions and gives you more control over how your instances communicate with other networks, on par with public cloud functionality. Cloud NAT provides several benefits:

Configurable egress IPs: You can assign and manage multiple egress IP addresses for your outbound traffic so you can identify exactly which workloads are communicating.
Customizable timeouts: Manage connection lifecycles by adjusting timeouts for different types of traffic.
Granular control: Administrators can create specific subnets for egress IPs, while application operators define how pods and VMs route their traffic.

Connect standard clusters directly to your organization

In a secure environment, isolation should not result in disconnected silos. With the latest release, standard clusters include networking updates that help you communicate across your organization while maintaining strict security boundaries, helping you manage your environment more effectively. The updates include:

Direct pod communication: Your standard cluster pods can now communicate directly with workloads in your organization’s Default VPC. This simplifies how you connect standard clusters and shared clusters.
Flexible firewall policies: You can use both Project Network Policy and Kubernetes Network Policy APIs to set granular rules for traffic entering and leaving your pods and nodes.
Managed load balancing: You can create internal and external load balancers using standard Kubernetes Service APIs, while GDC manages the underlying configuration for you.

Pods within a standard cluster can now connect to other pods directly or through a ClusterIP. While traffic to the Infra VPC remains blocked, you can send traffic to shared cluster workloads through GDC internal load balancers. This ensures your applications can reach necessary services quickly.

Improve reliability with Load Balancer HTTP and HTTPS health checks

Previously, L4 load balancing health checks only monitored basic TCP connectivity, only confirming if a port was open. GDC air-gapped load balancers now support HTTP and HTTPS health checks, which allow you to verify if an application is actually functioning correctly. By checking status codes and response content, you can:

Confirm application health: Verify that services are responding correctly, not just that the server is powered on.
Increase reliability: Automatically detect and route traffic away from applications experiencing internal errors.
Improve visibility: Access better data regarding the health of your VM-based workloads to manage performance before issues arise.

Make subnet management easier with subnet groups

Previously, a child subnet could only reference a single parent subnet. With the introduction of the subnet group, a child subnet can now reference a subnet group that may contain multiple parent subnets. This provides the following benefits:

Overcome the challenges of immutable subnet CIDR: While subnet CIDR range is immutable, subnet group simplifies scaling up IP resources by attaching a new subnet to a subnet group. You can reference a subnet group instead of a single parent subnet for easy scale-up.
Automatically identify a parent subnet: Now you can reference a subnet group as parent rather than as a single subnet. By using a subnet group in this way, you don't need to manually identify a parent subnet that has available IP resources: instead, GDC IPAM automatically finds a subnet in the subnet group with enough available IP space as its parent.
Start with smaller CIDRs for easier planning: Using subnet groups to scale IP resources also means that you can start with smaller and discontinuous CIDRs when creating new parent subnets, making IP resource utilization more efficient and the planning process easier.

Get started

To learn more about these features, please refer to our documentation or contact your Google Cloud account team.

A gRPC transport for the Model Context Protocol

Tue, 13 Jan 2026 17:30:00 +0000

AI agents are moving from test environments to the core of enterprise operations, where they must interact reliably with external tools and systems to execute complex, multi-step goals. The Model Context Protocol (MCP) is the standard that makes this agent to tool communication possible. In fact, just last month we announced the release of fully-managed, remote MCP servers. Developers can now simply point their AI agents or standard MCP clients like Gemini CLI to a globally-consistent and enterprise-ready endpoint for Google and Google Cloud services.

MCP uses JSON-RPC as its standard transport. This brings many benefits as it combines an action-oriented approach with natural language payloads that can be directly relayed by agents in their communication with foundational models. Yet many organizations rely on gRPC, a high-performance, open source implementation of the remote procedure call (RPC) model. Enterprises that have adopted the gRPC framework must adapt their tooling to be compatible with the JSON-RPC transport used by MCP. Today, these enterprises need to deploy transcoding gateways to translate between JSON-RPC MCP requests and their existing gRPC-based services.

An interesting alternative to MCP transcoding is to use gRPC as the custom transport for MCP. Many gRPC users are actively experimenting with this option by implementing their own custom MCP servers. At Google Cloud, we use gRPC extensively to enable services and offer APIs at a global scale, and we’re committed to sharing the technology and expertise that has resulted from this pervasive use of gRPC. Specifically, we’re committed to supporting gRPC practitioners in their journey to adopt MCP in production, and we’re actively working with the MCP community to explore mechanisms to support gRPC as a transport for MCP. The MCP core maintainers have arrived at an agreement to support pluggable transports in the MCP SDK, and in the near future, Google Cloud will contribute and distribute a gRPC transport package to be plugged into the MCP SDKs. A community-backed transport package will enable gRPC practitioners to deploy MCP with gRPC in a consistent and interoperable manner.

The use of gRPC as a transport avoids the need for transcoding and helps maintain operational consistency for environments that are actively using gRPC. In the rest of this post, we explore the benefits of using gRPC as a transport for MCP and how Google Cloud is supporting this journey.

The choice of RPC transport

For organizations already using gRPC for their services, gRPC support allows them to continue to use their existing tooling to access services via MCP without altering the services or implementing transcoding proxies. These organizations are on a journey to keep the benefits of gRPC as MCP becomes the mechanism for agents to access services.

“Because gRPC is our standard protocol in the backend, we have invested in experimental support for MCP over gRPC internally. And we already see the benefits: ease of use and familiarity for our developers, and reducing the work needed to build MCP servers by using the structure and statically typed APIs.” - Stefan Särne, Senior Staff Engineer and Tech Lead for Developer Experience, Spotify

Benefits of gRPC

Using gRPC as a transport aligns MCP with the best practices of modern gRPC-based distributed systems, improving performance, security, operations, and developer productivity.

Performance and efficiency

The performance advantages of gRPC provide a big boost in efficiency, thanks to the following attributes:

Binary encoding (protocol buffers): gRPC uses protocol buffers (Protobufs) for binary encoding, shrinking message sizes by up to 10x compared to JSON. This means less bandwidth consumption and faster serialization/deserialization, which translates to lower latency for tool calls, reduced network costs, and a much smaller resource footprint.
Full duplex bidirectional streaming: gRPC natively supports the client (the agent) and the server (the tool), sending continuous data streams to each other simultaneously over a single, persistent connection. This feature is a game-changer for agent-tool interaction, opening the door to truly interactive, real-time agentic workflows without requiring application-level connection synchronization.
Built-in flow control (backpressure): gRPC includes native flow control to prevent a fast-sending tool from overwhelming the agent.

Enterprise-grade security and authorization

gRPC treats security as a first-class citizen, with enterprise-grade features built directly into its core, including:

Mutual TLS (mTLS): Critical for Zero Trust architectures, mTLS authenticates both the client and the gRPC-powered server, preventing spoofing and helping to ensure only trusted services communicate.
Strong authentication: gRPC offers native hooks for integrating with industry-standard token-based authentication (JWT/OAuth), providing verifiable identity for every AI agent.
Method-level authorization: You can enforce authorization policies directly on specific RPC methods or MCP tools (e.g., an agent is authorized to ReadFile but not DeleteFile), helping to ensure strict adherence to the principle of least privilege and combating "excessive agency."

Operational maturity and developer productivity

gRPC provides a powerful, integrated solution that helps offload resiliency measures and improves developer productivity through extensibility and reusability. Some of its capabilities include:

Unified observability: Native integration with distributed tracing (OpenTelemetry) and structured error codes provides a complete, auditable trail of every tool call. Developers can trace a single user prompt through every subsequent microservice interaction.
Robust resiliency: Features like deadlines, timeouts, and automatic flow control prevent a single unresponsive tool from causing system-wide failures. These features allow a client to specify a policy for a tool call that the framework automatically cancels if exceeded, preventing a cascading failure.
Polyglot development: gRPC generates code for 11+ languages, allowing developers to implement MCP Servers in the best language for the job while maintaining a consistent, strongly-typed contract.
Schema-based input validation: Protobuf's strict typing mitigates injection attacks and simplifies the development task by rejecting malformed inputs at the serialization layer.
Error handling and metadata: The framework provides a standardized set of error codes (e.g., UNAVAILABLE, PERMISSION_DENIED) for reliable client handling, and clients can send and receive out-of-band information as key-value pairs in metadata (e.g., for tracing IDs) without cluttering the main request.

Get started

As a founding member of the Agentic AI Foundation and a core contributor to the MCP specification, Google Cloud, along with other members of the community, has championed the inclusion of pluggable transport interfaces in the MCP SDK. Participate and communicate your interest in having gRPC as a transport for MCP:

Express your interest in enabling gRPC as an MCP transport. Contribute to the active pull request for pluggable transport interfaces for the Python MCP SDK.
Join the community that is shaping the future of communications for AI and help advance the Model Context Protocol. Contributor Communication - Model Context Protocol.
Contact us. We want to learn from your experience and support your journey.

How Hackensack Meridian Health de-risked network migration using VPC Flow Logs

Fri, 09 Jan 2026 17:00:00 +0000

Network administrators rely heavily on VPC Flow Logs for visibility into their network traffic. Last year, we updated VPC Flow Logs to offer expanded network traffic visibility, extending beyond subnets to include VLAN attachments and VPN tunnels. This enhancement provides comprehensive monitoring of network traffic across your on-premises and multi-cloud environments.

Now, with VPC Flow Logs for VLAN attachments, you can export detailed telemetry data for your network traffic traversing Cloud Interconnect. This data encompasses essential information such as source and destination IP addresses, ports, protocols, bytes/packets transferred, timestamps, and other relevant metadata. These logs are crucial for a variety of use-cases, including network traffic analysis, troubleshooting, capacity planning, and maintaining compliance and security. Then, you can use Flow Analyzer to quickly analyze your VPC Flow Logs to gain valuable insights into your network without writing complex SQL queries.

Sounds great, but how do you use it? Hackensack Meridian Health (HMH) is a leading not-for-profit healthcare organization and the largest hospital system in New Jersey. As a network of hospitals, urgent care centers, and physician practices, system reliability is extremely important and a cornerstone value of HMH. In this blog post, we demonstrate how HMH leveraged VPC Flow Logs and Flow Analyzer to analyze their Cloud Interconnect traffic prior to migrating their Google Cloud network to a new architecture design.

Let’s jump in.

Using VPC Flow Logs to prepare for migration

Last year, HMH was getting ready to migrate their critical, large-scale network to a newer Google Cloud network design. Before a migration of this scale, they wanted to use sankey diagrams to get a clear understanding of their most important hybrid traffic patterns. This analysis was the only way to accurately identify — and proactively plan for — the biggest risks that could cause disruption during the cutover.

"Getting a clear picture of our interconnect traffic always felt like a black box. Enabling VPC Flow Logs and feeding it into Flow Analyzer finally gave us the 'who-is-talking-to-what' map we needed. Identifying those critical traffic flows before we changed any routes was key to de-risking the entire migration." - Randall Brokaw, Cloud Engineering Manager, Hackensack Meridian Health

To collect the necessary data, HMH enabled VPC Flow Logs on all of their VLAN attachments, then leveraged Flow Analyzer to easily aggregate the ingress and egress data. The following query components were used for ingress analysis:

Flow Analyzer query

Source

Filter: Gateway type = INTERCONNECT_ATTACHMENT
Organize Flows By: Gateway location, Gateway VPC network

Destination

Organize Flows By: GCE Instance Project, Google service type

These selections filter VPC Flow Logs to ingress traffic over Cloud Interconnect VLAN attachments, and aggregate the source traffic volume by Google Cloud region and VPC network.

The destination data was grouped by Compute Engine instance project to easily identify the destination application, since each application is deployed into a dedicated service project. However, since not all traffic is sent to Compute Engine VMs, incorporating the Google service type enabled them to account for traffic destined for Google APIs and Google VPC hosted services.

In your environment, the best flow parameters and destination grouping to conduct this analysis will depend on how your organization deploys applications on Google Cloud. For example, you can group by any of the available fields collected by VPC Flow Logs metadata, such as IP address and port, VPC subnet, GKE cluster, and more.

HMH then transformed the VPC Flow Logs traffic volumes into sankey diagrams. This required formatting each traffic flow into multiple three-column rows of {source, destination, weight}. For this analysis, the weight was the traffic volume displayed in Flow Analyzer, and source,destination corresponded to each layer of the sankey visualization in the following order:

Data center to Google Cloud region
Google Cloud region to VPC network
VPC network to application

Selecting “View the query in Log Analytics” from the Flow Analyzer console allows the traffic flows to be easily exported to Google Sheets and combined correctly for the diagram. Then using Google Charts, HMH created the sankey diagram:

code_block: <ListValue: [StructValue([('code', "var data = new google.visualization.DataTable();\r\n\r\ndata.addColumn('string', 'From');\r\ndata.addColumn('string', 'To');\r\ndata.addColumn('number', 'Weight');\r\ndata.addRows([\r\n [ 'On Premises', 'us-central1', 28 ],\r\n [ 'On Premises', 'us-east1', 7 ],\r\n [ 'us-east1', 'Prod Network', 2 ],\r\n [ 'us-east1', 'Shared Network', 9 ],\r\n [ 'us-central1', 'Prod Network', 4 ],\r\n ...\r\n]);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f1757076340>)])]>

Google Charts sankey diagram - Analysis of Cloud Interconnect traffic

Using VPC Flow Logs, HMH network engineers pinpointed critical cutover moments in their plan, allowing them to de-risk the migration through proactive monitoring and preparedness. This preparation proved its value when a migration issue was detected in 3 minutes and resolved in just 5 — slashing a resolution process that previously could have taken hours. This readiness was fundamental to the migration's success.

This implementation uses Flow Analyzer which requires VPC Flow Logs to be stored in Cloud Logging. Alternatively, you have the option to forward VPC Flow Logs straight to BigQuery, bypassing Cloud Logging. From there, you can utilize visualization services like Looker to construct personalized dashboards and gain valuable insights.

VPC Flow Logs and Flow Analyzer for the win

HMH used VPC Flow Logs and Flow Analyzer to facilitate their network migration. But, by providing granular visibility into your Cloud Interconnect traffic, VPC Flow Logs can enable many other use cases, such as for capacity planning, cost attribution, and more. Enable VPC Flow Logs on your VLAN attachments today and leverage Flow Analyzer for insights into your traffic flow patterns.

To learn more, check out the VPC Flow Logs documentation or get started with Flow Analyzer to analyze your logs at no additional cost.

Responding to CVE-2025-55182: Secure your React and Next.js workloads

Wed, 03 Dec 2025 23:00:00 +0000

Editor's note: This blog was updated on Dec. 4, 5, 7, and 12, 2025, with additional guidance on Cloud Armor WAF rule syntax, and WAF enforcement across App Engine Standard, Cloud Functions, and Cloud Run.

Earlier today, Meta and Vercel publicly disclosed two vulnerabilities that expose services built using the popular open-source frameworks React Server Components (CVE-2025-55182) and Next.js to remote code execution risks when used for some server-side use cases. At Google Cloud, we understand the severity of these vulnerabilities, also known as React2Shell, and our security teams have shared their recommendations to help our customers take immediate, decisive action to secure their applications.

Vulnerability background

The React Server Components framework is commonly used for building user interfaces. On Dec. 3, 2025, CVE.org assigned this vulnerability as CVE-2025-55182. The official Common Vulnerability Scoring System (CVSS) base severity score has been determined as Critical, a severity of 10.0.

Vulnerable versions: React 19.0, 19.1.0, 19.1.1, and 19.2.0
Patched in React 19.2.1
Fix: https://github.com/facebook/react/commit/7dc903cd29dac55efb4424853fd0442fef3a8700
Announcement: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Next.js is a web development framework that depends on React, and is also commonly used for building user interfaces. (The Next.js vulnerability was referenced as CVE-2025-66478 before being marked as a duplicate.)

Vulnerable versions: Next.js 15.x, Next.js 16.x, Next.js 14.3.0-canary.77 and later canary releases
Patched versions are listed here.
Fix: https://github.com/vercel/next.js/commit/6ef90ef49fd32171150b6f81d14708aa54cd07b2
Announcement: https://nextjs.org/blog/CVE-2025-66478

Google Threat Intelligence Group (GTIG) has also published a new report to help understand the specific threats exploiting React2Shell.

We strongly encourage organizations who manage environments relying on the React and Next.js frameworks to update to the latest version, and take the mitigation actions outlined below.

Mitigating CVE-2025-55182

We have created and rolled out a new Cloud Armor web application firewall (WAF) rule designed to detect and block exploitation attempts related to CVE-2025-55182. This new rule is available now and is intended to help protect your internet-facing applications and services that use global or regional Application Load Balancers. We recommend deploying this rule as a temporary mitigation while your vulnerability management program patches and verifies all vulnerable instances in your environment.

For customers using App Engine Standard, Cloud Functions, Cloud Run, Firebase Hosting or Firebase App Hosting, we provide an additional layer of defense for serverless workloads by automatically enforcing platform-level WAF rules that can detect and block the most common exploitation attempts related to CVE-2025-55182.

For Project Shield users, we have deployed WAF protections for all sites and no action is necessary to enable these WAF rules. For long-term mitigation, you will need to patch your origin servers as an essential step to eliminate the vulnerability (see additional guidance below).

Cloud Armor and the Application Load Balancer can be used to deliver and protect your applications and services regardless of whether they are deployed on Google Cloud, on-premises, or on another infrastructure provider. If you are not yet using Cloud Armor and the Application Load Balancer, please follow the guidance further down to get started.

While these platform-level rules and the optional Cloud Armor WAF rules (for services behind an Application Load Balancer) help mitigate the risk from exploits of the CVE, we continue to strongly recommend updating your application dependencies as the primary long-term mitigation.

Deploying the cve-canary WAF rule for Cloud Armor

To configure Cloud Armor to detect and protect from CVE-2025-55182, you can use the cve-canary preconfigured WAF rule leveraging the new ruleID that we have added for this vulnerability. This rule is opt-in only, and must be added to your policy even if you are already using the cve-canary rules.

In your Cloud Armor backend security policy, create a new rule and configure the following match condition:

code_block: <ListValue: [StructValue([('code', "(has(request.headers['next-action']) || has(request.headers['rsc-action-id']) || request.headers['content-type'].contains('multipart/form-data') || request.headers['content-type'].contains('application/x-www-form-urlencoded')) && evaluatePreconfiguredWaf('cve-canary',{'sensitivity': 0, 'opt_in_rule_ids': ['google-mrs-v202512-id000001-rce','google-mrs-v202512-id000002-rce']})"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f175ab3e280>)])]>

This can be accomplished from the Google Cloud console by navigating to Cloud Armor and modifying an existing or creating a new policy.

Cloud Armor rule creation in the Google Cloud console.

Alternatively, the gcloud CLI can be used to create or modify a policy with the requisite rule:

code_block: <ListValue: [StructValue([('code', 'gcloud compute security-policies rules create PRIORITY_NUMBER \\\r\n --security-policy SECURITY_POLICY_NAME \\\r\n --expression "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})" \\\r\n --action=deny-403'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f175ab3e730>)])]>

Additionally, if you are managing your rules with Terraform, you may implement the rule via the following syntax:

code_block: <ListValue: [StructValue([('code', 'rule {\r\n action = "deny(403)"\r\n priority = "PRIORITY_NUMBER"\r\n match {\r\n expr {\r\n expression = "(has(request.headers[\'next-action\']) || has(request.headers[\'rsc-action-id\']) || request.headers[\'content-type\'].contains(\'multipart/form-data\') || request.headers[\'content-type\'].contains(\'application/x-www-form-urlencoded\')) && evaluatePreconfiguredWaf(\'cve-canary\',{\'sensitivity\': 0, \'opt_in_rule_ids\': [\'google-mrs-v202512-id000001-rce\',\'google-mrs-v202512-id000002-rce\']})"\r\n }\r\n }\r\n description = "Applies protection for CVE-2025-55182 (React/Next.JS)"\r\n }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f175ab3e670>)])]>

Verifying WAF rule safety for your application and consuming telemetry

Cloud Armor rules can be configured in preview mode, a logging-only mode to test or monitor the expected impact of the rule without Cloud Armor enforcing the configured action. We recommend that the new rule described above first be deployed in preview mode in your production environments so that you can see what traffic it would block.

Once you verify that the new rule is behaving as desired in your environment, then you can disable preview mode to allow Cloud Armor to actively enforce it.

Cloud Armor per-request WAF logs are emitted as part of the Application Load Balancer logs to Cloud Logging. To see what Cloud Armor’s decision was on every request, load balancer logging first needs to be enabled on a per backend service basis. Once it is enabled, all subsequent Cloud Armor decisions will be logged and can be found in Cloud Logging by following these instructions.

Interaction of Cloud Armor rules with vulnerability scanning tools

There has been a proliferation of scanning tools designed to help identify vulnerable instances of React and Next.js in your environments. Many of those scanners are designed to identify the version number of relevant frameworks in your servers and do so by crafting a legitimate query and inspecting the response from the server to detect the version of React and Next.js that is running.

Our WAF rule is designed to detect and prevent exploit attempts of CVE-2025-55182. As the scanners discussed above are not attempting an exploit, but sending a safe query to elicit a response revealing indications of the version of the software, the above Cloud Armor rule will not detect or block such scanners.

If the findings of these scanners indicate a vulnerable instance of software protected by Cloud Armor, that does not mean that an actual exploit attempt of the vulnerability will successfully get through your Cloud Armor security policy. Instead, such findings mean that the version React or Next.js detected is known to be vulnerable and should be patched.

How to get started with Cloud Armor for new users

If your workload is already using an Application Load Balancer to receive traffic from the internet, you can configure Cloud Armor to protect your workload from this and other application-level vulnerabilities (as well as DDoS attacks) by following these instructions.

If you are not yet using an Application Load Balancer and Cloud Armor, you can get started with the external Application Load Balancer overview, the Cloud Armor overview, and the Cloud Armor best practices.

If your workload is using Cloud Run, Cloud Run functions, or App Engine and receives traffic from the internet, you must first set up an Application Load Balancer in front of your endpoint to leverage Cloud Armor security policies to protect your workload. You will then need to configure the appropriate controls to ensure that Cloud Armor and the Application Load Balancer can’t be bypassed.

Best practices and additional risk mitigations

Once you configure Cloud Armor, we recommend consulting our best practices guide. Be sure to account for limitations discussed in the documentation to minimize risk and optimize performance while ensuring the safety and availability of your workloads.

Serverless platform protections

Google Cloud is enforcing platform-level protections across App Engine Standard, Cloud Functions, and Cloud Run to automatically help protect against common exploit attempts of CVE-2025-55182. This protection supplements the protections already in place for Firebase Hosting and Firebase App Hosting.

What this means for you:

Applications deployed to those serverless services benefit from these WAF rules that are enabled by default to help provide a base level of protection without requiring manual configuration.
These rules are designed to block known malicious payloads targeting this vulnerability.

Important considerations:

Patching is still critical: These platform-level defenses are intended to be a temporary mitigation. The most effective long-term solution is to update your application's dependencies to non-vulnerable versions of React and Next.js, and redeploy them.
Potential impacts: While unlikely, if you believe this platform-level filtering is incorrectly impacting your application's traffic, please contact Google Cloud Support and reference issue number 465748820.

Long-term mitigation: Mandatory framework update and redeployment

While WAF rules provide critical frontline defense, the most comprehensive long-term solution is to patch the underlying frameworks.

While Google Cloud is providing platform-level protections and Cloud Armor options, we urge all customers running React and Next.js applications on Google Cloud to immediately update their dependencies to the latest stable versions (React 19.2.1 or the relevant version of Next.js listed here), and redeploy their services.

This applies specifically to applications deployed on:

Cloud Run, Cloud Run functions, or App Engine: Update your application dependencies with the updated framework versions and redeploy.
Google Kubernetes Engine (GKE): Update your container images with the latest framework versions and redeploy your pods.
Compute Engine: The public OS images provided by Google Cloud do not have React or Next.js packages installed by default. If you have installed a custom OS with the affected packages, update your workloads to include the latest framework versions and enable WAF rules in front of all workloads.
Firebase: If you’re using Cloud Functions for Firebase, Firebase Hosting, or Firebase App Hosting, update your application dependencies with the updated framework versions and redeploy. Firebase Hosting and App Hosting are also automatically enforcing a rule to limit exploitation of CVE-2025-55182 through requests to custom and default domains.

Patching your applications is an essential step to eliminate the vulnerability at its source and ensure the continued integrity and security of your services.

We will continue to monitor the situation closely and provide further updates and guidance as necessary. Please refer to our official Google Cloud Security advisories for the most current information and detailed steps.

If you have any questions or require assistance, please contact Google Cloud Support and reference issue number 465748820.

Gain Cross-Cloud Network traffic insights with VPC Flow Logs and Flow Analyzer

Mon, 01 Dec 2025 17:00:00 +0000

Gaining visibility into your network traffic is crucial, particularly with hybrid environments encompassing both on-premises and cross-cloud infrastructure. VPC Flow Logs have long been a staple to obtain detailed records of network traffic to, from, and within your Google Cloud subnets. But with the rise of more complex network topologies enabled by the Cross-Cloud Network, we knew we needed to expand VPC Flow Logs to give you a more complete picture.

That's why we're excited to share that you can now enable VPC Flow Logs directly on your Cloud VPN tunnels and VLAN attachments for Cloud Interconnect and Cross-Cloud Interconnect. This enhancement provides comprehensive monitoring of critical network traffic moving between your on-prem infrastructure, cross-cloud resources, and Google Cloud. With this new capability, you can:

Gain granular insights: Log network flows passing through Cloud Interconnect and Cloud VPN with 5-tuple granularity (source/destination IP, source/destination port, protocol).
Optimize performance: Quickly identify "elephant flows" (high-bandwidth flows) that might be congesting a specific VPN tunnel or VLAN attachment, enabling you to better plan and manage capacity.
Audit Shared VPC usage: In Shared VPC environments, identify which service projects are consuming the most hybrid bandwidth.
Map utilization to flows: Understand exactly how your hybrid connections are being utilized by mapping high-level bandwidth graphs to specific application flows.
Diagnose connectivity issues: When an on-prem/cross-cloud application can't reach a Google Cloud resource, use logs to check if the traffic is arriving at the Google Cloud gateway (VLAN attachment or VPN tunnel).
Finetune your application awareness on Cloud Interconnect policy configurations: Monitor and verify that your applications are marking differentiated services field codepoints (DSCP) correctly.

To provide more context to these flows, we've also added "gateway" annotations to VPC Flow Logs. Think of a gateway as the entry or exit point for traffic traveling between your Google Cloud VPC and an external network.

When you inspect a flow log of Cross-Cloud Network traffic, you'll now see two key new fields:

reporter: This field tells you the direction of the traffic, relative to the gateway.

SRC_GATEWAY: The traffic was observed entering Google Cloud through Cloud Interconnect or Cloud VPN (e.g., on-prem to Google Cloud).
DEST_GATEWAY: The traffic was observed exiting Google Cloud through Cloud Interconnect or Cloud VPN (e.g., Google Cloud to on-prem).

gateway object: This JSON payload provides the full context of the gateway itself, including its name, type (VPN_TUNNEL or INTERCONNECT_ATTACHMENT), project_id, and location.

Analyze your logs with Flow Analyzer

To help you analyze your flow logs without writing-complex SQL queries, we’ve also integrated the new gateway annotations directly into Flow Analyzer, a native tool for performing deep network traffic analysis on your VPC Flow Logs stored in Cloud Logging at no additional cost. Using Flow Analyzer, you can:

Quickly identify top talkers in your network with 5-tuple granularity.
Run Connectivity Tests in-context to understand how your configurations (ie. firewall policies) impact traffic flowing through your network.
Use Gemini Cloud Assist to construct natural language queries.
Analyze and compare current network flows with historical data (e.g., last hour, day, or week).

Flow Analyzer providing Cloud Interconnect traffic insights

Achieve essential visibility across the Cross-Cloud Network

If you're running a Cross-Cloud Network, enabling VPC Flow Logs on your VLAN attachments and VPN tunnels provides the essential telemetry you need to manage, secure, and scale your interconnected networks. You can enable this feature on your new and existing VLAN attachments and VPN tunnels using CLI, API, Terraform, or directly from the Google Cloud console.

To learn more, check out the VPC Flow Logs documentation or get started with Flow Analyzer.

AWS and Google Cloud collaborate to simplify multicloud networking

Sun, 30 Nov 2025 19:00:00 +0000

As organizations increasingly adopt multicloud architectures, the need for interoperability between cloud service providers has never been greater. Historically, however, connecting these environments has been a challenge, forcing customers to take a complex "do-it-yourself" approach to managing global multi-layered networks at scale.

To address these challenges and advance a more open cloud environment, Amazon Web Services (AWS) and Google Cloud collaborated to transform how cloud service providers could connect with one another in a simplified manner.

Today, AWS and Google Cloud are excited to announce a jointly engineered multicloud networking solution that uses both AWS Interconnect - multicloud and Google Cloud’s Cross-Cloud Interconnect. This collaboration also introduces a new open specification for network interoperability, enabling customers to establish private, high-speed connectivity between Google Cloud and AWS with high levels of automation and speed.

“Integrating Salesforce Data 360 with the broader IT landscape requires robust, private connectivity. AWS Interconnect - multicloud allows us to establish these critical bridges to Google Cloud with the same ease as deploying internal AWS resources, utilizing pre-built capacity pools and the tools our teams already know and love. This native, streamlined experience — from provisioning through ongoing support — accelerates our customers' ability to ground their AI and analytics in trusted data, regardless of where it resides.” - Jim Ostrognai, SVP Software Engineering, Salesforce

Previously, to connect cloud service providers, customers had to manually set up complex networking components including physical connections and equipment; this approach required lengthy lead times and coordinating with multiple internal and external teams. This could take weeks or even months. AWS had a vision for developing this capability as a unified specification that could be adopted by any cloud service provider, and collaborated with Google Cloud to bring it to market.

Now, this new solution reimagines multicloud connectivity by moving away from physical infrastructure management toward a managed, cloud-native experience. By integrating AWS with Google Cloud’s Cross-Cloud Network architecture, we are abstracting the complexity of physical connectivity, network addressing, and routing policies. Customers no longer need to wait weeks for circuit provisioning: they can now provision dedicated bandwidth on demand and establish connectivity in minutes through their preferred cloud console or API.

Reliability and security are the cornerstone of this collaboration. We have collaborated on this solution to deliver high resiliency by leveraging quad-redundancy across physically redundant interconnect facilities and routers. Both providers engage in continuous monitoring to proactively detect and resolve issues. And this solution is built on a foundation of trust, utilizing MACsec encryption between the Google Cloud and AWS edge routers.

“This collaboration between AWS and Google Cloud represents a fundamental shift in multicloud connectivity. By defining and publishing a standard that removes the complexity of any physical components for customers, with high availability and security fused into that standard, customers no longer need to worry about any heavy lifting to create their desired connectivity. When they need multicloud connectivity, it's ready to activate in minutes with a simple point and click.” - Robert Kennedy, VP of Network Services, AWS

“We are excited about this collaboration which enables our customers to move their data and applications between clouds with simplified global connectivity and enhanced operational effectiveness. Today's announcement further delivers on Google Cloud’s Cross-Cloud Network solution focused on delivering an open and unified multicloud experience for customers.” - Rob Enns, VP/GM of Cloud Networking, Google Cloud

This collaboration between AWS and Google Cloud is more than a multicloud solution: it’s a step toward a more open cloud environment. The API specifications developed for this product are open for other providers and partners to adopt, as we aim to simplify global connectivity for everyone. We invite you to explore this new capability today. To learn more about how to streamline your multicloud operations please visit the in-depth Google Cloud Cross-Cloud Interconnect blog and the AWS Interconnect - multicloud website to get started.

Expanding Google Cloud’s Cross-Cloud Network with a groundbreaking AWS collaboration

Sun, 30 Nov 2025 19:00:00 +0000

Today, we announced a significant collaboration with Amazon Web Services (AWS) to offer a managed, private and secure, on-demand, solution for cross-cloud connectivity. This solution is designed to enable customers to easily build enterprise-grade applications that span both Google Cloud and AWS environments. This collaboration is particularly timely, as the adoption of multicloud applications is rapidly accelerating, driven in part by the rise of AI. A Forbes survey highlighted that 82% of respondents anticipate that the arrival of AI services will increase the demand for multicloud networking due to the scarcity of specialized accelerator resources and the availability of diverse AI agents across different vendors. The surge in multicloud adoption is a strategic imperative for organizations looking to build agentic AI applications, optimize workloads, access best-of-breed services, meet data residency requirements, and ensure the necessary resiliency for modern hybrid and multicloud applications.

To address the inherent network infrastructure challenges introduced by multicloud deployments, we designed the Cross-Cloud Network to simplify and optimize networking between Google Cloud and other providers.This commitment to multicloud integration has led to over 50% of the Fortune 500 currently using the Cross-Cloud Network, and this collaboration provides a significant boost. Importantly, this new jointly engineered solution with AWS is being published under an open specification, creating an opportunity to expand the reach, allowing other providers to contribute and implement this solution in their own environments, further benefiting mutual customers.

Introducing the Cross-Cloud Interconnect for AWS

Today marks a major step in simplifying and securing the multicloud journey. We are thrilled to announce a first of its kind open specification that fundamentally streamlines private network connections between customers' environments across different cloud providers. This groundbreaking joint specification has culminated in the preview of partner Cross-Cloud Interconnect for AWS, a powerful expansion of our Cloud Interconnect portfolio. This innovation allows you to build on-demand connections in minutes between your Google Cloud and AWS VPCs, transforming multicloud networking from a complex build into a simple, managed service.

This is more than just a connection — it's a complete shift in how you adopt multicloud solutions. We are delivering substantial value to our mutual customers:

Simplicity and speed: Say goodbye to complex networking builds. This is a fully managed, cloud-native experience where a cross-cloud connection is as easy as peering two VPCs. We're cutting end-to-end setup time from days to mere minutes, with flexible, on-demand bandwidth starting at 1 Gbps during preview and scaling up to 100 Gbps at general availability.
Secure by default: Your data's security is paramount. All connections between the two clouds' edge routers are MACsec-encrypted — providing line-rate performance with always-on encryption — for a more secure foundation.
Inherently resilient: Benefit from an inherently resilient architecture that provides layers of protection against facility, network, and software failures, ensuring your critical applications remain online.
Open and optimized: The foundation is an open specification for seamless adoption across the industry. You can also benefit from an optimized total cost of ownership through vendor consolidation and an on-demand service model that lets you provision exactly what you need, when you need it.

This service is launching with availability in key locations like N. Virginia, Oregon, London, and Frankfurt, with rapid expansion planned to more locations globally.

Simplifying cross-cloud connectivity

Before today's jointly engineered solution, building applications that spanned multiple cloud environments was a significant undertaking, often becoming a barrier to multicloud adoption. Customers faced a complex, multi-layered process that involved cross-functional teams and substantial lead times.

A typical deployment required several intricate steps:

Procurement: Acquiring physical connections, whether dedicated or through a shared partner offering, and then building and managing the necessary infrastructure to ensure network availability and separation of fate.
Logical configuration: Establishing basic connectivity by meticulously assigning and negotiating non-overlapping link-local IP addresses and setting up VLANs.
Routing setup: Configuring BGP sessions, assigning Autonomous System (AS) numbers, and creating complex routing policies to meet specific performance and reliability requirements.
Security implementation: Conducting thorough security reviews and implementing custom solutions to encrypt traffic between the distinct cloud environments.

The integrated partner Cross-Cloud Interconnect offering completely abstracts away this complexity. Customers can now bypass all the manual steps and instantly leverage pre-built physical connections with built-in security and resiliency, achieving streamlined, on-demand connectivity between their Google Cloud VPCs and AWS.

Building this powerful cross-cloud connection is now remarkably simple. Customers configure a single "transport" resource in Google Cloud and accept it in AWS. This transport is an innovative, managed construct that completely abstracts and provisions the underlying physical interconnects, VLAN attachments, and Cloud Router instances. This profound simplification enables end-to-end connectivity in minutes, transforming multicloud deployment from a days-long engineering project into a simple, rapid configuration task.

Under the hood: a secure and resilient foundation

We co-designed our solution to deliver a secure and resilient foundation for cross-cloud applications, with a simple new service that doesn’t compromise on core enterprise availability tenets.

Privacy and security: All peering relationships are built between link local addresses, facilitating connectivity between IPv4 and IPv6 private address spaces across both environments. All underlying physical connections between Google Cloud and AWS edge routers are MACsec-encrypted, and both providers manage key rotation to meet enterprise security requirements.
Quad-redundancy: To enable connectivity between a Google Cloud and an AWS cloud region, quad-redundant connections are leveraged, ensuring facility redundancy, as well as edge-router redundancy. This design helps protect from multiple simultaneous failure scenarios and provides high resiliency levels for joint customers.
Managed operations are key to enabling integrated solutions. The newly introduced solution not only streamlines the physical and logical builds on behalf of joint customers, it also leverages a robust underlying proactive monitoring system that detects and reacts to failures before customers suffer from their consequences. The system relies on coordinated maintenance to avoid overlaps that may impact end-to-end service availability, and streamlines support operations to address potential issues on behalf of customers.

A variety of multicloud workloads

These new streamlined network connections between Google Cloud and AWS enable application teams to automate network builds for a variety of interesting applications. Consider the following scenarios:

Infrastructure and AI deployments supporting active-active or active-standby disaster recovery strategies. With basic connectivity between two peer services — e.g., agentic AI applications or database replicas — applications can synchronize state across the cloud boundary as if they are co-located, supporting maximum application resilience and operational consistency.
AWS customers issuing inbound requests into Google Cloud to allow a service running in AWS to securely and privately access a Google Cloud API. Examples include custom applications running on Compute Engine or a critical data warehouse hosted in BigQuery that bypasses the public internet for enhanced security and performance.
Google Cloud customers issuing outbound requests towards AWS, where a data pipeline orchestrating in Google Cloud can privately pull large datasets from an AWS datastore like S3 or an RDS instance.

Build applications across Google Cloud and AWS today

Regardless of your use case, if your organization would benefit from simple, secure, and robust on-demand connectivity between your Google Cloud and AWS environments, we invite you to start building your applications across clouds and let us manage your network connectivity infrastructure for you.

This collaboration is not restricted to Google Cloud and AWS. We invite other cloud and service providers to offer their customers this streamlined private peering capability with Google Cloud. To learn more, check out the open specification, and contact us at cross-cloud@google.com. We are truly excited to grow this ecosystem for the benefit of our joint customers.

Conquering IP address scarcity: A deep dive into Google Cloud's private NAT

Tue, 18 Nov 2025 17:00:00 +0000

Running AI workloads in a hybrid fashion — in your data center and in the cloud — requires sophisticated, global networks that unify cloud and on-premises resources. While Google’s Cloud WAN provides the necessary unified network fabric to connect VPCs, data centers, and specialized hardware, this very interconnectedness exposes a critical, foundational challenge: IP address scarcity and overlapping subnets. As enterprises unify their private and cloud environments, manually resolving these pervasive address conflicts can be a big operational burden.

Resolving IPv4 address conflicts has been a longstanding challenge in networking. And now, with a growing number of IP-intensive workloads and applications, customers face the crucial question of how to ensure sufficient IP addresses for their deployments.

Google Cloud offers various solutions to address private IP address challenges and facilitate communication between non-routable networks, including Private Service Connect (PSC), IPv6 addressing, and network address translation (NAT) appliances. In this post, we focus on private NAT, a feature of the Cloud NAT service. This managed service simplifies private-to-private communication, allowing networks with overlapping IP spaces to connect without complex routing or managing proprietary NAT infrastructure.

Getting to know private NAT

Private NAT allows your Google Cloud resources to connect to other VPC networks or to on-premises networks with overlapping and/or non-routable subnets, without requiring you to manage any virtual machines or appliances.

Here are some of the key benefits of private NAT:

A managed service: As a fully managed service, private NAT minimizes the operational burden of managing and scaling your own NAT gateways. Google Cloud handles the underlying infrastructure, so you can focus on your applications.
Simplified management: Private NAT simplifies network architecture by providing a centralized and straightforward way to manage private-to-private communication — across workloads and traffic paths.
High availability: Being a distributed service, private NAT offers high availability, VM-to-VM line-rate performance, and resiliency, all without having to over-provision costly, redundant infrastructure.
Scalability: Private NAT is designed to scale automatically with your needs, supporting a large number of NAT IP addresses and concurrent connections.

Figure: Cloud NAT options

Common use cases

Private NAT provides critical address translation for the most complex hybrid and multi-VPC networking challenges

Unifying global networks with Network Connectivity Center

For organizations that use Network Connectivity Center to establish a central connectivity hub, private NAT offers the essential mechanism for linking networks that possess overlapping “ non-routable” IP address ranges. This solution facilitates two primary scenarios:

VPC spoke-to-spoke: Facilitates seamless private-to-private communication between distinct VPC networks (spokes) with overlapping subnets.
VPC-to-hybrid-spoke: Enables connectivity between a cloud VPC and an on-premises network (a hybrid spoke) connected via Cloud Interconnect or Cloud VPN. Learn more here.

Figure: Private NAT with Network Connectivity Center

Enabling local hybrid connectivity in shared VPC

Organizations with shared VPC architectures can establish connectivity from non-routable or overlapping network subnets to their local Cloud Interconnects or Cloud VPN tunnels. A single private NAT gateway can manage destination routes for all workloads within the VPC.

“Thanks to private NAT, we effortlessly connected our Orange on-prem data center with the Masmovil GCP environment, even with IP address overlaps after our joint venture. This was crucial for business continuity, as it allowed us to enable communications without altering our existing environment.” – Pedro Sanz Martínez, Head of Cloud Platform Engineering, MasOrange

Figure: Enabling local hybrid connectivity using private NAT

Accommodating Cloud Run and GKE workloads

Dynamic, IP-intensive workloads such as Google Kubernetes Engine (GKE) and Cloud Run often use Non-RFC 1918 ranges such as Class E to solve for IPv4 exhaustion. These workloads often need to access resources in an on-premises network or a partner VPC, so the ability for the on-premises network to accept non-RFC 1918 ranges is critical. In most cases, central network teams do not accept non-RFC 1918 address ranges.

You can solve this by applying a private NAT configuration to the non-RFC 1918 subnet. With private NAT, all egress traffic from your Cloud Run service or GKE workloads is translated, allowing it to securely communicate with the destination network despite being on non-routable subnets. Learn about how private NAT works with different workloads here.

Configuration in action: Example setups

Let's look at how to configure private NAT for one of these use cases using gcloud commands.

Example: connecting to a partner network with overlapping IPs

Scenario: Your production-vpc contains an application subnet (app-subnet-prod, 10.20.0.0/24). You need to connect to a partner's network over Cloud VPN, but the partner also uses the 10.20.0.0/24 range for the resources you need to access.

Solution: Configure a private NAT gateway to translate traffic from app-subnet-prod before it goes over the VPN tunnel.

1. Create a dedicated subnet for NAT IPs. This subnet's range is used for translation and must not overlap with the source or destination.

code_block: <ListValue: [StructValue([('code', 'gcloud compute networks subnets create pnat-subnet-prod \\\r\n --network=production-vpc \\\r\n --range=192.168.1.0/24 \\\r\n --region=us-central1 \\\r\n --purpose=PRIVATE_NAT'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f175aad8610>)])]>

2. Create a Cloud Router

code_block: <ListValue: [StructValue([('code', 'gcloud compute routers create prod-router \\\r\n --network=production-vpc \\\r\n --region=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17545e2910>)])]>

3. Create a private NAT gateway. This configuration specifies that only traffic from app-subnet-prod to local dynamic (match is_hybrid) destinations should be translated using IPs from pnat-subnet-prod subnet.

code_block: <ListValue: [StructValue([('code', "gcloud compute routers nats create pnat-to-partner \\\r\n --router=prod-router \\\r\n --region=us-central1 \\\r\n --type=PRIVATE --region=us-central1 \\\r\n --nat-custom-subnet-ip-ranges=app-subnet-prod:ALL\r\n\r\ngcloud compute routers nats rules create 1 \\\r\n --router=prod-router --region=us-central1 \\\r\n --nat= pnat-to-partner \\\r\n --match='nexthop.is_hybrid' \\\r\n --source-nat-active-ranges= pnat-subnet-prod"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f17545e2370>)])]>

Now, any VM in app-subnet-prod that sends traffic to the partner's overlapping network will have its source IP translated to an address from the 192.168.1.0/24 range, resolving the conflict.

Google Cloud's private NAT elegantly solves the common and complex problem of connecting networks with overlapping IP address spaces. As a fully managed, scalable, and highly available service, it simplifies network architecture, reduces operational overhead, and enables you to build and connect complex hybrid and multi-cloud environments with ease.

Learn more

Ready to get started with private NAT? Check out the official private NAT documentation and tutorials to learn more and start building your own solutions today.

Introducing Dhivaru and two new connectivity hubs

Mon, 17 Nov 2025 15:00:00 +0000

Today, we’re announcing Dhivaru, a new Trans-Indian Ocean subsea cable system that will connect the Maldives, Christmas Island and Oman. This investment will build on the Australia Connect initiative, furthering the reach, reliability, and resilience of digital connectivity across the Indian Ocean.

Reach, reliability and resilience are integral to the success of AI-driven services for our users and customers. Tremendous adoption of groundbreaking services such as Gemini 2.5 Flash Image (aka Nano Banana) and Vertex AI, mean resilient connectivity has never been more important for our users. The speed of AI adoption is also outpacing anyone’s predictions, and Google is investing to meet this long-term demand.

“Dhivaru” is the line that controls the main sail on traditional Maldivian sailing vessels, and signifies the skill, strength, and experience of the early sailors navigating the seas.

In addition to the cable investment, Google will be investing in creating two new connectivity hubs for the region. The Maldives and Christmas Island are naturally positioned for connectivity hubs to help improve digital connectivity for the region, including Africa, the Middle East, South Asia and Oceania.

“Google’s decision to invest in the Maldives is a strong signal of confidence in our country’s stable and open investment environment, and a direct contribution to my vision for a diversified, inclusive, and digitized Maldivian economy. As the world moves rapidly toward an era defined by digital transformation and artificial intelligence, this project reflects how the Maldives is positioning itself at the crossroads of global connectivity — leveraging our strategic geography to create new economic opportunities for our people and to participate meaningfully in the future of the global economy.” - His Excellency the President of Republic of Maldives, Dr. Mohamed Muizzu

“We are delighted to partner with Google on this landmark initiative to establish a new connectivity hub in the Maldives. This project represents a major step forward in strengthening the nation’s digital infrastructure and enabling the next wave of digital transformation. As a leading digital provider, Ooredoo Maldives continues to expand world-class connectivity and digital services nationwide. This progress opens new opportunities for businesses such as tourism, enabling smarter operations, improved customer experiences and greater global reach. We are proud to be powering the next phase of the Digital Maldives." - Ooredoo Maldives CEO and MD, Khalid Al Hamadi

"Dhiraagu is committed to advancing the digital connectivity of the Maldives and empowering our people, communities, and businesses. Over the years, we have made significant investments in building robust subsea cable systems — transforming the digital landscape — connecting the Maldives to the rest of the world and enabling the rollout of high-speed broadband across the nation. We are proud and excited to partner with Google on their expansion of subsea infrastructure and the establishment of a new connectivity hub in Addu City, the southernmost city of the Maldives. This strategic collaboration with one of the world’s largest tech players marks another milestone in strengthening the nation’s presence within the global subsea infrastructure, and further enhances the reliability and resiliency of our digital ecosystem." - Ismail Rasheed, CEO & MD, DHIRAAGU

Connectivity hubs for the Indian Ocean region

Connectivity hubs are strategic investments designed to future-proof regional connectivity and accelerate the delivery of next-generation services through three core capabilities: Cable switching, content caching, and colocation.

Cable switching: Delivering seamless resilience

Google carefully selects the locations for our connectivity hubs to minimize the distance data has to travel before it has a chance to ‘switch paths’.. This capability improves resilience, and ensures robust, high-availability connectivity across the region. The hubs also allow automatic re-routing of traffic between multiple cables. If one cable experiences a fault, traffic will automatically select the next best path and continue on its way. This ensures high availability not only for the host country, but minimizes downtime for services and users across the region.

Content caching: Accelerating digital services

Low latency is critical for optimal user experience. One of Google’s objectives is to serve content from as close to our users and customers as possible. By caching — storing copies of the most popular content locally — Google can reduce the latency to retrieve or view this content, improving the quality of services.

Colocation: Fostering a local ecosystem

Connectivity hubs are often in locations where users have limited access to high quality data centers to house their services and IT hardware, such as islands. Although these facilities are not very large as compared to a Google data center, Google understands the benefits of shared infrastructure, and is committed to providing rack space to carriers and local companies.

Energy efficiency

Subsea cables are very energy efficient. As a result, even when supporting multiple cables, content storage and colocation, a Google connectivity hub requires far less power than a typical data center. They are primarily focused on networking and localized storage and not the large demands supporting AI, cloud and other important building blocks of the Internet. Of course, the power required for a connectivity hub can still be a lot for some smaller locations, and where it is, Google is exploring using its power demand to accelerate local investment in sustainable energy generation, consistent with its long history of stimulating renewable energy solutions.

These new connectivity hubs in the Maldives and Christmas Island are ideally situated to deepen the resilience of internet infrastructure in the Indian Ocean Region. The facilities will help power our products, strengthen local economies and bring AI benefits to people and businesses around the world. We look forward to announcing future subsea cables and connectivity hubs and further enhancing the Internet’s reach, reliability, and resilience.

Google Cloud Networking under the hood: How Protective ReRoute increases resilience

Fri, 14 Nov 2025 17:00:00 +0000

Cloud infrastructure reliability is foundational, yet even the most sophisticated global networks can suffer from a critical issue: slow or failed recovery from routing outages. In massive, planetary-scale networks like Google's, router failures or complex, hidden conditions can prevent traditional routing protocols from restoring service quickly, or sometimes at all. These brief but costly outages — what we call slow convergence or convergence failure — critically disrupt real-time applications with low tolerance to packet loss and, most acutely, today's massive, sensitive AI/ML training jobs, where a brief network hiccup can waste millions of dollars in compute time.

To solve this problem, we pioneered Protective ReRoute (PRR), a radical shift that moves the responsibility for rapid failure recovery from the centralized network core to the distributed endpoints themselves. Since putting it into production over five years ago, this host-based mechanism has dramatically increased Google’s network's resilience, proving effective in recovering from up to 84%¹ of inter-data-center outages that would have been caused by slow convergence events. Google Cloud customers with workloads that are sensitive to packet loss can also enable it in their environments — read on to learn more.

The limits of in-network recovery

Traditional routing protocols are essential for network operation, but they are often not fast enough to meet the demands of modern, real-time workloads. When a router or link fails, the network must recalculate all affected routes, which is known as reconvergence. In a network the size of Google's, this process can be complicated by the scale of the topology, leading to delays that range from many seconds to minutes. For distributed AI training jobs with their wide, fan-out communication patterns, even a few seconds of packet loss can lead to application failure and costly restarts. The problem is a matter of scale: as the network grows, the likelihood of these complex failure scenarios increases.

Protective ReRoute: A host-based solution

Protective ReRoute is a simple, effective concept: empower the communicating endpoints (the hosts) to detect a failure and intelligently re-steer traffic to a healthy, parallel path. Instead of waiting for a global network update, PRR capitalizes on the rich path diversity built into our network. The host detects packet loss or high latency on its current path, and then immediately initiates a path change by modifying carefully chosen packet header fields, which tells the network to use an alternate, pre-existing path.

This architecture represents a fundamental shift in network reliability thinking. Traditional networks rely on a combination of parallel and series reliability. Serialization of components tends to reduce the reliability of a system; in a large-diameter network with multiple forwarding stages, reliability degrades as the diameter increases. In other words, every forwarding stage affects the whole system. Even if a network stage is designed with parallel reliability, it creates a serial impact on the overall network while the parallel stage reconverges. By adding PRR at the edges, we treat the network as a highly parallel system of paths that appear as a single stage, where the overall reliability increases as the number of available paths grows exponentially, effectively circumventing the serialization effects of slow network convergence in a large-diameter network. The following diagram contrasts the system reliability model for a PRR-enabled network with that of a traditional network. Traditional network reliability is in inverse proportion to the number of forwarding stages; with PRR the reliability of the same network is in direct proportion to the number of composite paths, which is exponentially proportional to the network diameter.

How Protective ReRoute works

The PRR mechanism has three core functional components:

End-to-end failure detection: Communicating hosts continuously monitor path health. On Linux systems, the standard mechanism uses TCP retransmission timeout (RTO) to signal a potential failure. The time to detect a failure is generally a single-digit multiple of the network's round-trip time (RTT). There are also other methods for end-to-end failure detection that have varying speed and cost.
Packet-header modification at the host: Once a failure is detected, the transmitting host modifies a packet-header field to influence the forwarding path. To achieve this, Google pioneered and contributed the mechanism that modifies the IPv6 flow-label in the Linux kernel (version 4.20+). Crucially, the Google software-defined network (SDN) layer provides protection for IPv4 traffic and non-Linux hosts as well by performing the detection and repathing on the outer headers of the network overlay.
PRR-aware forwarding: Routers and switches in the multipath network respect this header modification and forward the packet onto a different, available path that bypasses the failed component.

Proof of impact

PRR is not theoretical; it is a continuously deployed, 24x7 system that protects production traffic worldwide. Its impact is compelling: PRR has been shown to reduce network downtime caused by slow convergence and convergence failures by up to the above-mentioned 84%. This means that up to 8 out of every 10 network outages that would have been caused by a router failure or slow network-level recovery are now avoided by the host. Furthermore, host-initiated recovery is extremely fast, often resolving the problem in a single-digit multiple of the RTT, which is vastly faster than traditional network reconvergence times.

Key use cases for ultra-reliable networking

The need for PRR is growing, driven by modern application requirements:

AI/ML training and inference: Large-scale workloads, particularly those distributed across many accelerators (GPUs/TPUs), are uniquely sensitive to network reliability. PRR provides the ultra-reliable data distribution necessary to keep these high-value compute jobs running without disruption.
Data integrity and storage: Significant numbers of dropped packets can result in data corruption and data loss, not just reduced throughput. By reducing the outage window, PRR improves application performance and helps guarantee data integrity.
Real-time applications: Applications like gaming and services like video conferencing and voice calls are intolerant of even brief connectivity outages. PRR reduces the recovery time for network failures to meet these strict real-time requirements.
Frequent short-lived connections: Applications that rely on a large number of very frequent short-lived connections can fail when the network is unavailable for even a short time. By reducing the expected outage window, PRR helps these applications reliably complete their required connections.

Activating Protective ReRoute for your applications

The architectural shift to host-based reliability is an accessible technology for Google Cloud customers. The core mechanism is open and part of the mainline Linux kernel (version 4.20 and later).

You can benefit from PRR in two primary ways:

Hypervisor mode: PRR automatically protects traffic running across Google data centers without requiring any guest OS changes. Hypervisor mode provides recovery in the single digit seconds for traffic of moderate fanout in specific areas of the network.
Guest mode: For critical, performance-sensitive applications with high fan-out and in any segment of the network, you can opt into guest-mode PRR, which enables the fastest possible recovery time and greatest control. This is the optimal setting for demanding mission-critical applications, AI/ML jobs, and other latency-sensitive services.

To activate guest-mode PRR for critical applications follow the guidance in the documentation and be ready to ensure the following:

Your VM runs a modern Linux kernel (4.20+).
Your applications use TCP.
The application traffic uses IPv6. For IPv4 protection, the application needs to use the gVNIC driver.

Get started

The availability of Protective ReRoute has profound implications for a variety of Google and Google Cloud users.

For cloud customers with critical workloads: Evaluate and enable guest-mode PRR for applications that are sensitive to packet loss and that require the fastest recovery time, such as large-scale AI/ML jobs or real-time services.
For network architects: Re-evaluate your network reliability architectures. Consider the benefits of designing for rich path diversity and empowering endpoints to intelligently route around failures, shifting your model from series to parallel reliability.
For the open-source community: Recognize the power of host-level networking innovations. Contribute to and advocate for similar reliability features across all major operating systems to create a more resilient internet for everyone.

^{1. https://dl.acm.org/doi/10.1145/3603269.3604867}

How Ericsson achieves data integrity and superior governance with Dataplex

Fri, 07 Nov 2025 17:00:00 +0000

Data is the engine of modern telecommunications. For Ericsson's Managed Services, which operates a global network of more than 710,000 sites, harnessing this data is not just an advantage, it's essential for business growth and leadership. To power the future of its autonomous network operations and deliver on its strategic priorities, Ericsson has been on a transformative data journey with governance at the center of its strategy.

Ericsson moved from foundational practices to a sophisticated, business-enabling data governance framework using Google Cloud’s Dataplex Universal Catalog, turning data from a simple resource into a strategic asset.

From a new operating model to a new data mindset

Ericsson’s journey began in 2019 with the launch of the Ericsson Operations Engine (EOE), a groundbreaking, AI-powered operating model for managing complex, multi-vendor telecom networks. The EOE made one thing clear: to succeed, data had to be at the core of everything.

This realization led Ericsson to develop its first enterprise data strategy, which established the core principles for how data is collected, managed and governed. However, building a strategy is one thing — operationalizing it at scale is another.

To move beyond theory to address real-world challenges, Ericsson needed to:

Build trust: Provide discoverable, clean, reliable, and well-understood data to the teams deploying analytics, AI, and automation.
Balance defense and offense: Ensure compliance with contracts and regulations (defensive governance) while empowering teams to innovate and create value from data (offensive governance).
Ensure data integrity: Ericsson users see data integrity as the core principle for effective data management. Data quality, which is essential for reliable, trustworthy data throughout its lifecycle, is a key quality indicator (KQI) for measuring effectiveness. Any quality deviations must be managed like a high-priority incident with clear Service Level Agreements (SLA) for restoration and resolution.

To realize this vision, Ericsson sought a platform that could match its ambition for global-scale governance and innovation — and Dataplex Universal Catalog emerged as the ideal choice.

Ericsson made its selection based on four key criteria.

First, its capabilities aligned perfectly with Ericsson’s requirements for cloud-native transformation, business principles, and a long-term governance vision, underpinned by Ericsson’s strategic partnership with Google Cloud. Second, from a technical standpoint, Dataplex provided a tightly integrated, end-to-end ecosystem as a native Google Cloud solution, translating to faster time-to-market for use cases and reduced integration overhead.

Third, the platform offered a practical operating model that enabled quick learning, adaptation, and self-sufficiency, supporting an agile approach where Ericsson could fail fast and iterate. Finally, as an existing Google Cloud customer, Dataplex presented a clear and manageable Total Cost of Ownership (TCO), serving as a natural extension of Ericsson’s existing environment and providing a clear, manageable cost profile for both storage and compute extension with governance capabilities.

Putting governance into practice: Key capabilities in action

With Dataplex Universal Catalog as the governance foundation, Ericsson began implementing the core pillars of its governance program, moving from manual processes to an automated, intelligent data fabric.

More specifically, Ericsson established a unified business vocabulary within Dataplex. This transformative first step eliminated ambiguity and ensured their teams — from data scientists to data analysts — were speaking the same language. These glossaries also captured tribal knowledge and became the foundation for creating trusted data products.

In addition, Dataplex's catalog is at the heart of the data governance solution, making data discovery simple and intuitive for authorized users. Ericsson uses its tagging capabilities to enrich the data assets with critical metadata, including data classification, ownership, retention policies, and sensitivity labels. Dataplex’s ability to automatically visualize data lineage, down to the column level, is another game-changer. Different data personas can instantly understand a dataset's origin and its downstream impact, dramatically increasing trust and reducing investigation time. Furthermore, trustworthy AI models are built on high-quality data. For proactive data quality, Ericsson uses Dataplex to run automated quality checks and profiles on its data pipelines. When a quality rule is breached, an alert is automatically triggered, creating an incident in its service management platform to ensure data issues are treated with the urgency they deserve.

These capabilities are all underpinned by Ericsson's Data Operating Model (DOM), a framework that defines the policies, people, processes, and technology needed to translate its data strategy into tangible value, comprising several facets when working with data.

Enterprise data architecture: Managing data flow, enterprise data modeling and best practices for data collection till consumption
Technology and tools: Business glossary, master, reference and metadata management, data modeling, and data quality management
Roles and responsibilities: Roles to manage and govern data (i.e., end-to-end data lifecycle and stewardship)
Data and model assurance: Data pipelines monitoring, data observability, and data quality monitoring
Governance: Manage data compliance, risk and security management, managing operational level agreement, objective and key results, and audit management
Processes: Data governance, data quality, data management, and data consent related processes

Looking ahead: The future is integrated and intelligent

As a global technology leader, Ericsson is committed to shaping the future of AI-powered data governance. Technology, especially in the AI space, is evolving at a breathtaking pace and both the data and AI governance practices must keep up.

These developments are guiding Ericsson’s future priorities, which include bridging the gap between data and AI governance, especially with the rise of generative and agentic AI. These plans include evaluating using generative AI capabilities in BigQuery and Dataplex to simplify governance and pursuing solutions that ensure transparency, explainability, fairness and manage risk in the deployment of AI models.

In addition to harnessing the power of AI for at-scale governance, Ericsson will also include usage of governance workflows, glossary-driven data quality policies, at-scale assignment of terms to assets, bulk import and export of glossaries, AI-powered glossary recommendations, and data quality re-usability functionalities. Ericsson is also aligning its architecture with data fabric and data mesh principles, empowering teams with self-service access to high-quality, trusted data products.Finally, Ericsson will be assessing the use of more granular, policy-based access controls to complement existing role-based access, further strengthening its data security, protection and privacy.

For any organization embarking on a similar path, Ericsson’s experience offers several key lessons:

Governance is a value enabler, not a blocker: A modern data governance program is focused on business enablement first, driving value and innovation, to complement policies, rules and risk management.
It's a journey, not a destination: Be prepared to fail fast, learn, and adapt. The landscape is constantly changing at breakneck speed.
Focus on business outcomes, not tools: Technology is a critical enabler, but the conversation is about the business value you’re creating. Simplify the story, speak the language of the business, and unpack the hype.
Culture is everything: For governance to be effective, it’s the responsibility of everyone. This requires strong leadership, sponsorship, and a "data-first" mindset embedded throughout the organization.

By partnering with Google Cloud and tapping into the power of Dataplex Universal Catalog, Ericsson is building a data foundation that is not only compliant and secure but agile and intelligent — ready to power the next generation of autonomous networks.

7 ways networking powers your AI workloads on Google Cloud

Tue, 04 Nov 2025 17:00:00 +0000

When we talk about artificial intelligence (AI), we often focus on the models, the powerful TPUs and GPUs, and the massive datasets. But behind the scenes, there's an unsung hero making it all possible: networking. While it's often abstracted away, networking is the crucial connective tissue that enables your AI workloads to function efficiently, securely, and at scale.

In this post, we explore seven key ways networking interacts with your AI workloads on Google Cloud, from accessing public APIs to enabling next-generation, AI-driven network operations.

#1 - Securely accessing AI APIs

Many of the powerful AI models available today, like Gemini on Vertex AI, are accessed via public APIs. When you make a call to an endpoint like *-aiplatform.googleapis.com, you're dependent on a reliable network connection. To gain access these endpoints require proper authentication. This ensures that only authorized users and applications can access these powerful models, helping to safeguard your data and your AI investments. You can also access these endpoints privately, which we will see in more detail in point # 5.

#2 - Exposing models for inference

Once you've trained or tuned your model, you need to make it available for inference. In addition to managed offerings in Google Cloud, you also have the flexibility to deploy your models on infrastructure you control, using specialized VM families with powerful GPUs. For example, you can deploy your model on Google Kubernetes Engine (GKE) and use the GKE Inference Gateway, Cloud Load Balancing, or a ClusterIP to expose it for private or public inference. These networking components act as the entry point for your applications, allowing them to interact with your model deployments seamlessly and reliably.

#3 - High-speed GPU-to-GPU communication

AI workloads, especially training, involve moving massive amounts of data between GPUs. Traditional networking, which relies on CPU copy operations, can create bottlenecks. This is where protocols like Remote Direct Memory Access (RDMA) come in. RDMA bypasses the CPU, allowing for direct memory-to-memory communication between GPUs.

To support this, the underlying network must be lossless and high-performance. Google has built out a non-blocking rail-aligned network topology in its data center architecture to support RDMA communication and node scaling. Several high-performance GPU VM families support RDMA over Converged Ethernet (RoCEv2), providing the speed and efficiency needed for demanding AI workloads.

#4 - Data ingestion and storage connectivity

Your AI models are only as good as the data they're trained on. This data needs to be stored, accessed, and retrieved efficiently. Google Cloud offers a variety of storage options, for example Google Cloud Storage, Hyperdisk ML and Managed Lustre. Networking is what connects your compute resources to your data. Whether you're accessing data directly or over the network, having a high-throughput, low-latency connection to your storage is essential for keeping your AI pipeline running smoothly.

#5 - Private connectivity to AI workloads

Security is paramount, and you often need to ensure that your AI workloads are not exposed to the public internet. Google Cloud provides several ways to achieve private communication to both managed Vertex AI services and your own DIY AI deployments. These include:

VPC Service Controls: Creates a service perimeter to prevent data exfiltration.
Private Service Connect: Allows you to access Google APIs and managed services privately from your VPC. You can use PSC endpoints to connect to your own services or Google services.
Cloud DNS: Private DNS zones can be used to resolve internal IP addresses for your AI services.

#6 - Bridging the gap with hybrid cloud connections

Many enterprises have a hybrid cloud strategy, with sensitive data remaining on-premises. The Cross-Cloud Network allows you to architect your network to provide any-to-any connectivity. With design cases covering distributed applications, Global front end, and Cloud WAN, you can build your architecture securely from on-premises, other clouds or other VPCs to connect to your AI workloads. This hybrid connectivity allows you to leverage the scalability of Google Cloud's AI services while keeping your data secured.

#7 - The Future: AI-driven network operations

The relationship between AI and networking is becoming a two-way street. With Gemini for Google Cloud, network engineers can now use natural language to design, optimize, and troubleshoot their network architectures. This is the first step towards what we call "agentic networking," where autonomous AI agents can proactively detect, diagnose, and even mitigate network issues. This transforms network engineering from a reactive discipline to a predictive and proactive one, ensuring your network is always optimized for your AI workloads.

Learn more

To learn more about networking and AI on Google Cloud dive deeper with the following:

Documentation: AI Hypercomputer
Codelabs: Gemini CLI on GCE with a Private Service Connect endpoint
White paper: Leveling up with Autonomous Network Operations.

Want to ask a question, find out more or share a thought? Please connect with me on Linkedin.