{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibe6cuac7rfyo4eegnadpxjspy6yqb4kleiy67ifoebgmism46rsq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mplaxtfzn652"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreifioarrgvr7prramx5mrknaxk7jch4qncditi77dcx64nei3smquu"
    },
    "mimeType": "image/webp",
    "size": 23696
  },
  "path": "/muskan_8abedcc7e12/how-to-right-size-rds-instances-without-downtime-1lhp",
  "publishedAt": "2026-07-01T09:36:31.000Z",
  "site": "https://dev.to",
  "tags": [
    "aws",
    "database",
    "devops",
    "cloud",
    "Blue/Green Deployments for RDS",
    "logical replication limits",
    "CloudNativePG on Kubernetes"
  ],
  "textContent": "##  Quick Answer (TL;DR)\n\n> 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.\n\n##  Why this happens\n\nRDS 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.\n\n##  Fix #1: Use RDS Blue/Green Deployments\n\nThe 2026 default. Available for RDS MySQL, MariaDB, PostgreSQL, and SQL Server (added mid-2025).\n\nSteps:\n\n  * In the RDS console, select the instance and choose **Actions → Create Blue/Green Deployment**.\n  * Set the **Green** instance to your target instance class.\n  * AWS creates a full standby using logical replication, keeps it in sync, and validates health.\n  * When ready, click **Switch over**. Cutover typically takes under 60 seconds. Applications reconnect using the same endpoint.\n\n\n\nCommand-line equivalent:\n\n`aws rds create-blue-green-deployment --blue-green-deployment-name resize-prod --source arn:aws:rds:... --target-db-instance-class db.m6i.xlarge`\n\nBest when: your engine supports it and you can tolerate the extra cost of running two instances for the sync window.\n\n##  Fix #2: Read-replica promotion\n\nFor engines or versions that do not yet support Blue/Green, or for cross-region resizing.\n\nSteps:\n\n  * Create a read replica with the desired new instance class.\n  * Wait for the replica to catch up (near-zero lag).\n  * Point application writes to the read replica endpoint (requires connection-string change or DNS switch).\n  * Promote the read replica to a standalone primary with `aws rds promote-read-replica --db-instance-identifier <replica-id>`.\n  * Delete the old primary.\n\n\n\nBest when: you already have a replica strategy in place, and application code can handle a DNS or endpoint change.\n\n##  Fix #3: Multi-AZ failover with resized standby\n\nThe edge case. Works when Blue/Green is not available and you cannot introduce a new endpoint.\n\nSteps:\n\n  * On a Multi-AZ instance, temporarily disable Multi-AZ, resize the primary, then re-enable Multi-AZ.\n  * 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.\n\n\n\nThe downtime is the failover time, usually 30 to 120 seconds. Best when a full Blue/Green cutover is not feasible.\n\n##  How to prevent this\n\nRight-sizing is only a problem if you overprovision or underprovision in the first place. Three practices avoid the resize cycle.\n\n  * **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.\n  * **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.\n  * **Set CloudWatch anomaly-detection alarms** on `CPUUtilization`, `DatabaseConnections`, and `FreeableMemory`. Catch drift before it forces an emergency resize.\n\n\n\n##  FAQ\n\n**How long does a Blue/Green cutover actually take?**\nTypically 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.\n\n**Does Blue/Green work with encrypted RDS instances?**\nYes, on all supported engines as of 2025. The Green instance inherits the KMS key or you can specify a new one.\n\n**Will connections survive the cutover?**\nNo. Existing connections drop and reconnect. The application must handle transient connection errors, which is standard for any HA database interaction.\n\n**Can I use Blue/Green to change the engine version too?**\nYes. Blue/Green now supports minor and major version upgrades in the same cutover as the resize. Test the upgrade path first.\n\n**What about RDS Serverless v2?**\nServerless v2 autoscales compute in the range you configure, so you rarely need a manual resize. Adjust the ACU range instead.\n\n##  Related guides\n\n  * The AWS docs page on Blue/Green Deployments for RDS has the current engine and version support matrix.\n  * For Postgres specifically, see logical replication limits which affect Blue/Green.\n  * Compare against CloudNativePG on Kubernetes if you are evaluating a move off RDS entirely.\n\n",
  "title": "How to right-size RDS instances without downtime"
}