Hacker News Reader

Comment by marcinzm | Hacker News Reader

>If the instance runs at higher CPU utilization for a prolonged period, there will be an additional charge of $0.05 per vCPU-hour.

This seems to be the same as the T2 unlimited instances. Interesting that it's now the default and only (?) option.

View on HN

I'm very glad they changed the default to unlimited. The old default behavior of throttling was a just an outage waiting to happen, and it was more painful to opt into unlimited via Cloudformation than it should have been.

It's not the only option - it can be disabled, the same as on T2 instances.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-unlim... has documentation on disabling it.

(Disclosure: I work at AWS, not posting in an official capacity)

I'm not sure I understand, they're basically selling you less than one continuous CPU thread and upcharging if you use a full core? So suppose the machine has 56 cores and they're putting 3 customers on each vCPU. What happens in the case that everyone needs to burst to the full performance of each thread they're paying for (56 * 3)? I imagine they'd price that as if you utilized 100% but give you degraded performance due to hardware limitations.

Please correct me if I'm wrong but this sounds like "unlimited shared hosting for people who can SSH" (except you pay extra instead of unlimited)

What happens in the case that everyone needs to burst to the full performance of each thread they're paying for (56 3)? I imagine they'd price that as if you utilized 100% but give you degraded performance*

There's no reason to assume that. The hypervisor can track how much time each VM actually executed and subtract credits appropriately. AWS pricing is generally high enough that they don't need to use undocumented gotchas.

I would say it's more like shared hosting with full AWS API and ecosystem compatibility. Shared hosting for people who can SSH is Digital Ocean.

T2 and T3 use live migration to get around this, but it's not public knowledge.

Why doesn't ec2 support live migration for more instance types?

Why would they? None of the others are oversubscribed so it is guaranteed that the physical machine has the resources to provide everything that the virtual machine wants. Except network, but AWS doesn't guarantee anything about network speed.

In the case of hardware failure, say a malfunction or an error detected by ECC RAM, most people would prefer the machine to be turned off and they can restart it, rather than continue in a potentially corrupted state. As all the storage is network attached, it can immediately be restarted on another physical machine.

I'm going to guess that AWS is slightly more sophisticated than this, and has good data showing that the vast majority of users of this sort of instance type basically sit idle all the time. Certain customers may consistently max out their t3 instances, but those instances would be spread across thousands of host boxes, sharing resources with the tens of thousands of other customers who aren't utilizing the full capacity.

That rarely works in reality.

Lots of instances will all burst at the same time, for example when someone has thousands of T3 instances and then dumps a bunch of work into a work scheduling system, or when debians cron kicks in at exactly midnight.

I'd much rather Amazon say "You have X% guaranteed CPU, and up to Y% extra cpu you can use on a best effort basis" I'd like to see the same for memory and disk too.

For those who need fixed performance, there should be a setting to disable that best effort extra bit.

The modern instance families support Turbo Boost, which is the X% guaranteed and up to %Y extra best effort you desire. On many of the largest instance sizes you get P-state control which lets you "disable that best effort extra bit" — but most operating systems will by default use it to strategically burst some cores even more at the expense of others.

Many workloads really just need a significant fixed amount of memory, and only periodically need high-performance CPU. T2 instances are much faster than you'd intuitively expect, if your workload is very bursty you can easily beat C4.

The newer Unlimited model "just" removes the edge case of being throttled if you run out of earned CPUCreditBalance, so you no longer have to reason about its interactions with other scaling factors.

It also allows a whole new usecase: if your workload doesn't need much memory or high I/O but will utilize as much CPU as it can get, you can save big by picking smaller burstable instances with Unlimited.

The solution if you need fixed performance is one of the other instance types, so they don't need to make it a setting on the t* types since that's not what they're for.

I think it is more reasonable to compose it from mixture of big to small machines while keeping healthy margin for reserve. It is very much unlikely to get 20 machines above limit and top up all available cores. Also don't forget, that vCPUs most probably don't have any affinity to psychical cores

Reply on news.ycombinator.com