BigQuery Fluid Scaling GA and Network Connectivity Center Partner Cross‑Cloud Interconnect for AWS (Public Preview)

Google Cloud's recent release notes emphasize incremental, operationally meaningful changes that affect platform engineering decisions. Two items matter most for multi-cloud platform teams: BigQuery's fluid scaling reaching GA with per-second autoscaling billing, and Network Connectivity Center (NCC) adding Partner Cross‑Cloud Interconnect for AWS in public preview. A set of connector and runtime updates (Cloud Storage Connector 3.1.13, BigQuery Connector 0.44.1‑Preview, JupyterLab 4.5.7, Apache Zookeeper 3.9.5, etc.) also tighten integration and security for Vertex AI and GKE workloads.

BigQuery Fluid Scaling GA: per-second autoscaling billing and operational implications

What changed

• BigQuery fluid scaling is GA and supports per-second billing for autoscaling reservations. This lets reservations scale up and down with finer billing granularity, reducing cost increments for short-lived capacity usage.

Why it matters

• For spiky or multi-tenant analytic workloads (ad‑hoc queries, variable ETL windows, tenant isolation patterns), per‑second billing reduces billing granularity and can lower TCO for transient spikes.
• Capacity planning shifts from coarse overprovisioning toward tightened autoscaler policies, cooldown tuning, and control‑loop design.

Operational impacts and realities

• Billing: Expect the biggest savings on short-lived spikes; sustained load will continue to be charged based on aggregate compute consumed.
• Reservations & autoscaling: Review reservation automation and autoscaler settings. Scale-in cooldowns, minimum reserved slots, and scale‑out rate limits materially affect cost and query latency trade‑offs.
• Cost modeling: Update chargeback/showback and telemetry to account for per‑second metrics and amortize sub‑minute usage across projects using shared reservations.
• Regional availability: Features can roll out regionally. Verify GA coverage for the regions you operate before adopting in production.

Recommended steps for platform teams

• Run a 2–4 week parallel accounting window in sandbox to compare old vs. new billing signals and quantify delta.
• Tune autoscaler policies: shorten or lengthen scale‑in cooldowns depending on your burst profile; set appropriate minimums to avoid thrashing.
• Expose reservation sizing and autoscale parameters in Terraform modules and internal tooling so teams can adjust without infra changes.

If you want a deeper discussion of implications for BigQuery capacity and Vertex AI inference, see: /article/bigquery-fluid-scaling-ga-vertex-ai-model-garden-updates-june-2026/.

Network Connectivity Center: Partner Cross‑Cloud Interconnect for AWS (Public Preview)

What changed

• NCC now supports Partner Cross‑Cloud Interconnect for AWS in public preview. This provides a partner‑mediated managed path to connect GCP VPCs and workloads (GKE, Cloud Run) to AWS environments with centralized routing via NCC and Cloud WAN.

Technical capabilities

• Managed routing across a partner fabric into AWS, with integration into NCC/Cloud WAN for centralized route propagation and telemetry.
• Partner‑managed transport that offloads handoffs, provisioning, and some operational responsibilities to vetted partners instead of DIY VPN/peering.
• Attachments and service‑chaining options (Cloud Router, Cloud VPN, partner links) inside NCC hubs and spokes for centralized policy.

Preview constraints and caveats

• Partner variability: Throughput, failover behavior, and BGP characteristics differ by partner and geography—test partner SLAs and behavior.
• Routing semantics: NCC uses Cloud Router and propagated routes; if you rely on custom BGP attributes or nonstandard policy‑based routing, validate end‑to‑end fidelity.
• Security: Transport and routing are handled by the partner; IAM, VPC firewall rules, and application‑layer encryption remain your responsibility.
• Availability and throughput tiers depend on partner and region.

Architectural patterns enabled

