Cloud has fueled business growth like no other technology in the past. Opening a new data center or starting a new business on the web is easier than ever before. While that has helped companies, it has also strengthened competition. User experience is of paramount importance. Businesses are going global, and they are using the internet as the growth engine. The ability of companies to serve their users better determines whether or not they are successful. One of the critical factors is to be able to serve users data from where they are. If the business has to serve a user from the APAC region from a service running in NA, it can lead to poor user experience. As we say, the world has become smaller. Even if a business is mostly regional, for example, a bank in the US, it cannot assume that its users will access the service/application from the US. A business traveler might require banking services from India, and the business/bank has to be able to serve that user with a reasonably good user experience.
To enable those business use cases, OCI released a new service as part of its DNS offering, Traffic Management Steering Policies. It allows businesses to configure policies to serve intelligent responses to DNS queries.
Depending on the user's geolocation or depending on load profile in a given region or depending on the IP prefix of the source IP address, return different answers to the DNS query for the application.
It is a framework to define traffic management behavior for the given zones. It contains rules that help serve DNS requests. There are five traffic steering policies supported as below. The response, however, is driven by the rules defined for the policy.
You can attach a steering policy to the DNS zone. An attachment of a steering policy to a zone occludes all records at its domain for the application sub-domain. You typically attach a policy to a zone for a specific sub-domain. A domain can have only one attachment for every sub-domain. For example, you cannot have two traffic steering policies for the application subdomain in the example.com DNS domain.
Rules are the guidelines for steering policy. For example, in a load balancer steering policy, should the traffic be spread equally between available servers, or only 10% of the traffic should be sent to a server is determined by the rules defined in the policy.
Answers contain the DNS record data and metadata to be processed in a steering policy for a given condition.
The health check is an essential aspect of traffic steering policy. For example, for a failover traffic steering policy, when should DNS failover to secondary instance happen. Failover for US users should occur if the service is not accessible only from the US vantage point. If the service, for example, is not available from the APAC region, that should not trigger a failover to the DR site or region.
Let's get to the part that you all are waiting for. How and where do I use traffic steering policies? Below are some examples of traffic steering policy.
The reason I combine cloud migration and canary testing in one topic is that the implementation is similar. In both cases, you want to either test a new feature/functionality added in the product/application or test a new data center/site to run the application. You deploy the application in a new data center or add a feature in an application running in an existing data center and start routing 10% of total traffic to the new site. You take user feedback, and if the feedback is positive, if there are no issues, then you start routing more traffic. You can use a traffic steering policy to implement the use case.
If there are numerous Active/Active data centers/regions, you can use steering policy to route a percentage of the traffic to a specific region. Or you can route traffic to the primary site and in case the primary site is not available, then route traffic to the secondary site. You can use health checks to determine if the site is available/healthy.
Conditional steering can be based on the originating enterprise, mobile operator, or other communications provider. Preferred ASNs can be directed to free resources while all other traffic can be directed to paid resources. Similar to ASN, you can use IP prefix or IP range as well to route traffic a specific resource. IP prefix can be used to segregate Internal vs. External users and route traffic accordingly to either the Internal portal or an external portal.
The use case that I want to focus on is where you create layers of steering policies. Create steering policies for every region that implements DR or HA between data centers in a given region and a steering policy to steer users from a region to service instance in that respective region.
You create a region-specific steering policy to implement HA or DR between data centers in the region. In my example, I will create steering policies for the US and the EU regions. The difference between regional policies and global policy is, the regional policy creates DNS A record. In contrast, the global policy will use A records created by regional policy and will create CNAME records. I have highlighted that in regional and global policy screenshots.
Global steering policy is needed to route users from a region to service instance in that respective region.
Traffic steering policy is a vital feature for building resilient applications and services. But wait, don't forget security. Remember, I talked about the Web Application Firewall (WAF). Make sure you use WAF between regional steering policy and Load Balancer. With region specific steering policies, you can enforce different security policies for different regions using WAF in every region. I know, I know, this is already too much to cover in one blog. I will talk more about using steering policy with WAF in my next blog. Until then, Good luck using traffic steering policies.