Known issue: AWS instances types shown may not be available in all regions

For AWS, the UI shows instances types that are not available on the AWS regions.
For example : The t2.nano instance type is not available on eu-central-1 region. This will results in the following error :

Deploying node cluster anasaso:cluster
fe3421a2-anasaso: Deploying to Amazon Web Services/eu-central-1
fe3421a2-anasaso: Instance is now terminated in Amazon Web Services
ERROR: fe3421a2-anasaso: There are no availability zones in Amazon Web Services/eu-central-1 region with the current restrictions to launch the instance
fe3421a2-anasaso: Reallocating containers in other nodes…
fe3421a2-anasaso: Reallocation done!
ERROR: Node Cluster Deploy action on ‘cluster’ in region ‘Amazon Web Services/eu-central-1’ has failed

Hi there! yes, you are right. We are aware of that, we need to improve the way we load the instance types to avoid it. Thank you very much for your feedback!
Regards

I am also receiving this error on Docker Cloud however I think it’s a different issue. I’ve tried t2.nano, t2.micro and t2.medium in us-east-1 (all of which are currently launching fine on Tutum).

I am using the same IAM user as Tutum (different access keys) so the policy permits access correctly to resources within this region.

Hi @marcqualie, looks like your error is relative to AWS itself, with the capacity of those types of instances in that moment in that region, as I can launch them normally. Are you selecting an Availability Zone in special? if so, try to change the subnet where you try to deploy the instance.
Let me know if it works
Regards

Hi @marcqualie, maybe you have reached to default limit on your AWS account (default 20 instances per regions)

I believe its a VPC issue. When trying the default docker cloud VPC - everything works. When using our own VPC, it fails

I was able to get this working by manually selecting a subnet within my own VPC (not an instance availability issue). If I leave subnet set to “auto” it fails every time. I checked and the subnet IPs and availability zones differ from the ones generated by docker cloud, so they may be searching under certain criteria and not finding a subnet that matches, hence thinking there’s no availability.

I can confirm it worked by selecting a specific subnet

1 Like

I’m running into this issue now over a year later. I’ve tried several combinations of different types of node, availability zone, and VPC/subnet, and nothing is working.