[ARTICLE]

Amazon EC2 T3 Instances: How To Fully Maximize AWS’ Offering

Back in 2010, Amazon Web Services (AWS) launched the t1.micro instance type. They followed this up with the first of the T2 instances (micro, small, and medium) in 2014, more sizes in 2015 and 2016, and finally unlimited bursting. Then, in 2018, AWS launched Amazon EC2 T3 (Elastic Compute Cloud). This was augmented in early 2019 with a less expensive variant – the T3a. T3 and T3a were more cost-effective than their forerunners, providing AWS users with general-purpose, burstable instances.

AWS EC2 T3 instances are low cost, general-purpose instances designed for applications that have moderate CPU usage and that can be expected to experience occasional spikes in demand; web servers and CI servers, for examples. They provide users with compute, network, and memory resources that are completely balanced. They provide a baseline level of CPU performance with the ability to rapidly increase (“burst”) CPU usage and maintain that higher use rate as long as needed

T3 instances feature Intel Xeon Platinum 8000 series processor with a sustained clock speed of up to 3.1 GHz. This provides up to 30% higher performance at a lower cost than equivalently sized T2 instances. T3a instances come with the AMD EPYC 7000 series processor, a clock speed of up to 2.5 GHz, and run about 10% cheaper than regular T3 instances. On the small end of the T3 size, all T3’s have dual-core processors while t2.small, t2.micro, and t2.nanos only offer single-core instances. T3 instances are available in seven sizes.

 

T3’s use CPU credits to manage costs.  One credit equals 1 maxed out CPU for 1 minute. When your instance is running below baseline, credits accumulate.  These then cover the higher CPU use during a bursting instance. As long as the instance credits for a time period are not exceeded, costs remain low.  I like to think of credit use similar to a bucket with a constant flow of credits filling it.  CPU use opens a spigot on the bucket to let more or less credits flow out.  If you are using fewer credits than are filling the bucket, eventually the bucket overflows and excess credits are lost.  Open the bucket’s spigot too wide for too long and you may drain the bucket.

It should be noted here that credits track costs and do not limit performance by default. If your app CPU requirement stays above baseline, the instance will support that higher CPU, but added costs ($0.05 per vCPU-hour) will accrue. For the bucket analogy, when the bucket is empty, Amazon will increase the incoming flow to match the bucket’s outflow.  It is possible to limit bursting to only the amount of allocated credits.

When is the best time to transfer workloads to Amazon EC2 T3 instances?

The introduction of burstable T3 instances types further encouraged users to run workloads even when these do not need prolonged, high-level CPU performance.  This presents users with a tricky situation and may place them in a tight spot if used excessively. Just because you’re using AWS infrastructure doesn’t mean everything’s optimized. By default, T3 instances don’t have limits. But continuously deploying T3 instances can incur huge costs, especially when running highly demanding workloads.

Opsani can help users determine when to move workloads to T3 instances. Leveraging its AI-fueled cloud optimization engine, Opsani looks deep into every workload and thoroughly analyzes its requirements. The software then decides whether a workload is best to run on an AWS EC2 T3 instance or if it’s more viable to go with R5, M5, C5, or other instance families. Simply put, Opsani delivers true AWS optimization, even with AWS’s latest T3 instances product offering.

With Opsani’s combined experience and expertise in cloud optimization, available services, and configurations on both on-premise and public cloud infrastructure, coupled with their patented AI-driven optimization engine, users get the most knowledgeable answer as to when or where to place their workloads and apps.

When To Use AWS EC2 T3 Instances: Factors To Consider

Nitro systems power T3 instances and support network and EBS bursting. You need to keep a close eye on things like HVM virtualization and the need to start inside a virtual private cloud (VPC) that uses an AMI, which comes with the elastic network adapter (ENA) driver.

Opsani’s powerful optimization engine takes in metadata from AWS, performs complete and thorough checks on workloads and their requirements, and compares your workloads’ needs against the capabilities of various types of cloud instances. Our team of performance optimization experts works to determine that only suitable workloads are categorized as migration candidates for T3. Other considerations are pointed out and manifested to our users.

Comparing Costs of T3 vs T2, M5, & R5 Instances

Assuming the following conditions are true:

  1. Instances functioning @ 100% for a 1-month period
  2. T3.xlarge baseline performance is 1.6 vCPUs (40% * 4 vCPUs)
  3. T2.xlarge  Baseline performance is 0.9 vCPUs (22.5% * 4 vCPUs)
  4. Extra charges of $0.05 (for Linux) and $0.096 (for Windows) per vCPU-hour for T2/T3 bursting beyond credits

