Cloud DNS Weighted Routing and Global External HTTP(S) Load Balancer: Can DNS-Level Traffic Shifting Guarantee a Zero-Downtime Cutover?
0 reputation · 29 Jun 2020, 15:19 UTC
I am planning a zero-downtime migration of a small web application from an on-premises origin to Google Cloud (Cloud Run behind a Global External HTTP(S) Load Balancer). The intended design keeps the legacy origin serving traffic while the GCP backend is health-checked, then shifts traffic gradually rather than flipping a single record.
Two supported mechanisms appear to overlap at this boundary: the load balancer's backend services with health checks and session affinity, and Cloud DNS weighted routing policies over the same hostname. My uncertainty is where the cutover control should live. DNS weight changes are subject to resolver caching and TTL behavior outside my control, while load balancer backend changes converge faster but require both environments to sit behind the same frontend.
Assume a recent Cloud DNS and load balancer feature set; I have not yet validated propagation behavior across public resolvers.
- Is a Cloud DNS weighted routing policy between two A/AAAA records a reliable mechanism for incremental cutover, given recursive resolver TTL caching?
- Or should both origins be modeled as backends on one Global External HTTP(S) Load Balancer so traffic shifting converges independently of DNS?
- Which option preserves session affinity most predictably during the shift?