• Centralized multi‑cloud transit using NCC + Cloud WAN and partner interconnect as the transit fabric.
• Lower‑latency, deterministic paths for cross‑cloud service calls without managing many per‑VPC peering relationships.
• Consolidated management‑plane or bastion access patterns that favor centralized routing and monitoring over ad‑hoc VPNs.

Operational checklist before production

• Confirm partner list, SLAs, and regional availability. Run partner‑specific throughput and failover tests.
• Validate BGP advertisements, ASN planning, prefix filters, and route‑advertisement policies to avoid leaks.
• Model NCC hubs, spokes, Cloud Routers, and partner attachments in Terraform and codify failover behavior.
• Instrument e2e tests for latency, packet loss, and route convergence and include them in runbooks.

Connector, runtime, and Vertex AI updates: security and runtime implications

What changed

• Several connectors and runtime components received minor version upgrades: Cloud Storage Connector 3.1.13, BigQuery Connector 0.44.1‑Preview, JupyterLab 4.5.7, Apache Zookeeper 3.9.5, and assorted Vertex AI Model Garden updates.

Impacts

• Vertex AI model availability: New models may change inference options and hardware requirements; consult the Model Garden release notes for per‑model constraints (GPU, TPU, or CPU SKUs and autoscaling behavior).
• Connectors: Upgrades commonly include paging improvements, IAM condition support, bug fixes, and changes to retry/backoff semantics. Test client behavior in pipelines before rolling to prod.
• Export and encryption: New export capabilities include CMEK (Cloud KMS) options and finer extraction controls tied to IAM.

Security & governance

• CMEK: If you adopt CMEK for exports, ensure key rotation, IAM permissions, and KMS audit logging are configured. Loss of KMS permissions will halt exports.
• Least privilege: Map service accounts used by connectors to narrow roles; avoid broad default permissions.
• CVE management: Treat runtime upgrades (e.g., Zookeeper) as security patches—test in staging and prioritize where CVEs affect your stack.

Testing recommendations

• Upgrade connectors in staging with representative traffic and validate throughput, error semantics, and retry behavior.
• For Vertex AI, run inference performance and cold‑start tests across intended machine types and tune serving autoscalers.
• For CMEK, run a controlled key‑access removal test to confirm monitoring and recovery procedures.

Recommended immediate actions (30–90 days)

• Audit regional release notes for all affected products and confirm GA/preview scope for your regions.
• Update cost models and internal dashboards to reflect BigQuery per‑second billing; run a parallel accounting window to measure impact.
• If planning to use NCC partner interconnect, formalize partner selection criteria, update Terraform modules, and run interop tests with the AWS network team.
• Create a staged upgrade path for connectors and runtimes and validate IAM scoping and KMS permissions.

Operational controls to implement

• Automated regression tests that exercise BigQuery autoscaling under synthetic bursts.
• End‑to‑end network tests measuring route convergence, latency, and failover for NCC + partner interconnect.
• Alerting on KMS permission anomalies for export pipelines and a recovery playbook for temporary key denials.

Longer‑term considerations (90–180 days)

• Revisit architecture assumptions that relied on minute/hour billing granularity; fluid scaling enables designs that accept transient overprovisioning and tighter autoscaler policies.
• Treat NCC partner interconnect as part of your multi‑cloud transit architecture and consolidate routing policy and monitoring there rather than ad‑hoc peering.
• Maintain a proactive connector lifecycle: subscribe to release notes for connectors, Vertex AI runtimes, and container runtimes and schedule upgrades as part of platform cadence.

Bottom line These release‑note updates are incremental but operationally meaningful. BigQuery fluid scaling GA changes cost granularity for analytics; NCC's partner interconnect for AWS makes managed multi‑cloud routing more practical at scale; and connector/runtime upgrades reduce friction but require staged validation. For platform engineers, the priority is integrating these changes into capacity planning, network design, and CI/CD gates so you can safely capture cost and operational benefits.

Sources

• Google Cloud release notes (all products, last 60 days)
• What’s new in Google Cloud – latest news and announcements hub
• Google Cloud Press Corner – recent press releases