Google's October 2026 release notes include several changes that infrastructure teams can act on now: a time-zone change affecting some Cloud SQL instances, a future Cloud DNS resolution change, new private connectivity defaults, and useful updates to Compute Engine, Cloud Run, storage, and Apigee.

This roundup covers changes published from October 1 through October 31, 2026. Preview features are marked as such; they are opportunities to test, not production defaults. Google's release notes are a rolling feed and can be corrected after publication, so check the linked product documentation before making a change.

Start here: check Cloud SQL time-zone handling

Google warned that, beginning November 1, 2026 at 02:00 local time, some unpatched Cloud SQL for MySQL, PostgreSQL, and SQL Server instances that use local time zones in Alberta, British Columbia, Manitoba, and parts of the Northwest Territories can calculate local times one hour off. Stored timestamp values are not changed. The impact is on applications and database functions that interpret local civil time, such as reports, schedules, or date conversions.

If you operate in those jurisdictions, check this first:

  1. Find instances and application sessions that use the affected local time zones.
  2. Check the instance maintenance version and apply Google's current self-service maintenance where available.
  3. If you cannot perform maintenance in time, review Google's documented database-specific stopgap. For MySQL, this can be a fixed session offset; PostgreSQL can use an anchor time zone; SQL Server requires a matching fixed-offset Windows time zone.
  4. Test scheduling and reporting around the transition. A fixed offset is deliberate: it will not follow future seasonal clock changes.

Use the Cloud SQL MySQL maintenance changelog and the October release notes for the current version thresholds and database-specific instructions. Do not assume that stored timestamps need to be rewritten.

DNS and private connectivity

Cloud DNS will follow CNAME chains across zone boundaries

Starting January 5, 2027, Cloud DNS will follow CNAME chains using the VPC's full name-resolution order. A CNAME returned from a public zone can therefore continue into a private zone or response policy; a private answer can also continue toward public DNS. Names that overlap across public and private namespaces may resolve differently or return an error after the change.

Inventory CNAME targets that cross public/private boundaries, including response policies, forwarding zones, and peering zones. Test each chain from a representative VPC with dig or nslookup, and make matching TTLs consistent across records you control. Also stop using DNS ANY queries as a way to dump a zone: public authoritative zones will return only one matching record for ANY queries after January 5. Use Cloud DNS record-set listing through the console, API, or gcloud dns record-sets list instead.

Cloud SQL private IP now defaults to Private Service Connect in new projects

For new Google Cloud projects, Private Service Connect (PSC) is now the default private IP connectivity option when creating Cloud SQL for MySQL, PostgreSQL, and SQL Server instances. PSC can connect an instance to VPC networks across project or organization boundaries and can provision endpoint and DNS records. Private services access remains available, and you can choose both options where supported.

For a new landing zone, decide which connectivity model you want before provisioning database instances. PSC can simplify cross-project consumers; teams with existing private-services-access automation should explicitly check the selected option and update connectivity, DNS, and firewall runbooks. This default applies to new project setup; it does not convert existing instances by itself. See the Cloud SQL private IP options.

Compute Engine: more resilient APIs and storage choices

Regional views can protect control-plane reads

Compute Engine's regional projectViews and imageViews endpoints are generally available. They let automation query global project and OS image resources through a selected region, isolating those read requests from some global API disruptions.

This is useful for recovery tooling that must still discover projects or images during a control-plane incident. Add regional reads as a resilience path, but keep the existing global workflow until you have tested permissions, endpoint selection, retries, and failover behavior. These are control-plane reads; they do not move the resources themselves.

Pin API versions and inspect partial results

Interface-based versioning for the Compute Engine API is generally available, so clients can pin a date-based API version and adopt API changes on a planned schedule. The 2026-09-01 version also changes aggregatedList behavior: partial results are returned by default when a scope is unreachable. Automation must inspect warnings and unreachable scopes instead of treating a successful response as a complete inventory.

The separate 2026-10-01-preview API version removes the quotas field from several project and region responses. If you are testing that preview version, get quota information through the Cloud Quotas API. Do not build production automation around a preview response shape.

Hyperdisk multi-writer support expands; Z4M is generally available

