Cloud DNS Weighted Routing and Global External HTTP(S) Load Balancer: Can DNS-Level Traffic Shifting Guarantee a Zero-Downtime Cutover?

No, a Cloud DNS weighted routing policy cannot guarantee a zero-downtime cutover because it is subject to recursive resolver caching and client-side TTL behavior outside of your control. While you can set a low TTL in Cloud DNS, many public resolvers ignore low TTLs or cache records longer than specified, meaning traffic will shift probabilistically over minutes or hours rather than instantaneously.

Comparison of Traffic Shifting Mechanisms

Cloud DNS Weighted Routing

DNS-level shifting operates at the authoritative layer. When you change weights, you are changing the answer provided to the recursive resolver. However, the convergence is non-deterministic. Because the client communicates with a resolver (and not your DNS server directly), the shift only occurs once the resolver's cache expires. This makes it unsuitable for precise, zero-downtime migrations where you need a tight feedback loop.

Global External HTTP(S) Load Balancer (GCLB)

Modeling both origins as backends behind a single GCLB allows for deterministic traffic splitting. By using a URL map with weighted backend services, traffic is shifted at the Google frontend (GFE) layer. Changes typically propagate across the global fleet in 10–30 seconds, independent of DNS caching.

Implementation Strategy

To achieve a zero-downtime cutover, use the Load Balancer approach. This requires your on-premises origin to be reachable by the GCLB (via Cloud VPN, Interconnect, or an Internet Network Endpoint Group if the origin has a public IP).

1. Configure Backends: Create a Serverless NEG for Cloud Run and an Internet NEG (or Zonal NEG via VPN) for the on-premises origin.
2. Establish Health Checks: Ensure the on-premises origin passes GCLB health checks before any traffic is shifted.
3. Define Traffic Split: Use the URL map to distribute traffic between the two backend services (e.g., 90% on-premises, 10% Cloud Run).
4. Incremental Shift: Gradually increase the weight of the Cloud Run backend while monitoring error rates in Cloud Logging.

Session Affinity Predictability

The Load Balancer preserves session affinity most predictably. Because the GCLB terminates TLS and manages the session, it can use generated cookies (GCLB) to ensure a client stays with the same backend regardless of weight changes. DNS-level affinity is unreliable during a shift because a resolver may rotate the returned IP for a client mid-session, forcing a connection reset or session loss.

Verification Command

To verify the traffic split and affinity during the migration, use curl to inspect the load balancer's session cookie:

curl -v -H "Host: yourdomain.com" https://<LB_IP> | grep -i "set-cookie: GCLB="

Required Diagnostic Detail: Does your on-premises origin have a public IP reachable by Google's health-check ranges, or is it restricted to private connectivity (VPN/Interconnect)? This determines whether you use an Internet NEG or a Zonal NEG.