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).
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:
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.
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.
Create multiple origins for each region's ALB to the main CF distribution (US).
Create a [email protected] function and attach to this distribution, which will validate the location of the user and send to appropriate origin.
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:
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.
Contact Us Today
Breaking Down the Walls Every organization deals with data in one way or another—whether in a database, data warehouse, or other architecture type. With this data comes a management burden, as customer data must be protected in line with data regulations. IT teams struggle with data pipelines: controlling access to datasets across numerous products, services, and business applications. Improper data governance and security configurations can prevent data access entirely and leave data in the wrong internal or external hands.Explore
Putting Data to Work Recently, one of the world’s largest global shipping companies was seeking to identify new revenue opportunities; specifically, they were interested in monetizing their data by building other, related business intelligence products for different industries. Like many other businesses, they had found themselves sitting on a mountain of actionable data without any processes in place to explore or leverage said data. Their intentions were now pointed in the right direction, but what they were missing was a data monetization strategy.Explore
The Data Tide Businesses in the digital age are inundated with data as it floods in from multiple channels. This data is both a challenge to wade through and an absolute goldmine. Its tremendous potential can be harnessed to communicate meaningfully with audiences and advance an organization’s brand awareness in the public eye. The problem is, however, that raw data itself can’t tell a compelling story to most people. It needs to be woven together artfully to create a narrative that connects with a specific audience. This is where data-driven storytelling comes in.Explore