CODEWITHSUNDEEP
amazon-web-servicesamazon-ec2amazon-cloudfrontamazon-route53
Sheel Pancholi
Sheel Pancholi

Reputation: 703

Multiple region deployment with Geolocation based policy v/s Cloudfront

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.

Upvotes: 3

Views: 4074

Answers (2)

Michael - sqlbot
Michael - sqlbot

Reputation: 179404

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.

Upvotes: 8

Kannaiyan
Kannaiyan

Reputation: 13055

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.

Upvotes: 0

Related Questions