Criteria for choosing which regions to use on a multi-region setup for improved reliability

1

Based on the recent outage at us-east-1, where we have most of our AWS resources, the company has taken the path to start transitioning into a multi-region architecture, but picking which extra region(s) to use is not a matter of chance and the decision must be thoughtfully taken.

Right now the first criteria to consider is cost as most US-based regions are cheaper for example than the one in Sao Paulo. Latency for our customers (distributed across LATAM and US) might be worthwhile considering, but right now everything is working from Virginia. For major disasters maybe replicating to a different country, or perhaps even continent could be the best for geographic isolation, but at a cost.

How do you actually decide which regions to use? How to weigh different factors? Is there an actual guide for such?

2 Respuestas
4

There was a recent blog post on this: "What to Consider when Selecting a Region for your Workloads" https://aws.amazon.com/blogs/architecture/what-to-consider-when-selecting-a-region-for-your-workloads/ Hope this will help you identify the criteria that you could use.

respondido hace 2 años
1

From the blog post above, you will likely mainly consider latency (some regions such as Stockholm are cheap to use but would significantly impact your US/SA userbase's experience) and cost as you mentioned.

Cost though is something you can tune and optimise by carefully consider what you need to replicate (this will be based on your risk modelling). For example, if you go for active/active and plan to do old-fashioned backups, you can keep them in the cheapest region. Traffic flows can be optimised to avoid going too much "cross border" (ie make sure once an user's request enters into a region, it stays there).

I know you haven't directly requested it, but if you're planning things now, I suggest to do it with this in mind: https://aws.amazon.com/builders-library/static-stability-using-availability-zones/ - most of Amazon/AWS are designed based on this principle and generally limiting your dependency on control planes or changes in general during a failure will make everything better.

AWS
respondido hace 2 años

No has iniciado sesión. Iniciar sesión para publicar una respuesta.

Una buena respuesta responde claramente a la pregunta, proporciona comentarios constructivos y fomenta el crecimiento profesional en la persona que hace la pregunta.

Pautas para responder preguntas