The Misunderstood t2 Instance Type

Sat, 16 May 2015

Amazon EC2 has over 40 different instance types and keeping track of them all can feel a little daunting. To simplify it, pay attention to something called an “instance family”. This is the prefix before the period in the instance name, for example the m3.large instance is in the family “m3”. A few basic rules about instance families:

• Anything with a 1 (such as c1) is a “Previous Generation” family. m2 is also Previous Generation. These instances are on older hardware and have much more powerful and cost-effective counterparts in “Current Generation”. The only reason to be running a previous generation instance is that you can’t easily upgrade or you are committed to a reserved instance.
• c3 & c4 are compute-intensive: They have the most CPU per dollar and the highest ratio of CPU to RAM. Great for busy web servers, build systems, and scientific computation.
• r3 is memory-intensive: The most RAM per dollar and the highest ratio of RAM to CPU. Great for databases.
• m3 is balanced RAM & CPU: Great for many web server applications and other general uses
• t2 is the lowest cost instance type, with a “burstable CPU”

What? Burstable CPU? t2 was released in 2014 by AWS and remains, in our opinion, one of the least appreciated instance types. They are very low cost, from under $10/mo to $37/mo for Linux in the US East Region; significantly less expensive than the next size, m3.medium, and in the case of t2.medium, significantly more performant for bursts: t2.medium has 2 cores and 4GB of RAM.

To make the idea of a “burstable CPU” transparent, AWS introduced the idea of CPU Credits. Every minute of the day, an instance adds credits. Each instance also has a baseline CPU level: 10% for t2.micro, 20% for t2.small, and 20% for each of 2 cores for t2.medium.

The instance will always have this baseline capability. But when it requires more CPU, it simply uses some of its CPU credits, and it can have up to 100% of the CPU. 1 CPU credit equals 1 core running at 100% for 1 minute. 1 credit would also equal 1 core running at 50% for 2 minutes. When the CPU burst is over, the instance starts adding credits again. Credit calculations happen at millisecond-level resolution.

You can watch this activity in CloudWatch, like in the below case. You’ll see CPU credits coming and going by the minute…

Many people hear this and think, “Well, that’s nice for dev/test, but I need guaranteed CPU for production!” However, the reality is more complex.

In truth, even in this cloud era where you can resize on a whim, most servers are still over-provisioned to account for bursts; actual CPU usage is usually 5-20% for even moderately busy applications.

Let’s examine the t2.medium in more detail to understand this:

• Baseline CPU of 2 cores @ 20% each (or 40% in aggregate of a 1 core)
• Credits are earned at a rate of 24 per hour
• Maximum credit balance of 576

Imagine you start the instance on Friday. Very quickly over the weekend, it builds up a full 576 credits. Then on Monday morning, higher user activity begins on your app and CPU begins using over 20% on each of 2 cores.

You could run at a sustained 50% CPU on 2 cores and use 1 credit per minute, or 60 per hour. However you are also still earning credits at 24 per hour, so your net loss per hour is only 36 credits. You could run like that for 10 hours, say from 8am to 6pm, and still have 216 credits in your balance. Then you would have 14 off-hours to build credits back up, and you would get almost all the way back to 576 (the max credit level).

That is a very significant CPU load, all business day long, totally within the bounds of the t2.medium. This is not what people usually think of when they hear “burstable CPU”.

So take a closer look at the t2 instance family. Your cloud budget will thank you.