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 Lambda@edge 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
With the explosive growth of social media in recent years, the entire marketing landscape has changed drastically and become more cut-throat. Today businesses have various avenues through which they can market themselves like “social media influencers,” commonly found on social media platforms like Instagram and Facebook with millions of followers—all of whom you can potentially reach by extension of these individuals.Explore
Choosing to implement a Data-as-a-Service (DaaS) strategy can be a daunting task, especially when deciding amongst the numerous cloud DaaS providers in the market. Handing control of your data to a third party involves some inherent risks, which makes it important for you to make the right choice for the long-term data security of your business.Explore
Enterprises across the world are increasingly reliant on the cloud technology when undergoing a digital transformation. At the same time, the complexity of cloud platforms is increasing, making it difficult for IT professionals to keep pace with these advances.Explore
As the demand to work remotely skyrockets due to the evolving COVID-19 situation around the globe, businesses are struggling to keep pace with extending remote access for employees while maintaining high levels of security, productivity and quality.. . The traditional applications and infrastructure used by most businesses are proving to be a hindrance as there are the complex tasks of checking compatibility in the cloud, augmenting existing applications to function in the cloud, and optimizing each application both individually, and as part of a holistic network.Explore
If your company has decided to migrate your data center infrastructure to the cloud, you probably already have one foot in the planning stage. If any of the other necessary steps end up being missteps, it could lead to downtime, customer outages and other unacceptable problems. Here at Trianz, we have worked with hundreds of companies migrating their systems to the cloud and based on that experience, we recommend you consider the following key questions as part of your planning process.Explore
Migrating data center infrastructure to the cloud offers businesses many significant advantages. Once the decision has been made, it is important to keep in mind that a massive undertaking such as this runs the risk of setbacks if not executed carefully and correctly. In many companies, executive leadership is already hesitant to make such a large change, so ensuring that the entire migration is completed without an outage is essential for continued buy-in.Explore