AWS T2 Instances – All you need to know

Amazon EC2 service has over 70 different instance types. As of writing this article, there are around 10 EC2 families with further division within them based on generation. AWS launched the T2 family Instance type in the year 2014 with burstable performance.


 T2  Instances

Let’s see the official definition given by Amazon for the T2 family before breaking it down and analysing it individually.


T2 instances are Burstable Performance Instances that provide a baseline level of CPU performance with the ability to burst above the baseline. The baseline performance and ability to burst are governed by CPU Credits. Each T2 instance receives CPU Credits continuously at a set rate depending on the instance size.  T2 instances accrue CPU Credits when they are idle, and use CPU credits when they are active.  T2 instances are a good choice for workloads that don’t use the full CPU often or consistently, but occasionally need to burst



T2 Instance Specification

Instance type Initial CPU credit CPU credits earned per hour vCPUs Base performance (CPU utilization) Maximum earned CPU credit balance
t2.nano 30 3 1 5% 72
t2.micro 30 6 1 10% 144
t2.small 30 12 1 20% 288
t2.medium 60 24 2 40% (of 200% max) 576
t2.large 60 36 2 60% (of 200% max) 864
t2.xlarge 120 54 4 90% (of 400% max) 1296
t2.2xlarge 240 81 8 135% (of 800% max) 1944


Let’s Deep Dive

In order to understand the specification, it is important to understand the meaning of the terms used. Let us analyse those using the below scenario.



You travel to office daily in your car which is located outside of city. Your car has a max speed of 100 MPH. Within the city you maintain an average speed of around 20 MPH. But once you reach the outskirts, you have the option and the capacity to go beyond the average speed of 20 MPH upto 100 MPH. Once you reach your office, you park your car and it remains idle.  The take away from this is that though you have a top speed of 100 MPH, you only use it a fraction of time when needed and also your car remains idle when not in use.

Many interesting compute workloads follow a similar pattern, with modest demands for continuous compute power and occasional needs for a lot more.

The above statement depicts the principle behind the inclusion of t2 instances in the EC2 service.


Baseline and Burstable Performance

The t2 instance family type provide a baseline level of CPU performance. Consider the t2.small instance from the above table. It contains a single vCPU. The base performance for this instance is 20% ( We can consider this as the average speed of the car ). It can burst beyond the base performance of 20% upto 100% when the situation demands by making use of available CPU credits.

On the other hand, instances starting from t2.medium and beyond have more than one vCPU’s. In this case, the base level performance increases further. For example, the base performance for a t2.large is 60% of 1 vCPU and it can go upto 200%. A t2.large instance has 2 vCPUs, therefore the CPU utilization for a t2.large instance operating at base performance is shown as 30% in CloudWatch CPU metrics (i.e, it is shown in percentage of 100 in CloudWatch).


CPU Credits

One CPU credit is equal to one vCPU running at 100% utilization for one minute. This equates to one vCPU running at 50% utilization for two minutes or two vCPUs running at 25% utilization for two minutes. 

Each T2 instance starts with a healthy initial CPU credit balance and then continuously  receives a set rate of CPU credits per hour, depending on instance size. For example, in the case of t2.small, whenever the instance uses fewer CPU resources than its base performance level of 20%, the unused CPU credits are stored in the credit balance for upto 24 hrs, building CPU credits for bursting. When this instance require more CPU resources than its base performance level of 20%, it uses credits from the CPU credit balance to burst up to 100% utilization. 

Apart from accruing CPU credits by using fewer CPU resources than its baseline, 12 CPU credits are added on hourly basis for t2.small and an initial credit of 30 is added during the launch of the instance. The maximum CPU credit that a t2.small instance can earn is 288 ( This does not include the initial CPU credit of 30 ). So at a credit cap of 288, t2.small has a reserve of nearly 4.8 hours.

The more credits your T2 instance has for CPU resources, the more time it can burst beyond its base performance level when more performance is needed. 



The CPU credit balance for an instance does not persist between instance stops and starts; stopping an instance causes it to lose its credit balance entirely, but when it restarts it will receive its initial credit balance again.


Track CPU credit balance

The CPU credit balance metric is available as part of cloud watch monitoring. It is essential to set an alert to notify if the credit drops below a specific threshold in order to take precautionary measures. This can also be helpful in setting a baseline for choosing the instance type within the t2 family based on your application’s need.


When can a t2 instance be a great fit?

Plenty of different usage profiles could fit the pattern which we discussed above. An environment that utilizes burst infrequently, allowing the restoration of CPU credits to happen, t2 family is operationally fine.  There are many good use cases for this: development environments, websites with periodic traffic spikes, build servers, etc. 


When t2 instance will not be a fit?

If your workload CPU requirements are more stable, then t2 instances aren’t the best choice. If your environment is in a steady burst mode, consuming all available credits and cores throughout the day without a chance to recover CPU credits, this is a sign that a larger instance or different, high-performance family, might be a better fit.


EBS Volume  – I/O Burst

Apart from CPU burst what we discussed above, the burst performance is extended to Input/Output for General Purpose SSD EBS volumes as well. If you are interested to know more on that, you can refer this article where we have benchmarked IOPS ( Input Output Per Second ) performance between AWS and Digital Ocean and explained how the IOPS Burst  work in AWS.



Established in 2016, a community where system admins and devops practitioners can find useful in-depth articles, latest trends and technologies, interview ideas, best practices and much more on Devops

Leave a Reply

Your email address will not be published. Required fields are marked *

20 − five =

Hello. Add your message here.
Any Udemy Technical course for $10 Redeem Offer