Multiple region deployment with Geolocation based policy v/s Cloudfront

2
votes

I have a custom origin i.e. a web app on an EC2 instance. How do I decide whether I should go for:

  1. a Cloudfront CDN

or,

  1. deploy multiple instances in different regions and configure a Geolocation/proximity based routing policy

The confusion arises from the fact that both aim at routing the request to the nearest location (edge location in case of Cloudfront and region specific EC2 instance when it comes to multi-region deployments with Geolocation based policy with Route 53) based on where the request originates from.

2
amazon-web-servicesamazon-ec2amazon-cloudfrontamazon-route53
This is an incomplete question, what things you're keeping me your mind before you choose any of these, there can be multiple solutions, not only Geo, LBR can be also be helpful but are you considering like: caching(static dynamic), cost, maintenance, number of users, instance types, traffic etc ? CloudFront edge location is based in terms of latency , not geo. – James Dean
Thanks. I know CDN is latency based. The point I am stressing upon is quickness of access. I wanted to understand the various factors that could influence. I have a DB to support dynamic content. I understand from the docs that even dynamic content could be cached based on query params/request headers/cookies if we know the dynamic content won't continuously keep changing with every access. I also have static pages. I have users across the globe. Since you say there are a multitude of options apart from CDN, Geo, LBR etc. Would you be able to list those & the conditions that influence them? – Sheel Pancholi

2 Answers

3
votes

There is no reason why you can't do both.

CloudFront automatically routes requests to an edge location nearest the viewer, and when a request can't be served from that location or the nearest regional cache, CloudFront does a DNS lookup for the origin domain name and fetches the content from the origin.

So far, I've only really stated the obvious. But up next is a subtle but important detail:

CloudFront does that origin server DNS lookup from a location that is near the viewer -- which means that if the origin domain name is a latency-based record set in Route 53, pointing to deployments in two or more EC2 regions, then the request CloudFront makes to "find" the origin will be routed to the origin deployment nearest the edge, which is also by definition going to be near to the viewer.

So a single, global CloudFront deployment can automatically and transparently select the best origin, using latency-based configuration for the backend's DNS configuration.

If the caching and transport optimizations provided by CloudFront do not give you the global performance you require, then you can deploy in multiple regions, behind CloudFront... being mindful, always, that a multi-region deployment is almost always a more complex environment, depending on the databases that are backing your application and how they are equipped to handle cross-region replication for reads and/or writes.

Including CloudFront as the front-end is also a better solution for fault tolerance among multiple regional deployments, because CloudFront correctly honors the DNS TTL on your origin server's DNS record, and if you have Route 53 health checks configured to take an unhealthy region out of the DNS response on the origin domain name, CloudFront will quickly stop sending further requests to it. Browsers are notoriously untrustworthy in this regard, sometimes caching a DNS answer until all tabs/windows are closed.

And if CloudFront is your front-end, you can offload portions of your logic to Lambda@Edge if desired.

0
votes

You can use multi region for lot reasons mainly,

  1. Proximity
  2. Failover (incase if first region fails, requests can be sent to another region)

Multi region lambda deployment is clearly documented here. You can apply the same logic to all of the AWS Resources too. (DynamoDB, S3)

https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/

You can also run Lambda@Edge to force all your requests / splits to one region on the edge.

Hope it helps.