9 ms·

AWS AZs: Not all are Equal (2021)

24 points by sciurus 5y ago

everfrustrated 5y ago
This is a quirk of us-east-1 only due to its legacy of having 6-8? AZ's (depending on how old your aws account is), whereas all other regions are (mostly) a more standard 3 AZ arrangement.
- runlevel1 5y ago
  Here's a count of AZs based on the AZ IDs: Format: `region (launch year): count` us-east-1 (2006): 6 ap-northeast-1 (2011): 4 ap-northeast-2 (2016): 4 us-west-2 (2009): 4 af-south-1 (2020): 3 ap-east-1 (2019): 3 ap-northeast-3 (2018): 3 ap-south-1 (2016): 3 ap-southeast-1 (2010): 3 ap-southeast-2 (2012): 3 ap-southeast-3 (2021): 3 ca-central-1 (2016): 3 cn-north-1 (2013): 3 cn-northwest-1 (2017): 3 eu-central-1 (2014): 3 eu-north-1 (2018): 3 eu-south-1 (2020): 3 eu-west-1 (2007): 3 eu-west-2 (2016): 3 eu-west-3 (2014): 3 me-south-1 (2019): 3 sa-east-1 (2011): 3 us-east-2 (2016): 3 us-gov-east-1 (2019): 3 us-gov-west-1 (2011): 3 us-west-1 (2011): 3 (As reported by SSM's `/aws/service/global-infrastructure/availability-zones/` endpoint) EDIT: Some curiosities of note: - apne1-az3: In the list, but some things, like NAT Gateway, aren't available; seems like most (all?) people can't provision new instances there. - cac1-az3: Not in list; jumps from az2 to az4. Supposedly launched for internal use back when cac1 only had 2 public AZs because S3 and some other services require 3 AZs for redundancy. - cnn1-az3: Not in list; jumps from az2 to az4. Same reason as cac1-az3?
AtlasBarfed 5y ago
Also, some regions don't support network optimized instances, or not all instance types of optimized instances. Japan once ran out of instances of a type we wanted. When we finally got more, they all got located on the same host (without us knowing)... that host went down and we lost more VMs of a distributed database than we would have liked. I've read that there are even regional differences in S3 metadata (like hash values for the file ... useful for seeing if you have the same file and don't need to upload and get dinged by AWS's ludicrous I/O costs). AWS was also kind of scummy with the retirement of... I think it was us-east-1e where they have no m5s. We had to move AZs for one of our databases and so the AZ name of that rack of servers no longer was the same as the actual AZ. We eventually fixed it, but why AWS couldn't transparently migrate an AZ? Anyway, the magic cloud isn't as magic as it appears. You'll run into edge cases.
- BaconPackets 5y ago
  I'm surprised that you had that much placement on a single compute. I do believe there are ways to prevent that compute failure domain at the VM creation with placementgroups
- dantheman 5y ago
  May want to make sure your EC2s are in the right placement groups: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placemen...

24 points by sciurus 5y ago

This is a quirk of us-east-1 only due to its legacy of having 6-8? AZ's (depending on how old your aws account is), whereas all other regions are (mostly) a more standard 3 AZ arrangement.

runlevel1 5y ago
Here's a count of AZs based on the AZ IDs: Format: `region (launch year): count` us-east-1 (2006): 6 ap-northeast-1 (2011): 4 ap-northeast-2 (2016): 4 us-west-2 (2009): 4 af-south-1 (2020): 3 ap-east-1 (2019): 3 ap-northeast-3 (2018): 3 ap-south-1 (2016): 3 ap-southeast-1 (2010): 3 ap-southeast-2 (2012): 3 ap-southeast-3 (2021): 3 ca-central-1 (2016): 3 cn-north-1 (2013): 3 cn-northwest-1 (2017): 3 eu-central-1 (2014): 3 eu-north-1 (2018): 3 eu-south-1 (2020): 3 eu-west-1 (2007): 3 eu-west-2 (2016): 3 eu-west-3 (2014): 3 me-south-1 (2019): 3 sa-east-1 (2011): 3 us-east-2 (2016): 3 us-gov-east-1 (2019): 3 us-gov-west-1 (2011): 3 us-west-1 (2011): 3 (As reported by SSM's `/aws/service/global-infrastructure/availability-zones/` endpoint) EDIT: Some curiosities of note: - apne1-az3: In the list, but some things, like NAT Gateway, aren't available; seems like most (all?) people can't provision new instances there. - cac1-az3: Not in list; jumps from az2 to az4. Supposedly launched for internal use back when cac1 only had 2 public AZs because S3 and some other services require 3 AZs for redundancy. - cnn1-az3: Not in list; jumps from az2 to az4. Same reason as cac1-az3?

AtlasBarfed 5y ago

Also, some regions don't support network optimized instances, or not all instance types of optimized instances. Japan once ran out of instances of a type we wanted. When we finally got more, they all got located on the same host (without us knowing)... that host went down and we lost more VMs of a distributed database than we would have liked. I've read that there are even regional differences in S3 metadata (like hash values for the file ... useful for seeing if you have the same file and don't need to upload and get dinged by AWS's ludicrous I/O costs). AWS was also kind of scummy with the retirement of... I think it was us-east-1e where they have no m5s. We had to move AZs for one of our databases and so the AZ name of that rack of servers no longer was the same as the actual AZ. We eventually fixed it, but why AWS couldn't transparently migrate an AZ? Anyway, the magic cloud isn't as magic as it appears. You'll run into edge cases.

BaconPackets 5y ago
I'm surprised that you had that much placement on a single compute. I do believe there are ways to prevent that compute failure domain at the VM creation with placementgroups
dantheman 5y ago
May want to make sure your EC2s are in the right placement groups: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placemen...