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
What Is an SQL Query Engine? SQL query engine architecture was designed to allow users to query a variety of data sources within a single query. While early SQL-based query engines such as Apache Hive allowed analysts to cut through the clutter of analytical data, they found running SQL analytics on multi-petabyte data warehouses to be a time-intensive process that was difficult to visualize and hard to scale.Explore
A Winning Base for Successful Digital Transformations When it comes to developing a successful digital strategy, it is not just corporations planning to maximize the benefits of data assets and technology-focused initiatives. The Government of Western Australia recently unveiled four key priorities for digital reform in its new Digital Strategy for 2021-2025.Explore
Engage Your Workforce with a Modern Employee Intranet Solution The employee intranet has changed significantly since it was first introduced in the early 1990s. What started as HTML-based static portals have now evolved into intuitive communication tools complete with search engines, user profiles, blogs, event planners, and more. Today, many organizations are taking a second look at employee intranets to bridge gaps between teams, build company culture, centralize information, increase productivity, and improve workflow.Explore
Adopting emerging cloud technologies, consolidating resources, and improving processes is the key. “IT no longer just supports corporate operations as it traditionally has but is fully participating in business value delivery. Not only does this shift IT from a back-office role to the front of business, but it also changes the source of funding from an overhead expense that is maintained, monitored, and sometimes cut, to the thing that drives revenue,” said John-David Lovelock, research vice president at Gartner.Explore
Deliver Powerful Insights Instantaneously with Federated Queries - No Matter Where Your Data Resides The concept of federated queries isn’t new. Facebook PrestoDB popularized the idea of distributed structured query language (SQL) query engines in 2013. Over the years, AWS, Google, Microsoft, and many others in the industry have accelerated the adoption of a distributed query engine model within their products. For example, AWS developed Amazon Athena on top of the Presto code base, while Google’s BigQuery is based on Cloud SQL.Explore
What is Unstructured Data? Almost 80% of the data that enterprises and organizations collect is unstructured - data without a set record format or structure. Unstructured data includes data such as emails, web pages, PDFs, documents, customer feedback, in-app reviews, social media, video files, audio files, and images.Explore