How to right-size RDS instances without downtime

Quick Answer (TL;DR)

Modifying an RDS instance class in place causes 5 to 15 minutes of downtime while AWS reboots the database. To right-size without downtime, use RDS Blue/Green Deployments (fastest, cleanest), a read-replica promotion (works on older engines), or a Multi-AZ failover to a resized standby. Blue/Green is the 2026 default for most workloads on MySQL, MariaDB, Postgres, and now SQL Server.

Why this happens

RDS instances are Managed EC2 hosts running the DB engine, and a class change (say db.m6i.large to db.m6i.xlarge) requires stopping the process, migrating the EBS volumes to a new host, and restarting. AWS's default "modify" workflow does this in place and warns you about downtime. The workarounds exist because that reboot is unacceptable for user-facing services, so you build the new instance alongside the old one and cut over.

Fix #1: Use RDS Blue/Green Deployments

The 2026 default. Available for RDS MySQL, MariaDB, PostgreSQL, and SQL Server (added mid-2025).

Steps:

• In the RDS console, select the instance and choose Actions → Create Blue/Green Deployment.


• Set the Green instance to your target instance class.


• AWS creates a full standby using logical replication, keeps it in sync, and validates health.


• When ready, click Switch over. Cutover typically takes under 60 seconds. Applications reconnect using the same endpoint.

Command-line equivalent:

aws rds create-blue-green-deployment --blue-green-deployment-name resize-prod --source arn:aws:rds:... --target-db-instance-class db.m6i.xlarge

Best when: your engine supports it and you can tolerate the extra cost of running two instances for the sync window.

Fix #2: Read-replica promotion

For engines or versions that do not yet support Blue/Green, or for cross-region resizing.

Steps:

• Create a read replica with the desired new instance class.


• Wait for the replica to catch up (near-zero lag).


• Point application writes to the read replica endpoint (requires connection-string change or DNS switch).


• Promote the read replica to a standalone primary with aws rds promote-read-replica --db-instance-identifier <replica-id>.


• Delete the old primary.

Best when: you already have a replica strategy in place, and application code can handle a DNS or endpoint change.

Fix #3: Multi-AZ failover with resized standby

The edge case. Works when Blue/Green is not available and you cannot introduce a new endpoint.

Steps:

• On a Multi-AZ instance, temporarily disable Multi-AZ, resize the primary, then re-enable Multi-AZ.


• Alternative: modify the standby's compute class first (via a maintenance window), then trigger a failover with aws rds reboot-db-instance --force-failover. Applications reconnect to the resized standby, which becomes the primary.

The downtime is the failover time, usually 30 to 120 seconds. Best when a full Blue/Green cutover is not feasible.

How to prevent this

Right-sizing is only a problem if you overprovision or underprovision in the first place. Three practices avoid the resize cycle.

• 
  Enable Performance Insights and check the db.load metric weekly. Sustained load above 80% of DB vCPU means you are underprovisioned. Sustained below 20% means overprovisioned.


• 
  Use Graviton-based instance classes (db.m7g, db.r7g) for a 15 to 20% price-performance improvement on most workloads. Right-size once at migration and revisit quarterly.


• 
  Set CloudWatch anomaly-detection alarms on CPUUtilization, DatabaseConnections, and FreeableMemory. Catch drift before it forces an emergency resize.

FAQ

How long does a Blue/Green cutover actually take?

Typically 30 to 90 seconds for the switchover step itself. The full setup (creating the Green instance and letting it sync) takes hours for large databases, but the customer-visible downtime is under a minute.

Does Blue/Green work with encrypted RDS instances?

Yes, on all supported engines as of 2025. The Green instance inherits the KMS key or you can specify a new one.

Will connections survive the cutover?

No. Existing connections drop and reconnect. The application must handle transient connection errors, which is standard for any HA database interaction.

Can I use Blue/Green to change the engine version too?

Yes. Blue/Green now supports minor and major version upgrades in the same cutover as the resize. Test the upgrade path first.

What about RDS Serverless v2?

Serverless v2 autoscales compute in the range you configure, so you rarely need a manual resize. Adjust the ACU range instead.

Related guides

• The AWS docs page on Blue/Green Deployments for RDS has the current engine and version support matrix.


• For Postgres specifically, see logical replication limits which affect Blue/Green.


• Compare against CloudNativePG on Kubernetes if you are evaluating a move off RDS entirely.