When should you migrate from EC2 T-series to M-series?

Migrating a workload from an Amazon EC2 T-series burstable instance to an M-series general-purpose instance becomes necessary when an application transitions from intermittent, spiky CPU usage to sustained, predictable resource consumption. While T-series instances offer significant cost savings by providing a baseline level of CPU performance with the ability to burst above that baseline using accumulated CPU credits, workloads that continuously exceed their baseline threshold can quickly deplete those credits or incur substantial surplus charges in Unlimited mode. This article examines the architectural differences between T-series and M-series instances, the financial and performance metrics that signal the need for migration, and how to calculate the exact break-even point for making the switch.

Understanding the architectural difference

Amazon EC2 T-series instances (such as T3, T3a, and T4g) are designed for workloads that do not use the full CPU often or consistently, such as web servers with low traffic, development environments, and small databases. Each T-series instance size is assigned a baseline CPU utilization percentage per vCPU, ranging from 5% to 40%. When average CPU utilization stays below the baseline, the instance earns CPU credits; when utilization rises above the baseline, it spends them.

In contrast, M-series instances (such as M6i, M6g, M7i, and M7g) provide fixed, dedicated compute resources where 100% of the vCPU capacity is available at all times without a credit system. In addition to dedicated CPU availability, M-series instances offer higher network bandwidth baselines, greater Elastic Block Store (EBS) throughput guarantees, and larger memory-to-vCPU ceilings compared to similarly sized T-series counterparts.

Key indicators that it is time to migrate

Deciding when to move from a T-series to an M-series instance relies on monitoring specific Amazon CloudWatch metrics and billing patterns. A workload is ready for migration when one or more of the following conditions occur consistently.

Sustained CPU utilization above the break-even threshold

All T3, T3a, and T4g instances launch in Unlimited mode by default. In this mode, if a workload exhausts its accrued CPU credit balance, EC2 allows the instance to continue bursting as high as needed by charging a flat fee per vCPU-hour for surplus credits. Once average CPU utilization stays elevated for long periods, the base hourly rate of the T-series instance plus the surplus credit charges will eventually exceed the fixed hourly cost of an equivalent M-series instance.

We can determine the exact average CPU utilization percentage where an M-series instance becomes cheaper than a T-series instance in Unlimited mode. Let $C_T$ be the hourly on-demand price of the T-series instance, $C_M$ be the hourly on-demand price of the equivalent M-series instance, $N$ be the number of vCPUs, $B$ be the baseline utilization per vCPU expressed as a decimal, and $P_c$ be the price per vCPU-hour for surplus credits (typically $\$0.05$ for Linux on x86 T3/T3a and $\$0.04$ for Arm-based T4g).

The total hourly cost of a T-series instance running at an average utilization $U$ (where $U > B$) over an extended period is:

\[\text{Cost}_{\text{total}} = C_T + N \cdot (U - B) \cdot P_c\]

Setting $\text{Cost}_{\text{total}} = C_M$ and solving for the break-even utilization $U_{\text{break-even}}$ gives:

\[U_{\text{break-even}} = B + \frac{C_M - C_T}{N \cdot P_c}\]

For example, comparing a t3.large ($N = 2$, $B = 0.30$, $C_T \approx \$0.0832$) with an m6i.large ($N = 2$, $C_M \approx \$0.096$) running Linux in us-east-1 with $P_c = \$0.05$:

\[U_{\text{break-even}} = 0.30 + \frac{0.096 - 0.0832}{2 \cdot 0.05} = 0.30 + \frac{0.0128}{0.10} = 0.428\]

In this scenario, if the t3.large instance maintains a 24-hour average CPU utilization above $42.8\%$, migrating to an m6i.large instance reduces monthly costs while providing access to $100\%$ of the vCPUs at no extra charge.

CPU credit depletion and throttling in Standard mode

If a T-series instance is configured in Standard mode rather than Unlimited mode, exhausting the CPUCreditBalance metric has an immediate impact on application performance. Once the credit balance reaches zero, the instance's CPU is throttled down to its baseline level (for example, 20% on a t3.medium). If your monitoring shows CPUCreditBalance frequently dropping near zero accompanied by spikes in application latency, request queueing, or health check timeouts, the workload has outgrown the burstable model.

Consistently positive CPUSurplusCreditBalance

For instances running in Unlimited mode, the CloudWatch metric CPUSurplusCreditBalance tracks the number of credits consumed beyond the available credit balance, while CPUSurplusCreditsCharged tracks the credits that were not paid down by subsequent idle periods within a 24-hour window. If CPUSurplusCreditsCharged is consistently greater than zero across multiple billing cycles, the workload is no longer exhibiting a true burst-and-idle pattern and should be evaluated against an M-series equivalent.

Network and EBS throughput bottlenecks

T-series instances also use a burst model for network and EBS I/O performance. A t3.large offers up to 5 Gbps of network bandwidth and 2,085 Mbps of EBS bandwidth only in short bursts, with significantly lower baseline throughput. While an m6i.large offers up to 12.5 Gbps of network bandwidth and 10 Gbps of EBS bandwidth on a burst basis, moving up the M-series family (or utilizing larger sizes) provides much higher sustained baselines. Workloads that perform continuous data streaming, heavy database replication, or sustained disk I/O often hit EBS and network throughput shaping on T-series instances long before they saturate CPU credits.

Latency sensitivity and noisy neighbor tolerance

Production workloads with strict service-level objectives (SLOs) for tail latency ($p95$ and $p99$ response times) generally belong on M-series instances. Because T-series instances oversubscribe physical host cores more aggressively than M-series instances, slight micro-contention or the transition between baseline and burst states can introduce minor CPU steal or jitter. M-series instances allocate dedicated execution threads on modern processors, providing predictable, deterministic compute performance.

Summary comparison of T-series vs. M-series

Characteristic	T-Series (T3, T3a, T4g)	M-Series (M6i, M6g, M7i, M7g)
Primary Use Case	Microservices, dev/test environments, low-traffic web apps, build servers	Production application servers, mid-size databases, caching fleets, enterprise backends
CPU Allocation	Baseline (5% to 40%) with credit-based bursting	100% sustained vCPU availability at all times
Cost Structure	Low base hourly rate; variable overage charges in Unlimited mode	Fixed, predictable hourly rate with no CPU overage fees
Network & EBS I/O	Lower baseline with credit-based I/O bursting	Higher sustained baseline and higher burst ceilings
Instance Scale	Up to 8 vCPUs and 32 GiB RAM (`2xlarge`)	Up to 192 vCPUs and 768 GiB RAM (`48xlarge` / `metal`)

How to verify before migrating

Before executing an instance type change, inspect the last 14 to 30 days of CloudWatch metrics for the target instance:

Check the average of the CPUUtilization metric over a 24-hour period. Compare this value against the calculated $U_{\text{break-even}}$ for your specific instance size and region.
Inspect CPUSurplusCreditsCharged in CloudWatch or review AWS Cost Explorer filtered by the CPUCredits usage type (USE1-CPUCredits:t3 or similar) to see how much you are paying in burst penalties.
Verify architecture compatibility. If migrating from an x86 t3 instance, the direct counterparts are m6i or m7i. If migrating from an AWS Graviton t4g instance, the direct counterparts are m6g or m7g. Because both families use the AWS Nitro System and Elastic Network Adapter (ENA) drivers, switching between them typically requires only stopping the instance, modifying the instance type, and starting it again.