fix: Adjust the GP3 IOPS defaults in case of modifications

[ZPascal]

Rollback Plan

If a change needs to be reverted, we will publish an updated version of the library.

Changes to Security Controls

No changes to security controls.

Description

This PR fixes two bugs in the aws_db_instance resource related to gp3 storage IOPS handling during ModifyDBInstance calls.

Bug 1: Stale IOPS sent when allocated_storage crosses the gp3 baseline threshold

Root cause

AWS gp3 storage automatically provisions a higher baseline IOPS once allocated_storage reaches or exceeds a per-engine threshold (AWS docs):

Engine	Threshold	IOPS below threshold	IOPS at/above threshold
DB2, MariaDB, MySQL, PostgreSQL	400 GB	3000	12000
Oracle EE / SE2	200 GB	3000	12000
SQL Server	—	3000 (always)	—

When allocated_storage grew across the threshold (e.g., 200 GB -> 400 GB for PostgreSQL) without an explicit iops change, the provider evaluated the threshold check against the new storage value only. Because the new value was at/above the threshold, the condition fired and sent the old stale IOPS value (3000) in the ModifyDBInstance call — overriding the automatic AWS increase to 12000.

Fix

Added isGP3CrossingThresholdFromBelow, which uses d.GetChange to compare old and new storage values. The IOPS value is now only sent when the user explicitly changed it or when the storage was already above the threshold before (and remains there):

The threshold lookup was also extracted into a shared helper gp3AllocatedStorageThreshold to avoid duplicating the per-engine switch in both functions.

Bug 2: Wrong gp3 IOPS threshold for Db2 engines

The pre-existing threshold map had db2-ae / db2-se at 100 GB, but according to the AWS documentation, DB2 is in the same tier as MySQL, MariaDB, and PostgreSQL, with a threshold of 400 GB.

Fix

Fixed by merging DB2 into the correct case branch.

References

• AWS RDS gp3 Storage documentation

Findings

Why aws_rds_cluster does not need the same fix

The cluster update path uses a separate if d.HasChange / if d.HasChange blocks, each of which only sends IOPS unconditionally for Provisioned IOPS storage types (io1/io2). For gp3 clusters, neither block sends IOPS when only allocated_storage changes — AWS handles the baseline automatically. -> No bug

Output from Acceptance Testing

% make testacc TESTS=TestAccRDSInstance_Storage_gp3MySQL PKG=rds
% make testacc TESTS=TestAccRDSInstance_Storage_gp3Postgres PKG=rds

[github-actions]

Community Guidelines

This comment is added to every new Pull Request to provide quick reference to how the Terraform AWS Provider is maintained. Please review the information below, and thank you for contributing to the community that keeps the provider thriving! 🚀

Voting for Prioritization

• Please vote on this Pull Request by adding a 👍 reaction to the original post to help the community and maintainers prioritize it.
• Please see our prioritization guide for additional information on how the maintainers handle prioritization.
• Please do not leave +1 or other comments that do not add relevant new information or questions; they generate extra noise for others following the Pull Request and do not help prioritize the request.

Pull Request Authors

• Review the contribution guide relating to the type of change you are making to ensure all of the necessary steps have been taken.
• Whether or not the branch has been rebased will not impact prioritization, but doing so is always a welcome surprise.