Automatically choosing the last AZ can be troublesome.

[bear454]

Enceladus/ec2utils/ec2uploadimg/lib/ec2utils/ec2uploadimg.py

Line 770 in bb19b7b

self.zone = availability_zones[-1]

In us-east-1, that resolves to us-east-1f, which is not like any other region:

Last week AWS quietly added a new availability zone to us-east–1. This new AZ (us-east–1f) differs from other AZs in a few ways.

It’s consistent between accounts. Other AZs are not– my us-east–1c might be your us-east–1a.
It only supports the latest generation of EC instances– namely the C4, M4, R4, I3, T2, D2, and X1 instance families.
If your code expects 5 AZs in us-east–1 and is now receiving 6, you may have discovered some fun new failure modes last week.

As a result, this week’s tip is to question the assumptions you have about regions– not all AZs are equal, and their numbers aren’t static.

• https://snarkive.lastweekinaws.com/issue_14-_US-East-1_Drops_An_F-Bomb.html

As a result, errors occur in ec2uploadimg that the user cannot resolve in the obvious way:

An error occurred (Unsupported) when calling the RunInstances operation: Your 
requested instance type (m3.medium) is not supported in your requested Availability 
Zone (us-east-1f). Please retry your request by not specifying an Availability Zone 
or choosing us-east-1b, us-east-1d, us-east-1c, us-east-1e.

[rjschwei]

Suggestions for wording or improvements welcome. This is a configuration or command line setting, if we would not choose the last AZ and a user had, lets say m9 in their configuration file, one would get the same message. A chosen instance type not being available is a general problem, AZ independent, and given that there is no API call to retrieve the available instance types there is no way to verify the user's choice.