Using AWS Services from different regions using Serverless Architecture

AWS comes with a bunch of cool services and most of the time not all the services are available in all the regions. At Craftsmen, while providing premium R&D services to our customers across the globe we encountered situations like this where our customers want to have services in certain regions where not all the services are available but they would like to use those services. In this article, I shall discuss the solutions with appropriate Serverless architecture.

Let’s assume the following use case.

We would like to have our system in Central Canada ca-central-1 and we would like to use the cognitive service of AWS like Rekognition to read texts from the images which is not available in Central Canada.

To make the use case more simple lets assume that we shall use DynamoDB as our No SQL database and S3 as files storages.

Other variants of the above use case could be like below.

The system needs to be deployed in North California (us-west-1) and the system needs to use AWS Transcribe …

There are two steps to solving this problem. The first step is deciding a robust distributed architecture and the second step is using the most simple and cost-effective way to glue them together. So let’s jump into the first step!

Deciding the architecture

People want to use services close to their premises mostly to gain near to zero latency. The heart of Serverless architecture, the lambdas are available in all the regions being supported by AWS. In any system, there will be CRUD operations on data and DynamoDB is also available in all the regions.

We shall accumulate our Lambdas and DynamoDB tables in one Cloud Formation Stack through our serverless.yml.

Now the other parts which are not available in ca-central-1 ( Canada Central) we need to find the nearest regions where these services are available. Generally, these services do extensive processing of data that takes time and returns a result set. Here we are using AWS Rekognition which does process files from S3. Generally, these kinds of services can’t process on files that resides in S3 in other regions.

So we shall accumulate AWS Rekognition and S3s in another Cloud Formation Stack and let’s assume that we are deploying this to us-east-2 (Ohio).

Since we have now spitted architecture as can be seen by the above diagram.

Still, we need to solve a big challenge, which is to ensure seamless communication between the resources across the regions ( stacks). There are several ways of doing it but I shall only cover the most simple one.

In general, almost all the AWS services which do heavy computations notifies the system either through Cloudwatch or through SNS. The limitation of these events is that they can’t go across the regions.

AWS SQS comes here as a rescuer as it can be integrated with SNS or CloudWatch events of different regions.

So particularly for this use case, we shall use an SNS-SQS pipeline to bridge between the stacks. It’s better to have the SQS in the same regions where we have the endpoints ( Lambdas).

So the final architecture will look like below.

Now there will be an obvious question like how to trigger the Rekognition operation from a lambda in the CA-CENTRAL-1 region.

All you need is to instantiate the AWS Rekognition API by supplying the appropriate region which is US-EAST-2 and S3 bucket name of US-EAST-2.