Burstable Performance Instances

As discussed in the previous blog Burstable Performance Instance Part I,  AWS burstable instances can be seen as customer-first strategy, especially when it is a “lift-and-shift” of Data center VMs to AWS or internal to the cloud, whose workloads don’t have prolonged high CPU usage. You can explore and leverage burstable instances for variety of general-purpose workloads such as Microservices, Dev/Test, Virtual desktops etc. to reduce your cloud expenditure. In this blog, let us discuss more on CPU credit model in relation with Burstable compute power.

AWS has launched transparent and traceable CPU credit model, with which there is a visibility towards earning CPU credits when there is less or no usage of compute power and the earned CPU credits could be used to burst the compute power. In other words, “Bursting mechanism is based on the CPU credits”.

Earlier, with standard option, it was indistinguishable for the users and their general-purpose applications for running on burstable instances. With the introduction of new mode “Unlimited”, you need not have to keep track of CPU credits & their workloads can use the compute resources whenever it needs and for as long as it needs without the need to worry about the credits.

What type of workloads can benefit from Burstable instances

1. Most general-purpose instances that don’t need fixed CPU resources.
2. Good for applications that occasionally need quick access to high CPU. Key thing to make sure is that the instance can react to very small spikes at the scale of microsecond granularity
3. Instances that are idle or need moderate CPU for majority of the time
4. Instances that need to sustain high CPU whenever and for as long as needed.
5. Examples of workloads
   1. Microservices
   1. Dev & Test environment
   1. Virtual Desktops
   1. Small & Medium Databases
   1. Interactive Applications
   1. Code Repositories

How to choose the Burstable instance categories

In majority of the cases, it is recommended to go with latest generation instances due to enhanced compute power.

Among the burstable turbo instances viz T2,T3,T3a,T4g, choose the one that is more appropriate for your workloads. Let us consider T3 instances in the below example (As T4g has been released in 3^rd week of September 2020, not many specific use cases/ stats are available yet)

How to choose the Burstable instance sizes

Once the burstable instance category has been identified (for eg:T3), then it is essential to choose the instance size viz. nano/micro/small/medium/large/xlarge/2xlarge as per the below recommendations

It is advisable to monitor the CPU utilization of the EC2 instances by using Cloudwatch monitoring tool for a period of at least 2 weeks and arrive at baseline/average CPU utilization, which helps in choosing the right instance size.

Be familiar with CPU credits

Once you are clear with the burstable instance category and the instance size, it is key to have an idea about the CPU credits such as

• The rate at which CPU credits are earned per hour
• The max # of earned CPU credits that an instance can accrue
• Max limit of burstable hrs/day
• Baseline utilization per vCPU

As the instances are idle, or using moderate CPU, it will start accruing CPU credits, then it can use that CPU credit to burst at later period. As it can’t burst more than 100%, the max# of credits that can be earned per day are 4,608 (In this example, of t3.2xlarge, the max CPU credits would be CPU credits per hour * 24 hrs = 192 * 24= 4608).

If the instance is running <40% of CPU usage, 192 CPU credits can be earned per hour. If the same continue, it can earn up to 4608 CPU credits/day which will be around 9 hrs burstable using all vCPUs.

Under what scenarios, Burstable instances (’T’ category) are cheaper than M category instance types

At times, you land up in a situation to decide whether to go with T type instance or M type instances and which one is the most cost-effective solution.

AWS has come up with a concept called “Break even CPU usage Threshold”, which is the main deciding factor to address this scenario

In the below example, Baseline CPU of T3.large is 30%. If the instances are bursting at 100% throughout the time, then the customer would end up paying quite a lot on T3.large, which is roughly of 1.5 times , the cost of running on M5 large. So, for the instances that need fixed CPU usage, it is better to go with M4 or M5 instance categories.

If the instances that don’t need fixed CPU, and if the Average CPU is somewhere around 42.5%, then the price would be exactly what it is on M5.large, on T3.large.So this is the breakeven price for T3.large, compared to M5.Large.

If the average CPU is anywhere between 0 to 42.5%, then it would result in savings by running on T3 instances, still benefiting from the same performance that can get from M4 or M5 instances. So, theT3 instances would be cheaper for the workloads than running them on M5.

How to calculate Break-even threshold and price

1. Calculate the price difference between T3.large and M5.large . In this example, under column E, the value is $0.0125.
2. The charge per vCPU hour for t3.large is $0.05. Convert that into vCPU minute by dividing $0.05 with 60 mins = 0.05/60= $0.000833 . In this example under column H.
3. Divide difference in price with charge per vCPU minute i.e $0.000833/$0.0125= 15 mins. In this example divide column E/H. It gives the # of minutes that the instance can burst at 100% CPU.
4. Take 100% CPU and spread it across 60 minute interval, it will give the incremental CPU above the base line for which it can burst at the breakeven price.
5. We know that 15 is 25% of 60. This is for 2 vCPUs. If we consider per vCPU,  it will come to 12.5%.
6.  In this case it is 12.5% incremental CPU , on top of base line 30%, giving you the break even as 42.5%.

       Note: Same formula applies across any instance types

Pre-requisites for Switching to T3 instances

You need to have the right drivers to run on new Nitro system that T3 runs on

• Must have the NVMe (Nonvolatile Memory express) drivers installed.
• Must have the ENA (Elastic Network Interface) drivers installed.

Once done, you can switch to T3 instances through AWS console or CLI

AWS console Select the EC2 instance Stop the instance Go to Instance settings Change instance Type Select the appropriate instance type Restart the instance

Key considerations

• Instances accumulate credits when idle and consume them when running.
• For running instances, credits never expire.
• For stopped instances, credits are stored for up to 7 days and then they expire.
• If the average CPU utilization of a T3 instance is lower than the baseline over a 24 hour period, the hourly instance price covers all spikes in usage.
• If the instance runs at higher CPU utilization for a prolonged period, there will be an additional charge of $0.05 per vCPU-hour.