Cloud Mercato tested CPU performance using a range of encryption speed tests:
Cloud Mercato's tested the I/O performance of this instance using a 100GB General Purpose SSD. Below are the results:
I/O rate testing is conducted with local and block storages attached to the instance. Cloud Mercato uses the well-known open-source tool FIO. To express IOPS the following parametersare used: 4K block, random access, no filesystem (except for write access with root volume and avoidance of cache and buffer.
.png)


the T series is more suitable for non-performance-verified test environments

the T series is more suitable for non-performance-verified test environments

T2 is a burstable instance type If you run out of CPU credits, CPU is throttled and performance degrades

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

Thank you for this article. We have T instances for EC2 and RDS and we are expecting some very strange performance behavior. Do you have plan to test RDS?

This is super well documented by aws themselves and if you understood how they work before creating the article then you probably would not have written it. Please do research before writing scare articles just for clicks. That’s just lame brother.

Thank you for this article. We have T instances for EC2 and RDS and we are expecting some very strange performance behavior. Do you have plan to test RDS?

This is super well documented by aws themselves and if you understood how they work before creating the article then you probably would not have written it. Please do research before writing scare articles just for clicks. That’s just lame brother.

I think the discrepancies can be attributed to the choice of the t-style instances. They are generally over committed.

Aren\'t \'t\' instances burst instances? They need to be under constant load for a long time before their burst credits for CPU, memory, network and EBS run out, after which they fall back on their baseline performance.

T2 instances do not have Unlimited mode turned on by default. Without Unlimited mode turned on, once the CPU credits have been exhausted, the server goes into a shallow resource usage state. Its CPU performance and network performance are lessened considerably until the CPU credits have accumulated again. We've seen this first hand on quite a few occasions now, even causing production outages.

Thank you for this article. We have T instances for EC2 and RDS and we are expecting some very strange performance behavior. Do you have plan to test RDS?

This is super well documented by aws themselves and if you understood how they work before creating the article then you probably would not have written it. Please do research before writing scare articles just for clicks. That’s just lame brother.

You can count t2 as upgrade of t1. In general t2 offer faster access to memory and disk compared to t1.

I remember there is a thread talking about whether aws over-sell their cpus. If I can not get consistent 100% cpu usage then it is. But whatever it its, the \"40%\" and \"60%\" in the video still strange and can not be clearly explained.

But it\'s a fact that the hardware specs for e.g. `t2.large` and `m4.large` are either exactly or roughly the same. That means even if you burst on a `t2` you will get the same performance as on `m4`.

Could you explain how can t2 get 60% higher than m4? From t2 instance document, the \"bursting\" is from baseline to 100%, not higher. Just now I launched a t2.medium and a m4.large, made a test using sysbench in ubuntu, they gave almost the same performance.

I have made cpu benchmarks and m4.large result was same with t2.large burst..

But with t2.large, you can only use 60% of a single vcpu, average 30% for each of the two vcpus. Even considering the \"cpu credits\", t2.large seems far weak than m4.large.

This is false information. Instance retirement event is just host maintenance event. NOT THE replacement process.

So, there is no specific date to end support for older instance type, they are retired gradually and we are only notified through scheduled events?

For detailed information on the process and implications of instance retirement, please refer to the following resource: [Understanding Instance Retirement on AWS](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html). Additional [Scheduled events for your instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-instances-status-check_sched.html)

That's a great news! Thank you for the link