New T3 Instances – Burstable, Cost-Effective Performance | Hacker News Reader

New T3 Instances – Burstable, Cost-Effective Performance

aws.amazon.com

97 pointsrunesoerensen47 comments

When I first read this headline I had a flashback to the late 90's / early 2000's. It was a time when the term "T3" unambiguously meant only one thing: a blazing fast, very expensive, dedicated network connection!

https://en.wikipedia.org/wiki/T-carrier

Then a few years later the even fatter optical pipes came along - OC1 and OC3 lines.

My, how times change! ..Well, some things do. If you want a T3 line, they're still available, and today will cost you in the neighborhood of $3,000USD/month (down from $10-15K/month around Y2K).

What a bargain :)

https://www.google.com/search?q=how+much+does+a+t3+line+cost

I had the same exact thought except OC192 popped into my head =)

Wow, 45-90Mbps for $3k-$6k/mo.

It's not only about the throughput, it's also about the SLA and sustainable throughput.

When I started my IT career in South Africa the internet situation was pretty horrendous. ADSL/Broadband speeds were 384kbps and you had hard bandwidth caps of ~$7 per gigabyte of traffic on top of your line rental.

Companies and universities could, however, cough up for expensive alternatives, such as a diginet line which the ISP I worked for at the time offered. These guaranteed uptime (which was very appealing as ADSL outages were very common) but you paid a hell of a lot of money per 64kbps of uncapped bandwidth. You were looking at something like $400-$500 a month per 64k for the cheapest support package. And we weren't even the most expensive. There was a law firm that was paying something like $30k a month for their pimped out 2048kbps line.

Thank God things have improved dramatically there in the last decade (at least in terms of internet speeds).

Wow, so all this was happening circa 2006?

And before. Most people were still on dialup until I think maybe 2010-2012. Wireless ISPs became really popular during all of this because they could offer better service, better uptime, better speeds, and QOS for things like VOIP. Bandwidth and data usage management became so important that ISPs were also selling managed proxy servers and on-premise email servers to businesses because it was cheaper than having to pay for additional 1GB data caps.

The two primary causes for this situation was that the sole wireline telecomms company in SA and there were only 2 undersea data cables connecting SA (and I think Africa) to the rest of the world. Telkom was semi-private and state-owned so they had no incentive to improve things and also had to pay through the nose for access to the two undersea cables.

However, things started to improve when more undersea cables got laid down (lowering bandwidth prices and improving international bandwidth) and the government started lowering entry barriers so that Telkom stopped being such a monopoly.

Out of curiosity, is there any reason to get a T3 today? I assume anywhere that it is available you can also get DSL for two orders of magnitude less.

No, unless you want to break it out to a lot of voice lines, 30 T1's to be exact.

Just about anywhere a T3 is you can get ethernet at the same or higher speed for less money.

It is 30 T1s in theory, but the physical connectivity is RJ-48 for T1 and x2 coaxial for T3. Both can be channelized into voice, or un-channelized for data...

Yes, exactly. I was trying to say that a person would be better served using ethernet if they wanted data. But some older phone systems still work well with tdm style T1 and T3...

>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.

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 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.

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)

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.

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.

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 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.

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.

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

Looking at 1yr reserved fully upfront pricing, the price cuts were ~9% across the board (except 10% for micro and 7% for nano).

This seems like a big improvement for nano, micro, and small which now have 2 vCPUs and the same credits and memory as before.

However, the larger instances are stuck with the same vCPUs and memory, but less than half the CPU credits!

Does 2 vCPUs on the nano get us twice the CPU cycles for multi-threaded workloads?

Regretting my 3-year non-convertible t2.nano reserved instances.

The 9% decrease is only for Linux. For Windows, there is a significant price increase.

For example, for Windows (VPC), a t3.2xlarge reserved for 1 year is a 19.21% more expensive than a t2.2xlarge.

Did anyone listen to the 'Amazon Polly' audio that accompanied the article?

I haven't used any of Amazons text-to-speech apps before now, but I found it a little creepy with the way it "inhales" between sentences...

Also, it pronounces "Gigabyte" as "Gibabyte" and "Ji-be-bies" (2:55). This made me giggle.

How does this compare price wise with t2 instances?

It specifies how cheap the t3s can be but not the difference between t2 and t3.

You can find pricing details at https://aws.amazon.com/ec2/pricing/on-demand/

Pricing varies from region to region, on-demand vs. reserved instance, etc.

The general answer is they are cheaper than the same sized t2 version.

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

The blog post mentions this:

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

But that (rather important detail) seems to have been omitted from the pricing page?

Farther down the page it talks about T2 Unlimited pricing, which is the same thing here. It does look like it needs to be updated to include details for T3 as well, however.

I'll submit some feedback to the documentation team about getting that updated.

(Disclosure: Not posting in an official capacity)

Will these be available for RDS?

An RDS T2 is not an EC2 T2. Just named similar.

Except T3 would imply newer underlying hardware.

I don't have any insider knowledge on this, so your guess is as good as mine on this one :)

If you have an account manager or solutions architect, they can probably help you connect with the right people to ask for details, though.

(Disclosure: Still not posting in an official capacity)

Baseline pricing looks about 10% cheaper for workloads that won't trigger lots of bursting. This looks like a good a choice for services that aren't CPU bound.

So what would be the benefit of running a T3 nano instance over a T2 nano instance? The price is almost the same. Is T3 faster?

Newer more efficient hardware. Workloads finish faster.

You get an extra vCPU for the same memory.

Bursting can cost up to an extra $37.5/month per instance. Bettrer make sure you keep an eye on that CPU usage

You only start getting billed long after your instance would have been throttled in the Standard model (or if you terminate with a surplus balance)

If your CPUCreditBalance didn't normally get near zero before it's mostly just insurance against grey failures. It also makes the credit model radically easier to reason about.

I hope this gets Google Cloud to expand their burstable offering.

Do these instances support AVX-512?

Yes, Amazon says so in the linked article

Thanks, I guess I failed the RTFA test.

I had assumed that this detail is normally hard to dig up, so it is nice to see Amazon being up front and clear about it.

AWS nets $20+ million a day in profit so these new machines will probably help us save like Amazon warehouse workers save on toilet breaks by pissing in bottles.

Reply on news.ycombinator.com