M5 vs. T3: How to Choose the Right Amazon EC2 Instance

Amazon EC2 has two instance families made for general purpose use cases. But which is better? We’ll look at the latest generation of each family to help you make your decision between m5 vs. t3 instances.

AWS has two Amazon EC2 families that are targeted toward general use cases — the M family and the T family. At first glance, the specs seem very similar, but there are a few big differences. Let’s compare the latest generations, M5 and T3, since they offer the best price/performance ratio and will usually be the best place to look.

Burst or Consistent Workloads

M5 is meant for workloads that have consistent behavior, with a balance of CPU, RAM and storage. For a normal application server workload, M5 is often the best choice, and many companies run their production applications on M instances.

M5 is a good place to start if you’re not sure about the performance characteristics of your application. Because CPU, RAM and storage are balanced, it’s easier to see if one of them is holding your application back. For instance, you might learn that your application is memory intensive, so you might decide to switch to the memory-optimized R family.

T3 is also aimed at general purpose workloads, but at a lower price point than M5. The key difference is that T3, like all T instances, is burstable, and ideal for applications that are CPU-intensive in short bursts, as opposed to needing 100% CPU utilization all the time.

For example, continuous integration servers or build servers often have lots of short bursts while a build is going on, but are idle the rest of the time. The average CPU usage is low, but when the build is running, you’re getting great performance, can do the build quickly and keep your developers happy.

Another good fit is virtual desktop applications or line-of-business applications. These have longer bursts during business hours, but there’s not much going on during evenings and weekends.

An example of a bad fit is video transcoding. This has high CPU usage all the time, so it needs the full-time high performance of an M5.

Do You Need a Smaller Instance?

If your workloads can run on smaller instances and don’t require lots of memory, then T3 might be your best bet. The smallest M5 instance is m5.large, with 2 virtual CPUs (vCPU) and 8GiB of memory. T3 instances have more options on the smaller end of the scale. All the smaller sizes, from t3.nano to t3.medium, have 2 vCPUs with memory specs from 0.5GiB to 4GiB. Once you get to the t3.large, it’s the same as the m5.large, with 2 vCPUs and 8GiB of memory. (To dig into the full numbers, check out Amazon EC2 Instance Types.)

m5 vs. t3 – A Comparison

Let’s get down to brass tacks and compare apples to apples by looking at t3.large and m5.large. We’ll start with the specs:

Of course, you always want to consider cost. Here’s an On-Demand price comparison for the US West (Oregon) region.

It’s obviously cheaper to use the t3.large, but, aside from whether the workload comes in bursts or not, there something else to consider. Like all M5 instances, m5.large offers dedicated EBS bandwidth, while t3.large EBS transfers can be throttled down. If you have an application that makes heavy use of storage and requires a lot of bandwidth between the instance and its EBS volumes, then m5.large might be the better fit. For example, look at a media site with many concurrent visitors. Those visitors spend time reading, watching videos and interacting with the content. To give them the best experience possible, you need that guaranteed bandwidth.

CPU Credits & Unlimited Mode

The amount you pay for an M5 instance is always the same. After all, they’re designed with consistent workload in mind. Instances in the T family, including T3, compensate for their burstable nature by the use of CPU Credits.

A single CPU Credit is equal to one vCPU running at 100% utilization for one minute, and each instance earns a set rate of CPU Credits per hour. A t3.large instance, for example, earns 36 CPU Credits per hour. Comparing this rate to CPU utilization gives you a baseline performance (as a percentage) for each vCPU that’s the breakeven point for earning or using CPU Credits. A t3.large instance has two vCPUs. Divide 36 by two, then 18/60 minutes and you get a baseline rate of 30%. When the vCPU utilization is below 30%, more CPU Credits are being earned than used, and those earned CPU Credits are accrued to cover future bursts.

AWS looks at the accrual model as a bucket of CPU Credits, with a capacity based on how many credits an instance can earn in 24 hours, which is why a t3.large instance can accrue up to 864 credits. That doesn’t mean they all have to be earned over the same 24 hours, though. Accrued CPU Credits on a running instance don’t expire. For T3 instances, your CPU Credit balance will persist for seven days after an instance is stopped and can be used if you start an instance up in that time. This is an advantage over T2, which loses balances instantly when the instance stops.

But what happens if you need more capacity than you have credits? That’s where Unlimited Mode comes in. All T3 instances are, by default, launched in Unlimited Mode (as opposed to Standard Mode). With Unlimited mode, you can spend Surplus Credits once your accrued CPU Credits run out, with a maximum of what the instance earns in 24 hours. Once the Surplus Credit maximum is reached, you’ll be charged for additional Surplus Credits at these rates:

• $0.05 per vCPU-Hour for Linux, RHEL and SLES
• $0.096 per vCPU-Hour for Windows and Windows with SQL Web

This method prevents the vCPU from being throttled back or stopped when you need it to be running at full speed. As a note, all CPU Credits and Surplus Credits are computed at a millisecond-level resolution, so you don’t have to worry about overspending.

The baseline and Surplus Credit use give you a method of comparing costs when deciding between T3 and M5. The average CPU utilization over time should be at a threshold where the total price you’d pay for a T3 base instance plus any surplus credit will still be lower than if you ran the same workload on an M5 of equal size.

Do You Have the Data You Need to Decide?

In the end, the choice will come down to your cost and usage. There are dozens of variables in play, from your cloud architecture to the number of users to your work schedule. The only way to know for certain is to have full visibility into how you’re using the cloud. That’s where IBM Cloudability is invaluable. Our cloud cost management platform gives you the visibility you need, and it includes features like Rightsizing that can make recommendations to lower your costs without lowering performance.

Based on past usage data, this recommendation is to replace an m4.xlarge with a t3.large instead of an m5.large.

A click to another option shows that an m5.large would provide similar specs, but would lower your potential savings by 6%.

As you can see in the above examples, it’s not always a cut and dry solution. On the surface, an M4 instance should be replaced with an M5 instance, but the actual usage data didn’t show that. Because the CPU use is so low on average, the T3 instance was a much better fit, saving money without lowering performance.

And that’s really the key question for choosing between the two: Which instance, M5 or T3, will allow me to meet performance expectations and cost the least at the same time?

When you have enough visibility, the answer can be very clear.

——

Get the data you need to gain actionable insights about your cloud architecture. Sign up for a free trial of Cloudability today!