Skip to content

[Feature Request] EBS IOPS modification should warn when provisioned IOPS exceeds the attached EC2 instance's baseline EBS performance

0

When modifying EBS volume IOPS through the AWS Console, there is currently no warning or guidance about the attached EC2 instance's EBS performance limits. I believe adding a simple validation message would save many engineers significant troubleshooting time.

The problem I encountered:

I provisioned 8,000 IOPS on a gp3 EBS volume attached to a t3.xlarge instance. However, CloudWatch metrics showed actual IOPS fluctuating between only 4,000–6,000. This caused significant latency during peak traffic periods.

After extensive investigation, I discovered the root cause: t3.xlarge has a baseline EBS IOPS of only 4,000 with a credit-based burst model. Once the burst credits were exhausted (approximately 30 minutes of sustained high I/O), the instance was throttled to 4,000 IOPS — regardless of the EBS volume's provisioned capacity.

The gap in the current console experience:

The EBS "Modify Volume" screen accepts any valid IOPS value without checking the attached instance's capabilities There is no indication that the instance may not be able to sustain the requested IOPS The user has to separately look up the instance type's EBS specifications in the documentation to discover this limitation Suggested improvement:

It would be very helpful if the EBS volume modification screen displayed a warning when the requested IOPS exceeds the attached instance's baseline EBS IOPS. For example:

⚠️ The attached instance (t3.xlarge) has a baseline EBS IOPS of 4,000. The requested 8,000 IOPS can only be sustained during burst periods. Consider changing the instance type for sustained performance.

This small UX improvement could prevent a common misconfiguration that is difficult to diagnose, especially for engineers who are not yet familiar with the credit-based burst behavior of T-series instances' EBS performance.

Thank you.

1 Answer
0

Thank you for this detailed feature request. You've identified an important gap in the user experience that can lead to performance issues that are difficult to diagnose.

Your observation is correct: an instance's EBS performance is bounded by either the instance type's performance limits or the aggregated performance of its attached volumes, whichever is smaller. To achieve maximum EBS performance, an instance must have attached volumes that provide combined performance equal to or greater than the maximum instance performance. However, if the instance type cannot support the provisioned IOPS, the volume will be constrained by the instance's limits.

AWS does provide tools to help identify when this situation occurs. Amazon CloudWatch offers metrics specifically designed to monitor when applications exceed I/O performance limits for EC2 instances with attached EBS volumes. The "Instance EBS IOPS Exceeded Check" and "Instance EBS Throughput Exceeded Check" metrics monitor whether the driven IOPS or throughput is exceeding the maximum that your instance can support. These metrics return a value of 0 when performance is not exceeded and 1 when it is exceeded, allowing you to create alarms and dashboards to detect these situations.

Your suggestion to add proactive warnings in the console during volume modification would indeed help prevent this common misconfiguration before it occurs, rather than requiring users to discover the issue through monitoring after the fact. This type of validation would be particularly valuable for users working with burstable instance types where the baseline and burst performance characteristics can be less intuitive.

I recommend submitting this feedback directly through the AWS Console feedback mechanism or through your AWS account team, as they can ensure it reaches the appropriate product teams for consideration in future console enhancements.
Sources
Performance for Multi-Attach Amazon EBS volumes - Amazon EBS
New Amazon CloudWatch metrics to monitor EC2 instances exceeding I/O performance - AWS
Amazon EBS-optimized instance types - Amazon Elastic Compute Cloud

answered 2 months ago
EXPERT
reviewed 2 months ago
  • Thanks for the suggestion. I've submitted this feedback through the AWS Console feedback mechanism as well. Hope it gets picked up by the product team

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.