So, I’ve a well performing SST based application right now. It is performing well, almost every endpoint that’s user facing is within 35ms response time. Fortunately, my API and my user base reside in the same region and so it was simple to achieve this thanks to AWS, the CDK, SST and SEED. Now, I need to take this further, I am targeting global outreach. In case of the dynamodb and aurora database, I can use global tables for the reads, the writes will have to be to the main table, that’s fine I guess. How would I go about global deployments for the API though, will I have to maintain region specific stages to achieve this? Also, suppose I go ahead with region specific stages how would the custom domain mapping work out? For ex: I’ve 3 stages, one in ap-south-1, one in us-west-1 and one in eu-south-1. If I use my current setup, my custom domains would be

<http://ap-south-1.dev.api.com|ap-south-1.dev.api.com>

,

<http://us-west-1.dev.api.com|us-west-1.dev.api.com>

and

<http://eu-south-1.dev.api.com|eu-south-1.dev.api.com>

. This would also create a problem of implementing some logic as to how to route requests from

<http://dev.api.com|dev.api.com>

to the appropriate region. I believe Lambda@edge is one possible solution but how would I use it here? I could use it for routing requests to appropriate regions, I’ve heard of people doing that. I would love it if you awesome people could chime in with your opinions and experiences on how to build a global serverless API. Most of what I’ve read up involves people creating k8s clusters across multiple regions and using a service mesh such as Istio or Linkerd to coalesce those clusters together at L4. It would be great if we could figure out a L7 solution which needs minimal intervention / management. I know, it’s a lot to ask, but I’d be grateful for any assistance.

One quick thing is route53 supports geo resolving

oh! I had no idea about this, does cdk support this, could you point me in a direction how could I go about implementing this?

This 2018 example from a-cloud-guru looks to be sensible: • DynamoDB global tables • API regional deploys to eu-west-1 and eu-central • Configure DNS to point at multiple API endpoints with weighting ◦ You would need to explore the config for the geolocation based routing • Configure endpoint health checks to automate fail-over at DNS level https://acloudguru.com/blog/engineering/building-a-serverless-multi-region-active-active-backend Thinking about composition in the cdk, it would maybe look something like 2 stacks. One stack that configures global concerns in DNS and custom domains, global tables etc. A second stack that consumes the outputs of DNS and deploys your API. The second stack could be deployed into multiple regions inside the same SST app I think? Similar to this example in cdk docs

👍🏽 to not needing multiple stages. Can initialize the same stacks by passing in the stack props

@Simon Reilly this looks promising. @thdxr yep, I agree that makes sense. The reason I was thinking about separate stages for each region was to be able to modify them / their implementation in the need arises.