AWS architecture when multi-regions

Question

I've been introduced recently to AWS and I really loved it. However, I'm asking myself some questions (that may be stupid) about architecturing for multi-regions.

Let's say an application is used by Europeans and Asians. My first idea was to add EC2 instances in Europe, as well as a S3 bucket to hold static data and a SQS queue and ElastiCache in Europe. It's going to be blazingly fast for European people, but slower for asians.

To solve this, I'd add CloudFront for static data, so that images are served quickly for Asians too. However, requests to server (Ajax requests...) still going to have some latencies, so the solution would be to add an EC2 instance in Singapore/Tokyo region too.

However, new problem arise: if a request is dispatched to Tokyo EC2 instance, then if it needs to receive a message from SQS that is stored in Europe or access ElastiCache data => latency again + costs for inter-regions transfer. So we need to add a SQS and ElastiCache in Asia too ?

Maybe I miss something, and cross-regions AWS requests are super-fast, but from what I've understood, if we want fast experience for multi-regions, we basically need to duplicate all services too every regions (excepting S3 maybe, as we can use CloudFront for that, and I suppose we can live with the latency if a SQS job in Asia need to access a S3 resource in Europe).

Anyway, did I understand this correctly ? Do you have any resources about how to architecture applications that target multi-regions ?

Thanks :)

Steven Hood Steven Hood · Accepted Answer · 2013-04-06T18:36:49

These aren't stupid questions at all! This part is absolutely correct:

Maybe I miss something, and cross-regions AWS requests are super-fast, but from
what I've understood, if we want fast experience for multi-regions, we basically
need to duplicate all services too every regions

Cross-region requests will be limited by the speed of light and the network topology between regions. I would expect requests from Asia to reach the European application in about 1/4 second round trip. Most requests would be faster, but you can't guarantee all of them will be faster, so you have to design accordingly. If that isn't fast enough, then yes, you'll need to deploy to a closer region and route users to the appropriate region. The number of times that round trip is required is up to your application's architecture. If you have many requests to Elasticache or SQS, those 1/4 seconds will add up very quickly. If you can batch the requests, it might be tolerable.

To route users to the appropriate region, you'll want to look at Route 53, which is another part of the AWS family. This announcement about Route 53 describes the latency-based routing between regions that you would need. Once users are routed to the appropriate EC2 instances, each region you've deployed to should be isolated. You would configure your European deployment with EC2, SQS, Elasticache, and any other AWS offerings all served from the European region (eu-west-1). For your Asian deployment, you might host it all in the ap-southeast-1 region. Once Route 53 connects an Asian user to an EC2 instance within ap-southeast-1, the requests to SQS, Elasticache, etc. would be within the same region and thus very fast.

AWS architecture when multi-regions

2 Answers