t2 anyone?

I read with interest Amazon's recent announcement about the new T2 range of instances with burstable performance. On the face of it, they look like the perfect fit for unpredictable workloads, such as API servers for MetaBroadcast's Atlas API.

The API is served by instances running in an auto-scaling group, where we use various metrics to trigger changes to the number of instances. However, there's always going to be a lag between instructing the group to scale up and having enough resource to deal with a traffic spike. That can be as much as a couple of minutes, by which time the spike may have gone. The obvious solution is to over-provision, but your AWS bill at the end of the month will be more than it need be.

t2 instances to the rescue?

As I said, T2 instances offer burstable performance. This means you're paying for a baseline performance, and then get credits to use more CPU for some of the time. Taking the example of a T2 medium instance, you get 40% of a CPU as a baseline performance, then 24 CPU credits per hour. Each credit entitles you to increase your CPU usage to 100% for a minute, and will roll over until you have a day's worth of credits in the pot: 576 in this case.

As the credits can be used immediately as demand increases, you don't have the ramp-up delay that causes problems with adding new instances to an auto-scaling group to cope with a spike.

There are a couple of new CloudWatch metrics: CPUCreditUsage and CPUCreditBalance. These could be used to introduce new T2 instances into an auto-scaling group if you see you're often running out of credits - an indication of being under-resourced.

local storage

This section will be short: there is none. Fine for our API servers, which are completely stateless, but may not suit every use case. If you need local storage then it's EBS volumes with the associated cost and latency that brings.

vpc only

As with other new features released in AWS, T2 instances are only available in VPC. Not surprising, given EC2 "classic" is being phased out, but it highlights the need for anyone still on classic to switch to VPC as soon as they can. That's something we're in the process of doing at work, too.

cost comparison

So, is it worth it? It's a little tricky to do a direct cost comparison, since Amazon aren't publishing their normalised CPU capacity measure, the ECU, for T2 instances, but we'll take a look the bang you're getting for your buck.

I've chosen to compare the t2.medium and c3.large instance types, since they're similar in terms of memory and CPU, the measures we're interested in for our API servers.

^*I did try to guess a value for the ECU of a t2.medium instance, but I wasn't able to do so with enough certainty to make it useful. If you assume all credits are used each hour, you'd get 64% of maximum CPU per hour by my reckoning. However, the AWS blog post mentions that it's a percentage of a single CPU, which compares to 2 vCPUs on a c3.large. You appear, then, to be a whole lot worse off with a t2.medium than a c3.large for CPU, even with the discount in price.

conclusion

We continue to be impressed by the new features AWS add to their offering. The vagueness of the information available means that we don't yet know if these new instance types will result in a cost reduction or just smoother scaling of resoures as demand increases. As soon as we're done with our VPC migration, or perhaps as part of it, we'll be spinning some up and benchmarking them to find out. If you've already used T2 instances for production workloads, I'd love to hear from you. It happens to be #MetaBeerTalks on Wednesday, so why not pop by and we can chat then?

_{This originally appeared on our company blog. Picture credit: Nomadic Lass}