AWS EC2 “T” family instances (t2, t3, t3a) are marketed as the most cost-effective way to run a server. They use a CPU Credit system that allows you to burst when needed. For a developer with a low-traffic personal project, it’s a miracle of pricing. But for a growing business, T-series instances are a time bomb waiting to explode your budget the moment your traffic becomes consistent.
The Efficiency Audit
“Burstable instances are a loan from AWS. You pay with credits during the day, and if you can’t pay them back, you pay with real dollars at an astronomical rate.”
Phase 1: The ‘Unlimited’ Credit Mode Illusion
Modern T3 instances have “Unlimited Mode” enabled by default. This means if you run out of CPU credits, AWS doesn’t throttle your performance—they simply charge you a surplus fee for every vCPU-hour beyond your baseline. I’ve seen production servers that were “cheap” on paper cost 500% more than a dedicated M5 instance simply because the owner didn’t realize their background workers were consuming credits 24/7.
Phase 2: The ‘Baseline’ Ceiling
Every burstable instance has a Baseline Performance (e.g., 20% for a t3.medium). If your app consistently uses 25% CPU, you are in a permanent credit deficit. In this scenario, you are paying for the “flexibility” of a burstable instance while actually needing the stability of a dedicated core. At pricecontext.com, we define the “T-to-M” pivot point at exactly 35% sustained CPU utilization. Crossing this line without migrating is a structural failure of financial management.
- Check your CloudWatch: Is your CPUCreditBalance consistently at zero?
- Are you paying “CPUSurplusCreditCharges” on your monthly bill?
- Is your application performance dropping during peak hours due to throttling?
The Economic Timing of the EC2 Instance Family Pivot