Using new traffic control features in External HTTP(S) load balancer

At the heart of every HTTP(S) load balancer is an enduring URL map that reliably directs each incoming request to its appropriate destination. In April, we announced two new actions supported by the URL map: redirects and rewrites. With URL redirects the load balancer redirects incoming requests from one URL to another. With rewrites, you can present external users with different URLs than those used by the backend service. In addition, we added more matching criteria that lets you match on HTTP headers and URL query parameters.

These traffic control features will allow you to shift more of your routing decisions to the load balancer, rather than relying on homegrown solutions. And since we announced the features, we’ve seen a few common use cases emerge. Read on to learn how Google Cloud customers are using these features in production, to inspire some use cases of your own. 

HIPAA compliance with HTTP-to-HTTPS redirect

The Health Insurance Portability and Accountability Act of 1996 (HIPAA) demands that personal health information (PHI) be encrypted in transit. For web sites, this all but requires that you use HTTPS to protect web requests and responses. Unencrypted HTTP requests should result in a response to the browser telling the browser to re-send the request instead as an HTTPS request; this is known as a redirect response. Usually the browser silently follows the redirect response’s suggestion, for a seamless user experience.

But having the backend web server generate the redirect responses results in increased computational costs, configurational complexity, latency and bandwidth consumption. Now you can short circuit the process, and have the load balancer issue the redirect directly, reducing any risk of an unencrypted request landing on your backend server. In addition to changing the scheme from HTTP to HTTPS, a redirect response generated from the load balancer can also signal that the request should be sent to a different host, or to a different URL path. 

To accomplish an HTTP to HTTPS redirect, simply configure the defaultUrlRedirect to set the httpsRedirect to true for all hosts.

Backend reorganization with URL rewrite

A URL redirect is usually a conversation between the user (browser) and the load balancer. Cloud Load Balancing’s new URL rewrite feature, however, only affects communication between the load balancer and the backend.

A typical use case for URL rewrite arises when migrating static web content from a VM web server to Google Cloud Storage. In this case, you must map the URL paths for the static web elements to a URL that identifies the storage bucket and the path within the bucket. This translation is not of interest to the client browser, and affects only the interaction between the load balancer and the storage system backend.

To accomplish this, first configure the routeAction as a urlRewrite, where the corresponding host and path matches the client to load-balancer URL.

A/B testing with routing by query parameter

Another capability enabled by these new Cloud Load Balancing features is making routing decisions based on HTTP headers and/or query parameters, rather than just the host and path of the URL.

For example, say you are testing out a new version of a website. You can add a query parameter to a URL that states that a given request should be directed to an experimental backend. Then, the load balancer checks for the presence of the ‘experimental’ query parameter and routes traffic to the experimental-web-server backend service:

We hope you find these examples useful. To learn more about added traffic control features associated with External HTTP(S) Load Balancing, please refer to the documentation. Also check out the Traffic Control APIs supported by Internal HTTPS Load Balancer here. We’d love to learn how you are using these Traffic Control APIs and get your feedback.