Select Language:
When adjusting the IOPS for an EBS volume in the AWS Console, there’s currently no warning or guidance about the attached EC2 instance’s limits on EBS performance. Adding a simple notification would save many engineers from spending a lot of time troubleshooting later.
Here’s an example of the issue I faced: I set up an 8,000 IOPS gp3 EBS volume attached to a t3.xlarge instance. At first, everything seemed fine, but CloudWatch showed that actual IOPS hovered between 4,000 and 6,000. During peak traffic, this caused noticeable delays.
After digging into the problem, I found the cause: the t3.xlarge instance has a baseline EBS IOPS limit of only 4,000 because it uses a credit-based burst system. Once the burst credits run out—usually after about 30 minutes of sustained high I/O—the instance gets throttled down to a maximum of 4,000 IOPS, regardless of the volume’s provisioned capacity.
The current console experience doesn’t help here. When you go to the “Modify Volume” screen, it accepts any valid IOPS number without checking if the attached instance can handle it. There’s no clear message to warn you that the requested performance might not be sustainable. To find out, you have to search through the documentation for your instance type’s EBS IOPS limits, which isn’t convenient.
A simple way to improve this would be to add a warning on the modification page. For example, if you try to set IOPS higher than what your instance can sustain, a message could appear saying:
“⚠️ The attached instance (t3.xlarge) has a baseline EBS IOPS of 4,000. The requested 8,000 IOPS can only be maintained during burst periods. Consider upgrading your instance for consistent performance.”
This small change would help prevent common mistakes that are often hard to spot and diagnose, especially for engineers who are not yet familiar with the burst behavior of T-series instances’ EBS performance.
Thanks for considering this improvement!





