[mwpmaybe]

Yeah, that's... not practical.

What if they upgrade the 1024 plan to 1536? (That has actually happened, by the way.) Now you're extracting the number and comparing it to a range?

> Give me the plan where the RAM is >= 1024 and < 2048.

What if they upgrade the 1536 plan to 2048?

> Nevermind, just give me the plan with two cores.

Okay, do you want the $20/mo plan or the $120/mo plan?

> Fine, sort the plans by cores and memory and give me the smallest plan.

Oops, they introduced a new plan with one core and less (i.e. not enough) storage.

I'm not saying it's impossible. Just impractical.

[Sir_Cmpwn]

It's not as difficult as you're suggesting. Figure out your minimum specs and get the cheapest plan that meets them.

[ceejayoz]

Or, the API's plan IDs could correspond to specific plans, and never change. New plans mean new IDs. Like how IDs are supposed to work.

[Sir_Cmpwn]

The plans themselves have changed many times before. They become obsolete over time. What if your plan ID becomes unavailble, or the specs change in a way your application can't handle? Don't shrug off your bad design decisions on someone else.

[ceejayoz]

> What if your plan ID becomes unavailble

The API should throw an error, so I can adjust my scripts, instead of silently provisioning a server I never intended to provision.

There should be a deprecation process when a plan is discontinued, so this doesn't happen unexpectedly.

If AWS can't provision me a t1.micro, they don't just go and give me a m3.small instead.

[uiri]

Deprecated plan ID requests should return two plan ids (new_price <= old_price and new_specs >= old_specs). Then a bit of retry logic means the code will still function sanely until the hard coded ID can be updated (or it may continue to function indefinitely).