# RDS Storage Type gp2 -- Migrate to gp3

> ZopNight deliberately reports nothing for RDS gp2 volumes today: AWS prices RDS gp2 and gp3 storage at the same per-GB-month rate (both $0.115 in us-east-1 Single-AZ), so unlike EBS there is no dollar saving to quantify. The gp3 migration still pays off in performance: 3000 baseline IOPS decoupled from size.

Source: https://zop.dev/integrations/aws/recommendations/rds-storage-type-gp2-migrate-to-gp3
Updated: 2026-08-19

---

## A rule that deliberately reports nothing

Every real evaluation of this rule ends in an abstain, and that is the correct
behaviour rather than a gap. The gates still run (the instance's discovered storage
type must be `gp2` and a priced monthly cost must exist), but no finding is ever
emitted, because the saving this migration is usually assumed to carry does not exist
on RDS.

## Why the EBS playbook does not transfer

On EBS, gp3 is priced below gp2 per GB-month, and the EBS equivalent of this rule
reclaims that real delta. On RDS, AWS prices gp2 and gp3 database storage at the same
per-GB-month rate ([$0.115 in us-east-1 Single-AZ](https://aws.amazon.com/rds/pricing/)), and the pricing pipeline ingests
both storage SKUs and confirms they are identical. The storage-line saving is genuinely
$0, not merely unmeasured.

There is a second, independent blocker: the priced cost available per instance is the
total monthly bill, which is overwhelmingly compute. Applying any fraction of it to
represent a storage-line saving would fabricate a number, and a cost recommendation
here is concrete or it is nothing.

## What would wake it up

The ingestion already keys the two storage SKUs separately, per region. If AWS ever
prices RDS gp2 above gp3 anywhere, the rates diverge, and the rule's documented upgrade
path is to read the allocated storage size and emit a real finding whose saving equals
storage GB times the per-GB rate delta, gated above $5 a month. Until that day,
abstaining is the permanently correct answer.

## The performance case still stands

None of this means staying on gp2. gp3 gives a 3,000 IOPS / 125 MiB/s baseline
independent of volume size, where gp2 couples performance to how many GB were
allocated. Small volumes gain the most: the smaller the gp2 volume, the further below
that gp3 baseline its coupled performance sits. The migration is a modification of the
instance's storage type, runs online with no downtime, and lets you configure IOPS and
throughput explicitly afterwards. A worthwhile change. Just a performance decision,
not a cost finding a savings platform should print.

## Check what you have

```bash
aws rds describe-db-instances \
  --query "DBInstances[?StorageType=='gp2'].[DBInstanceIdentifier,AllocatedStorage,Iops]" \
  --output table
```

Anything listed migrates for free in dollar terms and gains a predictable performance
floor in the same move. Monitor IOPS after the change to confirm the configured
baseline actually covers the workload.