Since Amazon released the “t2” instance class for EC2, a problem I noticed that happens more frequently than it should is lack of an understanding of how the credit system works.
One of the most common issues is when an EC2 instance runs out of CPU credits and becomes throttled, causing an impact on users.
This article covers how to leverage cost savings of bursting services while keeping high-availability.
EC2: t2 and t3 instances
The family of t2 and t3 instances are around 30% cheaper than their equivalent in other instance type families.
To achieve such reduction, AWS introduced “burstable” CPU credits. These credits are consumed every time the CPU is used and is replenished at a fixed rate, depending on the instance type.
As an example, if you create a t2.micro instance (very popular as it’s part of the free tier), wait until your credit balance is full and then start using 100% of CPU, it will run out of credits in 2 hours and 24 minutes. After that the instance will be limited to use only 10% of the CPU.
But how to calculate that?
Each instance type has a rate of credits earned and a maximum value. As per July/2020, the values are:
For t2.micro from our example. The max credits it holds is 144.
A CPU credit provides for 100% utilization of a full CPU core for one minute.
The t2.micro has 144 credits and 1 CPU core, which means 144 minutes of 100% CPU, or 2h24m.
How about t3?
T3 is a newer generation. Overall the instances gain more credits for the same or cheaper cost, so the only reason to continue using T2 would be because of the free tier or if your region/AZ doesn’t support this type.
Unlimited
To prevent throttling when credits run out, you can enable T2/T3 Unlimited.
With this feature enabled, instead of limiting your CPU to the baseline, AWS will charge you an extra to keep your credits flowing.
Enabling this can be a lifesaver if your workload is known to not use all the credits balance very often. Otherwise, it’s cheaper to use another instance type.
Example: If your instance works on 100% CPU for a full month on a t2.large, you will pay:
- $85.26 for the instance + $72 for the extra CPU credits = $157.26
Comparing to an m4.large, which has the same specs, you would pay:
- $91.25
In summary, T2/T3 instances are only cheaper when the amount of CPU credits provided is enough for your workloads. If your workload needs to sustain a high CPU over a long period of time, using an M4 or C5 is more economical.
RDS
Similar to EC2, RDS also supports T2/T3 instances, but with a catch.
RDS does not give the option to enable/disable T2/T3 Unlimited, which as we saw before, gives insurance against long CPU spikes that might exhaust the credits.
Instead, for RDS T2 instances have this option off by default and T3 instances have it on by default.
Conclusion
T2/T3 instances are great in terms of cost-efficiency, but it comes with an operational cost.
Using this instance class requires more planning and monitoring to make sure the type of workload running there is adequate and that you will be alerted before credits run out.
As an example, one of our Terraform modules creates an alarm for low credit balance on RDS instances automatically if the instance type starts with a “db.t”:
At DNX Solutions, we work to bring a better cloud and application experience for digital-native companies in Australia. Our current focus areas are AWS, Well-Architected Solutions, Containers, ECS, Kubernetes, Continuous Integration/Continuous Delivery and Service Mesh. We are always hiring cloud engineers for our Sydney office, focusing on cloud-native concepts. Check our open-source projects at https://github.com/DNXLabs and follow us on Twitter, Linkedin or Facebook.
No spam - just releases, updates, and tech information.
Stay informed on the latest
insights and tech-updates
