Simplify traffic steering with Cloud DNS routing policies

We are pleased to announce the Preview launch of Cloud DNS routing policies. With this feature, you can define custom ways to steer private and Internet traffic using DNS. There are many instances where traffic needs to be split, either because different vendors are being used or due to geographic preferences or because different versions of the product are being tested and rolled out. Utilizing DNS as a means of serving different IP addresses is a well understood design pattern and it is now available on Cloud DNS. 

Cloud DNS will support two routing policies in this Preview launch - weighted round robin and geo-location. In the weighted round robin policy, you can specify different weights for a set of IP addresses and Cloud DNS will serve the right IP based on its weight. The weight is dynamically computed for each request and you can control the update frequency by using the Cloud DNS APIs. 

The geo-location policy allows you to map source geographies with a target list of IP addresses. This allows you to deploy regional instances of your workloads and utilize DNS to direct traffic to the right instances based on where the traffic originates. At launch, we will support Google Cloud regions as the geographic boundaries and finer-grained boundaries like country and state will be made available in future releases. Each weight or geo bucket can contain multiple IP addresses and Cloud DNS will return the entire set as-is. 

Cloud DNS routing policies can be used in conjunction with our internal load balancers to create regional pools of workloads. One example can be to create two regionally isolated pools of workloads for your internal services and load-balance between them. You can put your workloads behind anInternal HTTP(S) Load Balancing in us-east and duplicate the setup in us-west and utilize the geo-location routing policy to direct traffic in the US east coast to the us-east Internal HTTP(S) Load Balancing and in the US west coast to the us-west Internal HTTP(S) Load Balancing.  Traffic originating from other areas would preferentially choose us-east or us-west depending on how close they are to those regions. 

This same principle can be utilized with the weighted round robin policy to set up manual active-passive configurations (manual because the first iteration does not support health checking and automatic failovers). Set up the us-west Internal HTTP(S) Load Balancing with 100% weight and the us-east Internal HTTP(S) Load Balancing with 0%. When failover is desired, use gCloud to change the us-east weight to 100% and the us-west weight to 0%. 

Google Cloud’s journey with DNS-based routing policies is just starting. We have an exciting roadmap that supports additional policies and health checking for internal and Internet endpoints in 2022.