The unlimited mode for t2 and t3 instances is a very interesting concept, as it allows you to run a burstable workload, without having to worry about running out of credits.
CPU credits are priced 0.05 USD per vCPU-hour (for Linux instances). This means that there are multiple instance types that can run the same workload for a different price, depending on the base price of the instance and how fast it earns credits.
Read on to see which instance might be a good fit for you.
Things we know
- The only CPU related difference inside the same instance family is the number of available CPUs, ie. a t3.nano gets the same kind of processors as a t3.2xlarge.
- Instances and CPU credit pricing differs for Linux and Windows. In this blog post we only look at Linux instances.
Assumptions we made
Because comparing instances across different families is hard, we assume the following:
- CPU performance on same generation instance families are equivalent (they’re not always).
- A workload that can run on a t instance can run on a m instance of the same size.
- The us-east-1 pricing is representative for other regions too.
- AMD instances are not directly comparable with instances with Intel processors.
In practice this means that we will be comparing t3 against m5 and t2 against m4 while only looking at the number of available CPUs as a difference between the two.
TL;DR
Pick the smallest burstable instance that matches your requirements, and switch when you start paying more than the equivalent non-burstable instance. If there is no equivalent, switching will only be a benefit in the edge case where you use almost all the available CPU.
For cost reasons it never makes sense to go to a bigger t2 or t3 instance, and if you can go smaller you save money without getting less processing-power (you do get less memory and/or networking throughput). If both a t3.nano and a t3.large can run your workload you should pick the nano, even if that means paying more burst credits.
The long explanation
The conclusion might sound logical in retrospect, but considering that both changing size and changing family are things you can do, it was interesting to make a full comparison. To make sure we didn’t miss any edge-cases, we plotted the (monthly) costs versus the CPU-usage (in percentage of one vCPU, so it’s expected to see more than 100% for instances with multiple CPUs), and used those graphs to write the above tl;dr. You can see the graphs for t3-m5 and t2-m4 here:
t3 and m5 instances
t2 and m4 instances
The easiest way to read these graphs is to start on the x-axis and pick the CPU-usage that you expect. If you draw a vertical line from that point, you’ll see every instance that can provide that level of CPU. By looking at the y-coordinate you see the monthly cost. Since your line is going up from the x-axis, picking the first instance you cross will give you the lowest price.
In both graphs the lines of the nano, micro, and small instance seem to (almost) overlap, but if you look at the actually cost the smallest ones are slightly less expensive for the t2 and t3 family. You can see this more clearly in the graphs below, where we only kept the instances with the lowest cost for that particular CPU-usage.
t3 and m5 instances: only the lowest cost
t2 and m4 instances: only the lowest cost
In practice the slight difference will probably not impact your bill in any meaningful way. But It is interesting to compare the graphs above with the same graphs for the AMD-based instances. Where the most “optimal” instance does change between the t3a.nano and the t3a.small.
t3a and m5a instances
t3a and m5a instances: only the lowest cost
Finally, if you are truly only CPU-bound and using more than 1 vCPU, switching to c5 instance for everything that does not fit in a t3.medium is a good idea.
t3, m5, and c5 instances
t3, m5, and c5 instances: only the lowest cost
We encourage you to look at the graphs and decide for yourself which strategy makes the most sense for you. Depending on the amount and size of instances it might make more sense to very infrequently pay a small premium than to spend a lot of time to pick the slightly less expensive instance.
