During the 90s, when I was playing Prince of Persia and Pac-man games on my PC, I was often using the turbo button of the CPU to manipulate the speed of the processor. That simple button would give me a chance to finish the game by slowing down the movement of the ghosts in the Pac-man game. Guess what? Amazon has now put the turbo button in the cloud with its next-generation micro instances called the T2 instances.
Though t1.micro instance type existed for nearly 4 years, it is not considered to be production ready. But with the new t2 instance types, Amazon made it is viable to run production workloads on these cheap, burstable-CPU based instances.
The key difference between t1.micro and t2.micro is the way the CPU bursting happens. It is not possible to predict or control the performance of t1.micro instance type. The official specs of t1.micro states that it can burst up to 2 ECUs with no guarantee of getting the maximum performance. On a side note, AWS has since moved away from the notion of ECUs to vCPUs. With the T2 instance types, you can accumulate points that can be redeemed within 24 hours to get predictable performance. AWS calls these points “CPU Credits” which are collected by your instance when it is idle. Every hour that the instance has been idle, it starts collecting the CPU credits.
Each instance can accumulate up to a specific number of credits beyond which the credits are not applicable. In case of t2.small, it can accumulate 12 CPU Credits per hour up to a maximum of 288 (12 CPU Minutes/hour * 24 hours) credits in a day. CPU credits cannot be carried forward to the next day. You either use them or lose them. In a scenario where there is a sudden spike and your instance has enough CPU credits, the accumulated credits get consumed to deliver higher performance. But what happens when you run out of the required CPU credits to sustain the same performance? Well, it falls back to the default level of performance that the instance type is originally assigned. Amazon calls this default level of performance as the “Baseline CPU Performance”.
Each instance type in the T2 family has an assigned baseline CPU performance. For example, t2.small is designed to consume 20% of a core in its default state. In the event of spikes, it leverages the CPU credits to go beyond the assigned 20% to draw more CPU power. To make it easy to track the CPU credits, Amazon CloudWatch has two new metrics called CPUCreditUsage and CPUCreditBalance. CPUCreditUsage tracks the expenditure of credits over time while CPUCreditBalance is to track the accumulation of credits over a period of time. That makes it easy to visualize the usage patterns and the available credits for a specific instance.
The T2 instance types are ideal for running dev/test, blogs and dynamic websites that don’t demand consistent CPU performance. It’s interesting to note that Amazon is making T2 instances VPC-only. This is a mechanism to move newer workloads to VPC by default.
With Google Compute Engine preferring to go the sustained use discount route, Amazon EC2 is following a similar path. I won’t be surprised if AWS takes the concept of CPU credits beyond T2 instances to offer discounts for all underutilized EC2 instances.
