4

I am planning to use AWS to host a global website that have customers all around the world. We will have a website and app, and we will use serverless architecture. I will also consider multi-region DynamoDB to allow users closer to the region to access the closest database instance.

My question regarding the best design to implement a solution that is not locked down to one particular region, and we are a borderless implementation. I am also looking at high traffic and high number of users across different countries.

I am looking at this https://aws.amazon.com/getting-started/serverless-web-app/module-1/ but it requires me to choose a region. I almost need a router in front of this with multiple S3 buckets, but don't know how. For example, how do users access a copy of the landing page closest to their region?, how do mobile app users call up lambda functions in their region?

If you could point me to a posting or article or simply your response, I would be most grateful.

Note: would be interested if Google Cloud Platform is also an option?

thank you!

Bluetoba
  • 885
  • 1
  • 9
  • 16
  • 1
    Start developing in one region. Once everything works, tested, and you have an MVP, you can deploy the same infrastructure and your application to other regions. – Noel Llevares Mar 20 '18 at 20:55
  • Thanks for that suggestion, and I am planning to do exactly that. But you need to know the end state and work backward with the overall architecture. I need to know the requirements/specification for overall solution, so that my short term solutions are not preventing me from scalling out. – Bluetoba Mar 20 '18 at 22:02

1 Answers1

4

S3

Instead of setting up an S3 bucket per-region, you could set up a CloudFront distribution to serve the contents of a single bucket at all edge locations.

During the Create Distribution process, select the S3 bucket in the Origin Domain Name dropdown.

Caveat: when you update the bucket contents, you need to invalidate the CloudFront cache so that the updated contents get distributed. This isn't such a big deal.

API Gateway

Setting up an API Gateway gives you the choice of Edge-Optimized or Regional.

In the Edge-Optimized case, AWS automatically serves your API via the edge network, but requests are all routed back to your original API Gateway instance in its home region. This is the easy option.

In the Regional case, you would need to deploy multiple instances of your API, one per region. From there, you could do a latency-based routing setup in Route 53. This is the harder option, but more flexible.

Refer to this SO answer for more detail

Note: you can always start developing in an Edge-Optimized configuration, and then later on redeploy to a Regional configuration.

DynamoDB / Lambda

DynamoDB and Lambda are regional services, but you could deploy instances to multiple regions.

In the case of DynamoDB, you could set up cross-region replication using stream functions.

Though I have never implemented it, AWS provides documentation on how to set up replication

Note: Like with Edge-Optimized API Gateway, you can start developing DynamoDB tables and Lambda functions in a single region and then later scale out to a multi-regional deployment.

Update

As noted in the comments, DynamoDB has a feature called Global Tables, which handles the cross-regional replication for you. Appears to be fairly simple -- create a table, and then manage its cross-region replication from the Global Tables tab (from that tab, enable streams, and then add additional regions).

For more info, here are the AWS Docs

At the time of writing, this feature is only supported in the following regions: US West (Oregon), US East (Ohio), US East (N. Virginia), EU (Frankfurt), EU West (Ireland). I imagine when enough customers request this feature in other regions it would become available.

Also noted, you can run Lambda@Edge functions to respond to CloudFront events.

The lambda function can inspect the AWS_REGION environment variable at runtime and then invoke (and forward the request details) a region-appropriate service (e.g. API Gateway). This means you could also use Lambda@Edge as an API Gateway replacement by inspecting the query string yourself (YMMV).

Community
  • 1
  • 1
Nicholas Sizer
  • 3,490
  • 3
  • 26
  • 29
  • Thank you Nicholas, I think you have given me the breakthrough in my understanding with CloudFront. – Bluetoba Mar 21 '18 at 06:37
  • 1
    Thanks for sharing the link to my answer about CloudFront and API Gateway regional vs edge-optimized endpoints. Note that DynamoDB now supports fully automated multi-region replication, https://aws.amazon.com/dynamodb/global-tables/ ... and Lambda@Edge deserves a mention, here, since it can be used in a CloudFront Origin Request trigger to potentially select regional service targets for in-flight requests (eS3, API-GW, Dynamo) based on the region where the edge serving a given request is located (as found in `process.env.AWS_REGION`). – Michael - sqlbot Mar 21 '18 at 11:01
  • Oh wow, that's even better! Thanks for the info, will update answer. – Nicholas Sizer Mar 21 '18 at 12:18
  • Man Man Man. You gave all the answers in short and sweet words. – SSS Apr 03 '18 at 03:53