Closed pegli closed 1 year ago
Hm, I've never heard about that. Let me investigate a little bit.
@pegli As a workaround, have you thought about using another region?
Yes, though I'd like to get it to work in us-west-1 because I'm standing up an instance for my local community in California. Not that latency is going to be a big deal, of course... :)
I successfully deployed my fork to us-east-2 with no problems. The only change was that the number of AZs was set to 3 instead of 2 per issue #3.
I also tried us-west-2 but it gave repeated subnet creation failures. I'm happy to help diagnose/reproduce the problem if needed.
Fixing this is not easy. The way we select the AZs during VPC creation is via CloudFormation's Fn::GetAZs.
There is no way to configure Fn::GetAZs
to only return AZs with certain features. E.g., we would need AZs that support ALBs as well as t4g RDS instances.
On 2/16, I was able to successfully deploy the 0.10.0 templates in us-west-1. My VPC subnets are all in 1a and 1c this time around.
I'll admit that this sounds very unlikely, but CloudFormation is reporting that an Application Load Balancer isn't available in us-west-1a:
The following Availability Zones us-west-1a cannot be associated with a load balancer. Please try a different Availability Zone. (Service: AmazonElasticLoadBalancing; Status Code: 400; Error Code: ValidationError; Request ID: 93e9babc-7135-4d02-b79a-8cfbc27642b2; Proxy: null)
When I create a target group and load balancer by hand, I get the same error:
The following Availability Zones us-west-1a cannot be associated with a load balancer. Please try a different Availability Zone.
I'm able to create an ALB if I remove us-west-1a from the list of AZs. Any guidance on how to set up the ALB and target groups manually?