The final recovery strategy is the most complex and the most costly out of the different recovery strategies available, this being ‘Multi-site active/active’. However with this complexity and cost, it does offer you the lowest RTO and RPO when it comes to defining your DR strategy which is required for those critical applications and solutions that need it.  

Whereas with the other recovery options there was an element that required you to provision additional resources within your DR region after the disaster had occurred, however with Multi-site active/active you are effectively deploying your infrastructure across multiple regions at full scale.  So this means that there isn’t a designated DR region, instead your customers can access your applications and services from any region they require, and if one region goes down, your applications and data can continue to be accessed from another region, there is no need for any failover events to be triggered. 

Let’s take a quick look at how this configuration would look:

As you can see, both regions are actively running operational workloads.  Route 53 is being used to route traffic accordingly based on specific routing policies that have been configured which will route traffic to the appropriate region.  At this point, the ELB will balance incoming requests between different AZs at the web server layer, which can scale using auto scaling groups.  From here, the request will be passed to the application layer where it is then passed to DynamoDB.  The DynamoDB data store has replication occurring automatically at this database layer using DynamoDB global tables, in addition to continuous backups of DynamoDB being taken in both regions.  

This configuration means should either of the regions fail, your application and services will remain fully functional with no requirement to manually provision additional resources.

However not all problems are mitigated when operating a Multi-Site active/active solution, you do still need to be aware of a few points! Firstly, you must still perform testing of your DR strategy, for example, should a region fail, will the remaining region(s) be able to handle the additional traffic being routed to it? Secondly, you could experience another disaster of data corruption or deletion, which means you might have to restore your databases from a backup, which will take time affecting your RTO.