Multi Region Architecture on AWS for SNS notifications

Question

We are trying out multi-region architecture for our application. Which is used by multiple clients.

We are using aws to replicate databases (s3 and dynamodb), and it solves data availability issues.

We use SNS to notify our clients whenever there is any data change, but I could not find any good pattern for message replication cross region.

Here are few consideration/requirements we will have to keep in mind

1. Clients should be able to get all the notifications even if they are in only one region.

2. Application should continue to work even if one region goes down. And if possible message can be replayed when region comes up.

Here are few approaches with pros and cons that are coming to our mind.

1. EC2 server writes to both the regions

   Pros.

   a. Requirement 1 is easily satisfied.

   Cons.

   a. Not sure if this is feasible, since no doc suggests to do so.

   b. won't be able to replay messages if one region goes down.

   c. latency delays in writing to both the regions.

2. Having a lambda function to write to both the regions. Since lambda functions can subscribe to cross region sqs and sns. We can have a lambda function in both the regions listening to another region's sns/sqs and then writing to its own region's sns.

   Pros:

   a. Requirement 1 is solved.

   b. Requirement 2 is solved if we use sqs instead of sns, where message will be kept in queue for some time if the region is down and messages will be replayed whenever region comes up. cross region sqs subscription is not possible and lambda function has to subscribe to sns.

   Cons:

   a. Cross region permissions means hardcoding in the cloudformation, not sure if cloudformation supports import from another region.

   b. Cost of lambda function. (although it will be minimal)

3. Instead of writing to sns, we write to dynamodb and use dynamodb global table and streams to send notification in both the regions.

   Pros.

   a. Requirement 1 is solved.

   b. Requirement 2 is solved since dynamodb replication will take care of replicating message.

   Cons.

   a. Costly solution.

Can you please suggest if I am missing anything or some other pattern is there which we should consider?

looking at above possible approaches, I am inclined towards approach 2,

Answer 1

We ended up solving it using this approach

1. Application write message to a SQS.

2. A lambda function is subscribed to the queue.

3. Lambda function writes to both the region's sns.

By this we can introduce delays and some preprocessing as well before sending the message. However IMO the best solution would have been to use dynamodb stream to generate message(Not a new dynamodb table but from the table where we are writing the data), since it would have meant that when we send message in one particular region data has already been replicated.