Finding Breakeven Points for Amazon EC2 T3 Instances

Below is a breakdown of the break-even point for the amount of time a T3 unlimited can run at 100% CPU against the equivalent M5.

  • For Linux

($138-$120)/(0.05*2.4) = 21% of the time or 150 hours out of the month

  • For Windows

($271-$173)/(0.096*2.4) = 59% of the time or 425 hours out of the month

Why use a T3 Micro instance vs an equivalent T2 Micro?

Which EC2 instance is right for you will depend on your use case. As mentioned above a T3 micro instance will, by default, provide slightly better performance than a T2 instance for a slightly lower price. This alone may not make the argument for moving from a T2 to T3 instance, but as with all things AWS, comparisons are generally not straightforward.  The smaller T3 instances all come with 2 cores and a t3.micro accrues credits at the rate a t2.small does. This means a t3.micro can comparatively burst for twice as long as a t2.micro, another small, incremental way to save on cloud costs. Another wrinkle in the credit game is that T2 instances lose accrued credits after 24 hours, while T3’s hang on to them for seven days before they start to expire.  When deciding which is right for you, the critical metric to monitor is an instance’s average CPU utilization for 24 hours overall CPU cores. Understanding that number will allow you to map out your credit needs and compare them to specific instance capabilities.

Crucial Insights Into Running Workloads on AWS T3s Against Other Instance Types

Amazon EC2 delivers a vast selection of instance families and types to choose between. These guidelines help you determine the best choice for your T3-compatible workload:

  • If you can fit on less CPUs, R5 offers the best value
  • A T3 unlimited running @ 100% is 25-50% more expensive than the equivalent M5 – the additional costs for unlimited bursting can be consequential
  • T3 instances are unlimited by default, causing customers to gain considerable charges when left unchecked
  • Opsani recognizes when unlimited bursting charges go beyond the threshold – e.g. breakeven point with M5 costs. The software will suggest using a different instance type or deactivating “unlimited” mode (e.g. dev/test workload)
  • T3 offers better value than T2, including extra CPU credits and better baseline performance, faster CPUs. The only downside is the migration effort.
  • The cost difference of the instance types between Windows and Linux is considerable and results in different optimal instance types:
  • For Linux, T3 is priced lower than T2. But for Windows, T3 is a tad pricier than T2.
  • The breakeven point for unlimited bursting of T3 vs M5 instances is greatly diminished on Linux as opposed to Windows (21% vs 59%)

These last few paragraphs have shared some, but not all of the considerations when choosing the right instance type.  Is my workload best served by an instance that is burstable? Can I put limits on bursting without negative or at least acceptable effects on my application?  Are the assumptions I am basing my decision on likely to be correct and constant? Opsani’s AI not only evaluates these considerations, but because it is able to learn based on application behavior over time,  Opsani can continuously tune the system performance with much less effort than doing this through a manual approach. 

Considerations for EC2 Reserved Instances (RI)

Reserved instances can provide substantial cost savings, but also, even with a RI marketplace that allows resale of RIs, a certain amount of lockin. Having T2 or even T3 instances and realizing that a T3a would be more cost-effective can leave one feeling buyer’s remorse. The good news is that Opsani’s team of optimization professionals is ready to help you leverage your existing reserved instances as well as plan and implement a comprehensive RI acquisition strategy to get the most out of your current RIs. While selling a RI on the AWS marketplace might be a solution, converting instances within an instance category can result in improved performance and cost savings. Moving a T3.large to four T3.small instances, or vice versa, might be a more efficient option and Opsani can automatically help identify these sorts of optimizations. Further, Opsani will be with you step by step to ensure your infrastructure achieves the optimal state, and to prevent the purchase of long-term reservations for older instance types that you can’t convert.

Match Candidate Workloads to T3s Automatically

Even with the potential complicating factors we have mentioned, if your workload can take advantage of a burstable instance, T3 EC2 instances will generally outperform and cost less than their T2 EC2 instance cousins.  Application performance monitoring (APM) and cost monitoring should be implemented as best practices anyway, and they provide a realistic view of your system and can help you determine if a T3 burstable instance might provide a path to cost savings. If you want to remove the toil of evaluating your monitoring data, Opsani’s robust and automated. Opsani’s robust and automated AI-driven optimization engine can immediately find and move workloads suited to take advantage of the efficiency and cost savings offered by T3 instances.