AWS has a low elasticity ceiling for big servers
noahlebovic.comI think there's a bit of a relationship with the age of the instance type. Whether that's supply chain, different policies around spare capacity, or even customer demand I don't know.
My specific area only has need for a relatively small number of nodes - and its been a while since we've had much trouble getting i3en.* instances in Sydney.
The new i4i's though? Kinda feels like they've, only got 3 hosts.. or 2 if Greg's off sick and can't switch on the one under his desk.
We recently moved to attribute based instance selection for our web traffic. It turns out that there's a ton of capacity in random instance classes at various times. Sometimes it's c6a.metal with 192 vCPU. Sometimes it's i3.metal with 64 vCPU.
We've been able to get the capacity we need much more readily with this configuration. (everything is spot btw)
i suspect its more likely that there are pools for c5a.large, xlarge, etc. and that they just aren't prioritizing as much buffer/liquidity in the large instance type pools. with chip shortages it may be worth it to them to prioritize more common workloads or those which they can get a consistent percentage of a host rented vs. all-or-nothing.
Seems plausible. It would be awesome if AWS had a publicly accessible metric to plan around this, do you know of anything like that?
Stop using us-east-1!
Author here, while us-east-1 has disproportionately bad uptime that's not our biggest concern (two nines is actually okay for our use-case!). Our concern is lack of high memory instance availability, for which us-east-1 was better than us-east-2 until recently – we even switched us-east-2 -> us-east-1 for our primary deploy.
How do you do that for IAM?