Can see the appeal of AWS for scaling, redundancy, cross region availability, etc., but for long lived services it seems you pay a high price compared to services like Digital Ocean where the per VM cost is significantly lower.
Conceptually it is "pay as you use" by CPU usage, but just rounded into buckets by instance tier.
Of course, there's a lot of underutilization within each bucket, because the granularity isn't per 1% used, but (more or less) per 100% used (aka each core). And also, most applications can't switch instance tiers easily to adapt to demand (though some certainly can).
There is a variety of CPUs. You can "cat /proc/cpuinfo" to see what you got.
>>> most applications can't switch instance tiers easily to adapt to demand (though some certainly can).
Most applications can and do change. Changing the instance type is just a reboot of the machine.
There certainly are, but generally they are the same within the same "class" (ie t2, c5, etc). Example:
- C5: 3.0Ghz custom Xeon processors. - C4: Xeon E5-2666 v3 - C3: Xeon E5-2680 v2 - X1/X1e: Xeon E7-8880 v3 - R4: Xeon E5-2686 v4 - R3: Intel Xeon E5-2670 v2
Etc. The only exception I'm aware of are the burstable instances; AWS's documentation doesn't explicitly guarantee a CPU bin there, it just says "high frequency Xeon".
The difference between an m5.large and an m5.xlarge isn't that you're getting a "faster" processor (meaning higher gigahertz or newer architecture). You're just getting "more" of the same processor (more cores). This is different than on, say, GCP, where you just ask for cores and you can specify if you specifically want a broader generation of Xeon (like Broadwell), but you can't be guaranteed specific chips.
My intention behind saying that most applications can't switch instance tiers is more to point out that most applications aren't prepared to handle node failure, not that there is something intrinsic to the node types which stops them from being able to switch (that'd be much more rare).
