- Newest
- Most votes
- Most comments
Based on the behavior you're describing, this appears to be an unusual situation where the modification process has encountered an issue during the instance class change operation. Let me explain what should normally happen and what might be occurring:
Normal Modification Process: When you modify an RDS DB instance with "Apply Immediately" enabled, the changes should be applied asynchronously as soon as possible, regardless of the maintenance window setting. For a Multi-AZ instance class change, the typical process involves:
- Applying the modification to the standby instance
- Performing a failover to make the standby the new primary
- Applying the modification to the former primary (now standby)
- Completing the modification and updating the instance status
What Appears to Be Happening: Your instance has completed the failover and restart steps successfully, but the modification status hasn't transitioned to "available," and the instance class still shows as db.t4g.small rather than the target db.t4g.medium. The fact that the instance remains accessible and LatestRestorableTime is advancing indicates the database engine itself is functioning normally, but the control plane operation hasn't completed.
Recommended Actions: Since your instance is stuck in this state with no new events being generated, and the modification appears incomplete despite the operational steps having finished, this requires investigation by AWS Support. The support team will need to examine the internal state of the modification workflow and the underlying infrastructure to determine why the instance class change didn't complete.
Please visit the AWS Support Center at https://console.aws.amazon.com/support/ to add detailed correspondence about this issue to your existing case, including:
- The specific DB instance identifier
- The exact timestamps of each event you observed
- The current output of describe-db-instances showing the stuck state
- Any relevant CloudWatch metrics showing resource utilization
If you don't currently have an appropriate support plan for production workloads, you may want to review your AWS Support plan options, as higher-tier plans provide faster response times for production system issues like this one.
The support team will be able to access backend logs and systems to identify the root cause and help resolve the stuck modification state.
Sources
Modifying an Amazon RDS DB instance - Amazon Relational Database Service
ModifyDbInstanceRequest.Builder (AWS SDK for Java - 2.46.11)
Please try the following steps in order.
Option 1: Resubmit the same modification
aws rds modify-db-instance \
--db-instance-identifier <your-db-identifier> \
--db-instance-class db.t4g.medium \
--apply-immediately
Resubmitting the request can sometimes reset the internal process if a modification is already in a "pending" state.
Option 2: Cancel the modification and then re-run it
# Cancel the current modification (temporarily switch to a different class, then switch back immediately)
aws rds modify-db-instance \
--db-instance-identifier <your-db-identifier> \
--db-instance-class db.t4g.small \
--apply-immediately
# Change to "medium" again once the state stabilizes
aws rds modify-db-instance \
--db-instance-identifier <your-db-identifier> \
--db-instance-class db.t4g.medium \
--apply-immediately
answered a month ago
Sometime i face issue while modify the RDS instance type in multi-AZ have issue due to same instance type is not available in other az so , please check before going to modify the instance . there is query available to check instance is available in all az or not
Regards, Anurag Pandey
answered a month ago
Relevant content
asked 7 years ago
- AWS OFFICIALUpdated 2 years ago

Additional troubleshooting performed:
Attempted to re-submit the same instance class modification using:
AWS returned:
The instance remains in
modifyingstatus and continues to show:The suggestion to simply reissue the
modify-db-instancecommand or "cancel" it by reverting todb.t4g.smalldoes not work with AWS RDS.The AWS RDS API enforces a strict state machine. Once an instance is in the
modifyingstate, it is locked against further changes. Any subsequent attempt to modify the instance class will be rejected with an error, as the user correctly identified by posting theInvalidDBInstanceStateerror.