RDS instances still on gp2 storage, where gp3 gives better baseline performance at the same price
What does ZopNight detect here?
ZopNight reads the `StorageType` of every RDS instance and singles out those still on gp2. Amazon RDS charges gp2 and gp3 the same per-GB rate ($0.115 per GB-month, Single-AZ, us-east-1), so no storage saving exists and ZopNight raises no cost finding; the move to gp3 is a performance upgrade you make yourself.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-167 |
| Category | performance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | StorageType = gp2 |
| Source | ZopNight |
| Permissions used | rds:DescribeDBInstances |
Where it applies
gp2 ties database IOPS to volume size, gp3 does not
On a gp2 volume, Amazon RDS gives you 3 IOPS for each GiB, with a floor of 100 IOPS. A 100 GiB volume gets 300 IOPS of baseline and you need 1,000 GiB before it reaches 3,000. Teams often buy storage they do not need just to raise that number.
gp3 breaks the link. Every gp3 volume starts at a baseline of 3,000 IOPS and 125 MiB/s whatever its size, and for Db2, MariaDB, MySQL and PostgreSQL a volume of 400 GiB or more is striped across four volumes and gets 12,000 IOPS and 500 MiB/s as its baseline. RDS SQL Server does not stripe and keeps the lower baseline. AWS now labels gp3 as recommended and gp2 as previous generation.
What gp3 does not do on RDS is cost less. The current AWS price list for US East (N. Virginia) shows provisioned gp2 and gp3 storage both at $0.115 per GB-month for Single-AZ instances, and both at $0.23 for Multi-AZ. IOPS and throughput provisioned above the gp3 baseline are billed on top.
Listing RDS instances that still use gp2
aws rds describe-db-instances \ --query 'DBInstances[?StorageType==`gp2`].[DBInstanceIdentifier,Engine,AllocatedStorage,MultiAZ]' \ --output tableRun it per Region. Compare AllocatedStorage with the gp2 formula: anything under 1,000 GiB has a
lower baseline than the 3,000 IOPS a gp3 volume starts with (gp2 volumes that small can only burst
to 3,000 while their I/O credits last).
How ZopNight evaluates an RDS gp2 instance
The check is a configuration read with no metric and no lookback window. ZopNight takes the storage
type AWS reports for the instance and looks only at instances where it is gp2, and only when a
monthly cost is known for the instance.
Why no finding appears for these instances
This rule is built to report a dollar figure, and for RDS storage the dollar figure is zero. Because AWS bills gp2 and gp3 at the same per-GB rate, the storage line would not change after a migration, so ZopNight stays silent on every gp2 instance rather than show a $0 recommendation. That is a deliberate outcome, not a gap in data collection. EBS volumes attached to EC2 are different: there gp3 is cheaper per GB, and EBS gp2 to gp3 Migration prices that difference.
When a saving would be reported
Only if AWS ever priced RDS gp2 and gp3 storage differently would the rule turn into a priced recommendation:
saving = allocated storage GB x (gp2 rate - gp3 rate)reported only when the saving is above $5 a monthUntil then the benefit is performance headroom, not cost.
Moving an RDS instance from gp2 to gp3
- Note the current IOPS your workload reaches in CloudWatch so you can confirm gp3 covers it.
- Change the storage type:
aws rds modify-db-instance --db-instance-identifier mydb --storage-type gp3 --apply-immediately - Leave
--iopsand--storage-throughputat the baseline unless you measured a need; anything above the baseline is billed separately. - Watch the instance while it shows the
storage-optimizationstatus. AWS says scaling storage usually needs no outage and that latency can rise during optimization while staying in the single-digit millisecond range.