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.
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.
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)
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.
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
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!
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).
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).
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.
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.
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...
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.
45 comments
[ 4.6 ms ] story [ 100 ms ] threadIt specifies how cheap the t3s can be but not the difference between t2 and t3.
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)
> 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?
I'll submit some feedback to the documentation team about getting that updated.
(Disclosure: Not posting in an official capacity)
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)
This seems to be the same as the T2 unlimited instances. Interesting that it's now the default and only (?) option.
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)
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)
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.
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.
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.
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.
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
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).
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.
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!
Regretting my 3-year non-convertible t2.nano reserved instances.
For example, for Windows (VPC), a t3.2xlarge reserved for 1 year is a 19.21% more expensive than a t2.2xlarge.
Just about anywhere a T3 is you can get ethernet at the same or higher speed for less money.
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.
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.
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.