barely. A couple of minor notes. What you call AZ is actually an area. The region is again divided into separate AZ regions. Simply put, a region is a DC or a group of nearby DCs with lightning fast interconnects (fibers from the operator itself). Each of the AZs often has its own power and primary networks/routers, and so can fail independently of the other AZs.

For example with Google Cloud Platform you have the region eu-west4 (NL / Groningen) and there are 3 regions AZ: eu-west4-aeu-west4-Beu-west4-c. These terms are also used in Azure and AWS. By the way, the region is not limited to 3 AZs. For example, eu-west1 (BE/St. Ghislain) has 4 AZ regions, so also eu-west1-Dr.

As a general rule, it is wise to divide your servers between different Availability Zones (AZs) in the region. Internet congestion inside The area is often very cheap or even free. This way you can aggregate multiple servers without having to pay for traffic within your cluster. Basically, you should be safe from things like fires and broken uplinks this way.

A multi-zone setup is often more difficult and complicated. This is where things like latency come into play, which isn’t ideal in many situations.

If I read the message from Micro $oft correctly, this is about cutting interconnection between different AZ regions within the Western European region. In this case, it is often best to turn off the workload in an isolated AZ, so that other AZs can continue without a hitch. However, the message from MS is very short… It’s not entirely clear which lines/AZ lines are completely broken..

AWS: https://docs.aws.amazon.c…s-availability-zones.html
GCP: https://cloud.google.com/compute/docs/regions-zones
I visit: https://learn.microsoft.ca…ailability-zones-overview