Enterprises are in a flux. An application served by a single CloudFront distribution across the globe with multiple PoPs in various regions should be accessible with one single endpoint (app.example.com) yet meet some important criteria. These include:
An ability to serve traffic to the nearest selected region
We should be able to route the traffic to the desired (forcibly) PoP, like even though EU is near for ME region, the traffic should go to the US.
Maintaining geo-based restrictions for compliance
Geo-based compliances such as GDPR etc.
Seamless addition of future application PoPs
A future application PoP in a new region should not cause any downtime.
Maintaining application disaster recovery (DR)
If the data is available with the required recovery point objective (RPO), this solution can meet the DR capability by modifying few Route 53 records in case of disaster at any given region.
The obvious question is: “Why CloudFront with default Route 53’s geo-based policy is not ideal?” The simple answer is: Route 53, in this case, depends on CloudFront’s edge location, and not the actual location of the client IP (please refer to the approach section for more details).
Why is geo-proximity important?
The importance of geo-proximity depends on various factors. The most common ones include:
Performance– To improve application performance by routing to the nearest application instance.
Compliance – To meet the governance of local authorities.
Workload classification – To be able to segregate workload based on priority,
Find below expected application flow diagram:
Approaches & Challenges
Since we cannot have two CloudFront distributions pointing to one CNAME (https://forums.aws.amazon.com/thread.jspa?threadID=97997), we can consider the following two approaches outlined below, before proceeding with the final solution.
Approach 1 -- CF distribution with a custom origin & Route 53 manage traffic at ALB based on Edge location IP:
Create a geo-based Route 53 records pointing to ALBs in application regions:
i.e., origin.example.com pointing to ALB CNAME in each region.
Add this as custom origin to the CF distribution (xxxx.cloudfront.net).
Create CNAME record for xxxx.cloudfront.net to be accessed as app.example.com (which is the actual application URL).
In this case, when customer accesses app.example.com, the request will be sent to respective ALB based on Edge location's IP.
| Pros | Cons |
|---|---|
|
|
Approach 2 -- Lambda@Edge Dynamic Origin Routing with multiple origins:
Create multiple origins for each region's ALB to the main CF distribution (US).
Create a Lambda@edge function and attach to this distribution, which will validate the location of the user and send to appropriate origin.
| Pros | Cons |
|---|---|
|
|
Solution
To address some of the drawbacks of the above two approaches, there is an alternative method, which is a slight modification on “Approach 1”, but in this case, we will make Route 53 to force geo-proximity instead of using its default geo-based policy.
Here is how default geo-based routing policy works:
Create a RRset as below, which will send all traffic to ALB in eu-west-1 region based on the geo-location.
Geolocation routing policy works by mapping IP addresses to locations in the geolocation-database, i.e., if an IP address is not updated correctly in the database, Route 53 will continue routing wrongly.
To avoid issues with backend geo-location database, here is how we need to create the record set:
Name: origin.example.com
Alias: Yes (this is recommended than CNAME from the costing prospective)
Alias Target: Target of the actual endpoint (ex: EU ALB DNS name for EU regions etc.,) Routing Policy: “Latency”
Location: Region name (here is how we are forcing Route 53 to direct traffic to the respective target)
Here is how it works. We are creating all traffic from eu-west-2 to the required target irrespective of the Route 53’s geo-database. Having said that, below are the consideration with this method:
You can only create one latency record for each Amazon EC2 region.
You aren't required to create latency records for all Amazon EC2 regions.
Route 53 chooses the region with the best latency from among the regions for which you create latency records.
You can't create non-latency records that have the same values for Name and Type as latency records.
If you create a record tagged with the region cn-north-1, Route 53 always responds to queries from within China using this record, regardless of the latency.
Finally, the solution will look like this.
If you are facing difficulties with your approaches, schedule a consultation with us. Our experts can devise a specific solution for you based on your requirements.
