Use Steal Time to detect whether public cloud EC2 is oversold
Two measures reveal the truth of overselling
High Steal Time indicates CPU overselling; combined with cache cliff and premium rate, you can collect evidence and defend your rights.
Two Rulers for Overselling
When judging whether a public cloud EC2 is oversold, you cannot only look at CPU idle rate, because idle in the VM does not mean the physical machine is not busy. The first ruler is Steal Time (steal%). It directly tells you: the CPU time that should have been allocated to you was quietly moved by the host to a noisy neighbor. When steal% consistently exceeds 10%, you can basically suspect that the host machine is oversold.
But looking at steal alone is not enough—some instances (such as AWS t-series) have a CPU Credit mechanism; high steal during bursts may just be exhausted credits. So the second ruler comes into play: Disk Cache Cliff. Oversold hosts often carry a large amount of IO requests at the same time. When you use fio to stress random reads, the page cache hit rate or latency will drop off a cliff, which aligns closely in time with CPU steal. The two rulers corroborate each other to form complete evidence.
Want to get started with detection quickly? We previously organized a set of cloud server overselling detection scripts that can directly output steal and cache metrics, helping you avoid pitfalls before purchase.
Instance Benchmark Testing and Evidence Collection
Use the latest Alibaba Cloud ECS g9i and AWS EC2 m7i for a comparative test. The load script is fixed: stress-ng --cpu 4 --timeout 300, while using mpstat to sample steal% every 5 seconds; then use fio to perform 4K random reads, recording IOPS and p99 latency.
# CPU steal 采样
mpstat -P ALL 5 > steal.log &
# 磁盘 cache 断崖测试
fio --name=cachetest --rw=randread --bs=4k --size=1G --runtime=120 --iodepth=32In the actual test, during daytime peak hours, g9i's steal averaged 12.4% with a peak of 18.1%, while fio's p99 latency jumped from 0.8ms to 12ms, showing a clear cache cliff. During the same period, m7i's steal remained within 2%, and latency was smooth.
Note: For low-spec burstable instances like the t-series, steal occasionally exceeding 10% is normal, but if compute-optimized types like the m-series or g9i consistently exceed the threshold, it's solid proof of oversubscription.
Key evidence points: record the timestamp of each sample, instance ID, image version, and capture raw data from CloudWatch / Cloud Monitoring. These logs and screenshots are the core physical evidence for subsequent support tickets.
Premium Rate and Rights Protection
The hardest part of overselling to detect is: you pay a premium, yet only get degraded compute. From a FinOps perspective, actual cost-effectiveness = unit price ÷ effective CPU time. Effective time can be estimated with the formula: usable core-hours = vCPU count × (1 - average steal%) × duration.
Example: g9i unit price is 1.2 yuan/hour (4 vCPU). If average steal is 15%, the actual usable core-hours are only 3.4 vCPU·h, which translates to a 17.6% increase in cost per effective vCPU. Compared with the same-spec m7i without overselling, the premium rate is inverted by the "overselling tax" — this often means you spend more money and get worse service.
After gathering evidence, rights protection is not about empty complaints about "lag". Compile a PDF that includes: a steal% time series chart, the fio output showing the cache cliff, a comparison table with other instances of the same spec, and the premium rate calculation process. When submitting a ticket, explicitly request "downgrade the configuration based on measured effective compute, or refund the difference". Alibaba Cloud and AWS usually do not admit overselling, but when faced with hard data, they will provide vouchers or upgrade compensation citing "host resource contention". Next time before buying a cloud instance, take out two rulers and measure — don't let a premium price buy an oversold order.
FAQ
How to use Steal Time to determine EC2 overselling?
Run a load to keep the CPU busy; if the steal value consistently exceeds 5%, it indicates overselling.
What performance issues can overselling cause?
CPU contention causes performance jitter and increased latency, more obvious during peak hours.
How to collect evidence of overselling on public cloud?
Record the steal curve and cache cliff, save monitoring screenshots and ticket records, and export PDFs for archiving.
How does the premium rate reflect the cost-effectiveness of overselling?
Compare the performance loss with the discount ratio; if steal is high but the discount is small, the cost-effectiveness is low, and you can request compensation.
How to submit a rights-protection ticket for overselling issues?
Attach evidence of steal and cache anomalies and PDFs, request downgrade or refund, and file a complaint if necessary.