Multi-writer Hyperdisk support is generally available for C3 bare-metal instances using Hyperdisk Balanced. C4 instances created after May 1, 2026 can share Hyperdisk Balanced, Hyperdisk Extreme, and Hyperdisk Balanced High Availability volumes in multi-writer mode.

This can help clustered applications that need shared block storage, but multi-writer access does not provide application-level coordination or make an ordinary file system safe for concurrent writes. Confirm that the database, cluster stack, and file system support the exact configuration before migrating data. See Google's shared disk guidance.

The storage-optimized Z4M machine family is also generally available. It is designed for storage-heavy systems such as parallel file systems, databases, vector search, and distributed caches, with configurations reaching 168,000 GiB of local Titanium SSD and up to 400 Gbps of network bandwidth. Evaluate it with a representative workload and account for local-disk durability, zone availability, and cost before selecting it for persistent data.

Cloud Run and network operations

  • GPU-enabled Cloud Run jobs (Preview): jobs can run for up to 12 hours. This opens a serverless option for long batch tasks such as offline inference, media processing, or model evaluation. Prototype with checkpointing, retries, GPU quota, supported regions, and cost controls; it is still Preview. See GPU configuration for Cloud Run jobs and long-running GPU job design.
  • Direct VPC ingress for Cloud Run instances (Preview): instances can use ephemeral private IP addresses to communicate with other VPC resources and instances. Test private service communication in a non-production service first, and verify routing and firewall behavior before relying on it. See Direct VPC for Cloud Run.
  • Cloud Run scaling controls (GA): custom target CPU or concurrency utilization is generally available. Load-test target values against latency and instance cost rather than copying a default from another service. The October notes also mark Cloud Run budget spend caps as GA for eligible workloads; review the pause behavior before using a cap on a service with strict availability needs.
  • GKE Network Services Monitoring (Preview): teams using GKE ambient networking can inspect service communication paths and network metrics. This is most useful when troubleshooting service-to-service connectivity across a mesh; validate its coverage and operational workflow before making it a production alert dependency. See Network Services Monitoring.
  • Cloud Load Balancing URL maps (GA): RE2 regular-expression matchers are available for host, path, HTTP header, and query-parameter route rules on supported Application Load Balancers. This can replace long sets of exact-match routes, but test overlapping patterns and precedence before deployment.

Apigee: review patch releases and MCP backend assumptions

Apigee hybrid v1.16.13 is the recommended patch in the v1.16 line. Do not use v1.16.12 because of a regression in apigee-connect-agent. Version 1.16.13 fixes the proxy handling issue and includes security fixes across runtime components. The release notes say Helm-based patch upgrades normally update the integrated container images automatically; follow the Apigee hybrid upgrade guide and your environment's normal canary and rollback process.

For Apigee X MCP proxies, a change published October 26 sends OpenAPI arguments declared in: header to HTTP headers and in: cookie to the Cookie header instead of appending them to the query string. Existing MCP proxy revisions keep the old behavior until regenerated. Check backends that read these values from the query string, declare parameters in the correct OpenAPI location, and deploy a regenerated proxy revision in a test environment before switching clients.

Cloud Storage: review encryption-policy findings

Storage Intelligence advisor now surfaces Preview security and compliance findings for objects that violate default customer-managed encryption-key policies or enforced encryption rules. Teams can use the findings to find affected objects and plan re-encryption.

Start with a report-only review: verify the bucket policy, key access, object scope, and expected application impact before running a re-encryption operation. This is especially useful when rolling out CMEK requirements across older buckets, where a policy may have been enabled after objects were uploaded.

A short operator checklist

  1. Check affected Cloud SQL instances and Canadian local-time calculations around the November 1 transition.
  2. Audit Cloud DNS CNAME chains and scripts using ANY before January 5, 2027.
  3. Update Compute Engine inventory clients to handle date-based API versions, partial results, and the Cloud Quotas API.
  4. Treat Cloud Run GPU jobs, Direct VPC ingress, GKE Network Services Monitoring, and Storage Intelligence findings as previews until their limits and operational behavior fit your workload.
  5. Review Apigee hybrid v1.16.13 and MCP parameter-location assumptions in a test environment.

Sources