Using AWS Services from different regions using Serverless Architecture
AWS comes with a bunch of cool services and most of the times 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 wants to have services in certain region 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.
Lets 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 of solving this problem. 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 lets jump in to the first step!
Deciding the architecture
People wants 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 does 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 kind of services can’t process on files which resides in S3 in other regions.
So we shall accumulate AWS Rekognition and S3s in another Cloud Formation Stack and lets 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 does 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 integrate with SNS or CloudWatch event of different regions.
So particularly for this use case we shall use a SNS-SQS pipeline to bridge between the stacks. Its 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 on obvious question like how to trigger the Rekognition operation from a lambda in 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.