Geo Routing for GDPR compliance made easy using reverse proxy as a service

In this tutorial, we'll show you how to quickly and easily route based on geography, and how developers can handle these responsibilities without relying on specialists.

Background: Why geo-routing is necessary for your service today.

GDPR compliance, data sovereignty, and data residency are important for maintaining the privacy of users, but also require data to be routed and stored in their host countries or states. Europe has GDPR, Canada has Pipeta, and California now has CCPA.

This additional layer of complexity can quickly compound with other network requirements, especially with increasing traffic. This makes it more difficult and expensive to stay in compliance, without an adequately simple and robust solution.

Rules structure

Our rules structure will continue as follows:

If the user is coming from the US, route them to the United Airlines site.

If the user is coming from the Philippines, route them to the Philippine Air site.

Else, route the user to the Star Alliance site.

We are routing to common websites in this example, but for your application, you can route to a geo-specific version of your site (for multi-language support), or route user data uploads to a host that is located in the same country as the user for data sovereignty/residency compliance.

Using a reverse proxy

By using an edge-based reverse proxy that logs sufficient request information, you can ensure that traffic originating from a defined region never leaves that region. We will use Snow Owl, which is a SaaS-based reverse proxy.

Below is a schematic of how a reverse proxy sits between the user and the host architecture:

By using headers in the http request the have been logged by the reverse proxy, we can understand very quickly what location the user is coming from, and route them accordingly.

The rules below will apply to a specific domain or set of domains within the same service. Different users in different geographies navigating to the same domain will be routed to different endpoints based on the rules below.

Example rule #1: Route US traffic to United.com (no code & JSON)

Below are two representations of the same logic for routing US traffic to United.com. They are identical and can be used interchangeably.

Example rule 2: Route Philippines traffic to Philippine Air

{
  "condition": [
    {
      "field": "header:cf-ipcountry",
      "operator": "equal",
      "values": [
        "PH"
      ],
      "not": true
    }
  ],
  "action": [
    {
      "field": "hostname",
      "operator": "set",
      "values": [
        "philippineairlines.com"
      ]
    }
  ],
  "stopProcessing": true
}

Example 3: Else, route traffic to Star Alliance

If users come from a location that isn't the US or the Philippines, they will be defaulted to the Star Alliance site. Snow Owl, we offer simple routing rules that only need a field or two to be filled out, in this case, a Proxy URL rule.

Summary and Discussion

With the right system architecture and service, a quick set of simple rules can be set up enabling technical staff from entry level developers to network specialists to monitor and route their traffic. This makes it substantially easier to stay in compliance with data sovereignty/residency regulations, and manage network complexity much more robustly for higher site reliability and much lower costs + time.

For more information, check out:
SnowOwl.co
docs.snowowl.co