What are the main factors for a multi-region cloud computing design?

• Improve resiliency. Dividing compute units into regions allows for more uptime in case one of the cloud regions experiences outages or degradations.
• Reduce latency. This allows data processing to be closer to the request, boosting performance.
• Enable disaster recovery: Each processing site is fully stacked, hot-hot, and failover ready to handle unexpected events.
• Support a geographically dispersed workforce and remote locations. Bring more and closer compute to a geographically dispersed workforce.

What do you need to be mindful of for a multi-region cloud design?

• Gather traffic and usage data. This allows you to decide the size and location of your needed infrastructure.
• Understand the latency issue. Work with your network providers on private connections and locations.
• Understand the cost implications of multi-regional business and have a solid return on investment plan.
• Prepare from the engineering and development sides to have the proper skills, patterns, and practices to handle the complexity.
• Multi-region does not automatically mean twins or cloning. Understand your system and business, and choose only the applicable portion.

In this example, the cloud computing is based on two regions, one from Northern Virginia and one from Northern California. Key cloud workloads rely on the performance of direct connect (DX). With the same network speed, the distance between the DX location and the region of computation comes into play. Please see the example below. The metrics show the latency in milliseconds of a ping operation from a US East client site to a US East 1 cloud region. It varies from 2 milliseconds for an Ashburn, VA, location to 122 milliseconds for a Denver, CO, location, a 61-times difference. Another ping operation from the US East client site to the US East2 (Ohio) region shows that Ashburn suffered some more latency, but all other three locations decreased.

This data confirms that your DX location contributes to the overall latency of your cloud traffic. It is important to select the cloud region and DX location strategically. It should be based on your geographical application use and specific performance requirements. But one principle holds: you want your primary DX to be as close as possible to your main compute ecosystem.