How to Right-Size Amazon RDS Instances: A Step-by-Step Guide
Published on · Updated on
Reworked the guide with current RDS metrics, Compute Optimizer eligibility, Database Insights, and safer class-change guidance.
Right-sizing an Amazon RDS DB instance means choosing a class that meets the database and application’s performance needs without paying for unused capacity. Low average CPU alone does not prove that an instance is oversized: memory pressure, storage waits, connections, workload peaks, and application latency can all affect the decision.
Use this sequence:
- Measure a representative workload and set the application outcomes that must hold.
- Find the limiting resource with CloudWatch, database load, and application signals.
- Compare eligible DB instance classes and validate the change plan.
- Resize during a controlled change window, then compare results with the baseline.
Choose a class for the workload
Understand DB instance class families
A DB instance class sets the compute and memory capacity of the database host. RDS class families include general purpose (db.m*), memory optimized (db.r*, db.x*, and db.z*), compute optimized (db.c*), and burstable performance (db.t*). Their exact processors, memory, storage, and network limits vary by class. Check the current RDS DB instance class documentation for engine, version, and Region support.
| Family | Typical fit | Check before choosing |
|---|---|---|
| General purpose | Workloads with balanced compute and memory needs. | Compare CPU, memory, EBS and network limits with measured peaks. |
| Memory optimized | Workloads that benefit from a larger memory-to-vCPU ratio. | Confirm memory pressure is the constraint; a larger cache alone does not fix slow queries or storage waits. |
| Compute optimized | CPU-bound workloads that need more compute capacity. | Verify that CPU, rather than I/O, locks, or application behavior, is driving the latency. |
| Burstable performance | Workloads with intermittent CPU demand. | Review baseline CPU, credit metrics, and any surplus-credit charges under Unlimited mode. |
Class availability and capabilities depend on the engine, version, and Region. Compare the specifications of the exact candidate classes rather than relying on a family name alone.
Match the class to the bottleneck
Use a class change when the evidence points to a compute or memory capacity limit. If the database is waiting on storage, blocked by locks, or spending time on inefficient queries, moving to a larger class may add cost without addressing the cause. Storage capacity, storage type, provisioned IOPS, and throughput are separate choices; review them separately when the storage signals point to a limit.
For each candidate, check engine and software compatibility, vCPU and memory, processor architecture where relevant, network and EBS bandwidth, and local-storage features. A class can have a different performance profile even when its CPU and memory appear to fit.
Review the signals that affect sizing
Amazon RDS publishes CloudWatch metrics in the AWS/RDS namespace. Select metrics that fit the symptom, and compare them with application latency, errors, throughput, and request volume. Common signals include:
CPUUtilization: CPU use over time. Compare peaks and sustained periods with query activity and application latency.FreeableMemory: memory available to the database host, in bytes. It is not a direct measure of memory used by a particular query or application.DatabaseConnections: client network connections; it does not count every database session.- Read and write latency, IOPS, and throughput: use these with queue depth and storage settings to investigate I/O pressure.
FreeStorageSpace: available storage capacity, which is different from instance-class capacity.- Burst and CPU-credit metrics: useful for supported burstable classes.
Metric availability varies by engine and configuration. See the AWS RDS CloudWatch metrics reference for definitions and limits.
Follow a measured resizing workflow
Build a representative baseline
Collect enough data to include ordinary traffic, known busy periods, scheduled jobs, backups, and recurring monthly or seasonal work. The right observation period depends on how the workload varies; a quiet week is not a useful baseline if the database has a month-end reporting peak.
Record application outcomes such as request latency, error rate, and throughput alongside RDS metrics. Define the service objectives and operating headroom the database must maintain. Do not use a universal CPU, memory, or IOPS threshold as a substitute for those workload requirements.
Find what is limiting performance
CloudWatch shows resource and storage trends, while CloudWatch Database Insights helps explain database load by waits and SQL activity. Database load is average active sessions, not CPU utilization or the number of open connections. Compare the load breakdown with CPU, memory, storage metrics, database logs, and the application symptom before deciding that the instance class is the cause. See the guide to using CloudWatch Database Insights with RDS for more on interpreting those signals.
AWS retired the Performance Insights console experience on July 31, 2026, and moved users to Database Insights. Some RDS settings and API parameters still use the Performance Insights name. Follow the current Database Insights documentation for the monitoring view and configuration available to your engine and Region.
Plan and apply a class change
Confirm that the target class supports your DB engine and version in the Region, and that it meets the workload’s resource and compatibility needs. Test the candidate where a representative test environment is available. Before production, check backups, pending modifications, the maintenance plan, application connection behavior, and a rollback path.
Changing an RDS DB instance class causes downtime. RDS applies the change during the next maintenance window unless you request immediate application. Multi-AZ can reduce the impact of some changes, but plan for an interruption and check the behavior for your deployment. If you choose to apply a change immediately, RDS also applies other pending modifications.
For a provisioned RDS DB instance, the CLI command has this form:
aws rds modify-db-instance \
--db-instance-identifier orders-prod \
--db-instance-class db.m6i.large \
--no-apply-immediately
This example schedules the class change for the maintenance window. Replace the identifier and class with values for your DB instance, and verify that the class is orderable for its engine, version, and Region. For Aurora or a Multi-AZ DB cluster, check the current procedure for that deployment because some settings are managed at the cluster level. See AWS guidance on DB instance modification timing and downtime before choosing when to apply it.
Use Compute Optimizer within its limits
AWS Compute Optimizer can help compare candidate instance and storage configurations, but its RDS coverage is limited. It currently generates database recommendations for RDS for MySQL, RDS for PostgreSQL, Aurora MySQL-Compatible Edition, and Aurora PostgreSQL-Compatible Edition, and only for supported resource types and instance classes. See the live Compute Optimizer support list before expecting a recommendation for another engine or class.
For an RDS or Aurora DB instance, AWS requires at least 30 hours of CloudWatch metrics within the previous 14 days. AWS also documents that Performance Insights must be enabled for Compute Optimizer to identify over-provisioned DB instances. The current console experience is Database Insights, though some setup fields retain the older Performance Insights name; use the current RDS and Database Insights instructions for your engine. The paid enhanced infrastructure metrics preference extends the recommendation lookback to as many as 93 days. Review the current database recommendation prerequisites and enhanced metrics details.
Treat a recommendation as a candidate. Check its lookback period, performance-risk information, analyzed metrics, and projected limits against your own workload evidence and service objectives before changing production capacity.
Keep sizing decisions current
Review after changes and workload shifts
After a resize, compare similar workload periods before and after the change. Check application latency, errors, and throughput along with CPU, available memory, connections, and storage signals. If the application loses headroom or misses an objective, restore the previous class or test another candidate. Revisit sizing after meaningful changes in traffic, database configuration, software, or service objectives.
Consider RDS Reserved DB Instances after sizing
Once the class and expected steady usage are understood, compare On-Demand charges with Amazon RDS Reserved DB Instance offerings. An RDS reservation is a one- or three-year billing commitment for discounted matching usage; it is not a physical database instance or a capacity reservation. The discount applies automatically when eligible usage matches the reservation’s Region, engine, class, and applicable license or deployment terms. Some engines and license models support size flexibility within the same instance family; for example, RDS for SQL Server and Oracle License Included are not size-flexible. Aurora has separate reservation guidance. Review the current RDS Reserved DB Instance terms and Aurora reservation terms before buying. These are distinct from EC2 Reserved Instances.
Alert on workload conditions
Use CloudWatch alarms for signals that represent a service objective or a capacity risk with a clear response. Choose the metric, statistic, period, and threshold from the workload’s behavior; a static CPU threshold that is unrelated to application impact can create noise or miss a real issue. Pair resource alerts with application latency or error signals where that gives operators a clearer picture. The site’s guide to CloudWatch alarm thresholds and conditions explains how to set useful alarm periods and evaluation rules.
Summary
Right-size an RDS instance from representative workload data, not a quiet average or a generic threshold. Identify the limiting resource, compare supported class options, plan for the downtime caused by a class change, and verify application performance and cost after the change. Use Compute Optimizer only when the engine, class, metrics, and monitoring configuration meet its current requirements; consider an RDS Reserved DB Instance only after the desired capacity and steady usage are clear.