It appears that the Fn::GetAZs provided by Amazon returns some invalid output if it's run in an account that was created pre-VPC.
Specifically, it returns a list that includes AZs that can not create new subnets in the VPC era. This is relevant to environmentbase because Fn::GetAZs is used in generated templates when creating HaClusters (and probably other places)
Specifically, when deploying a template with an HaCluster in us-east-1 with an older account, the following snippet of generated template:
"privateAZ1": {
"Properties": {
"AvailabilityZone": {
"Fn::Select": [
1,
{
"Fn::GetAZs": ""
}
]
},
causes Cloudformation to explode with: privateAZ1 Value (us-east-1b) for parameter availabilityZone is invalid. Subnets can currently only be created in the following availability zones: us-east-1e, us-east-1a, us-east-1d, us-east-1c.
Note - this ONLY occurs for pre-VPC accounts, due to the invalid AZ being returned. It appears that Amazon is aware of the issue but doesn't consider it a high priority to fix. http://stackoverflow.com/questions/22744467/vpc-capable-availability-zones-in-amazon/22812138#22812138
I'm not really sure what, if anything, can be done to fix this aside from building tables of VPC-subnet-capable AZs yourself instead of using Fn::GetAZs, but I thought you guys should be aware.
It appears that the Fn::GetAZs provided by Amazon returns some invalid output if it's run in an account that was created pre-VPC.
Specifically, it returns a list that includes AZs that can not create new subnets in the VPC era. This is relevant to environmentbase because Fn::GetAZs is used in generated templates when creating HaClusters (and probably other places)
Specifically, when deploying a template with an HaCluster in us-east-1 with an older account, the following snippet of generated template:
causes Cloudformation to explode with:
privateAZ1 Value (us-east-1b) for parameter availabilityZone is invalid. Subnets can currently only be created in the following availability zones: us-east-1e, us-east-1a, us-east-1d, us-east-1c.Note - this ONLY occurs for pre-VPC accounts, due to the invalid AZ being returned. It appears that Amazon is aware of the issue but doesn't consider it a high priority to fix. http://stackoverflow.com/questions/22744467/vpc-capable-availability-zones-in-amazon/22812138#22812138
I'm not really sure what, if anything, can be done to fix this aside from building tables of VPC-subnet-capable AZs yourself instead of using Fn::GetAZs, but I thought you guys should be aware.