The Difference Between One Large RDS Instance and Several Smaller Instances

Applicability of This Document

Ready-to-Run Commands

# 対象: Amazon RDS（AWS CLI v2）
# 権限: rds:DescribeDBInstances
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws rds describe-db-instances \
  --query "DBInstances[].{Id:DBInstanceIdentifier,Class:DBInstanceClass,Engine:Engine,\
MultiAZ:MultiAZ,Storage:AllocatedStorage,StorageType:StorageType,Iops:Iops,\
StorageThroughput:StorageThroughput,License:LicenseModel,ReadReplicas:ReadReplicaDBInstanceIdentifiers}" \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/RDS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS \
  --metric-name CPUUtilization \
  --dimensions Name=DBInstanceIdentifier,Value=db-sample-instance \
  --start-time 2026-08-06T00:00:00Z \
  --end-time   2026-08-13T00:00:00Z \
  --period 300 \
  --statistics Average Maximum \
  --extended-statistics p95 p99 \
  --output table

# 対象: Amazon CloudWatch（名前空間 AWS/RDS）
# 権限: cloudwatch:GetMetricStatistics
# 変更作業: なし（参照のみ）
# Production 実行: 可能
for M in ReadIOPS WriteIOPS ReadThroughput WriteThroughput FreeableMemory DatabaseConnections
do
  echo "===== $M ====="
  aws cloudwatch get-metric-statistics \
    --namespace AWS/RDS \
    --metric-name "$M" \
    --dimensions Name=DBInstanceIdentifier,Value=db-sample-instance \
    --start-time 2026-08-06T00:00:00Z \
    --end-time   2026-08-13T00:00:00Z \
    --period 300 \
    --statistics Average Maximum \
    --output text
done

# 対象: Amazon RDS（AWS CLI v2）
# 権限: rds:ModifyDBInstance
# 変更作業: あり（インスタンスクラス変更 → 再起動 / Multi-AZ ではフェイルオーバー）
# Production 実行: 可能だが接続断が発生する。メンテナンス枠内で実施すること
aws rds modify-db-instance \
  --db-instance-identifier db-sample-instance \
  --db-instance-class db.r6i.4xlarge \
  --no-apply-immediately

How to Read the Results

When to Use This

• CPU utilization stays high at peak, and it is unclear whether to add capacity or consolidate
• Proposals such as "3 × 8xlarge" vs. "2 × 12xlarge" are on the table with no agreed basis for comparison
• Increasing the instance size didn't speed things up as much as expected
• Consolidating onto one instance means a single failure now stops the entire system at once
• Increasing the instance size on SQL Server RDS raised the total cost more than expected

Possible Causes (Most Likely First)

1. 01

   The premise that a writer cannot be horizontally split is not shared

   RDS read replicas can only scale out read processing. RDS has no mechanism that automatically distributes a single write workload across multiple instances. So choosing "several smaller instances" always comes with a design decision to split the workload by database or by function.

2. 02

   The bottleneck is not CPU

   If something other than CPU — an IOPS ceiling, an EBS throughput ceiling, lock contention, a single-threaded batch job — is the limiting factor, raising the instance class just leaves vCPUs idle. Deciding size without measuring what the limiting factor actually is leads to this situation.

3. 03

   Resources that scale with instance size are mixed with ones that do not

   vCPU, memory, network bandwidth, and EBS bandwidth broadly increase with instance size, but not at the same rate. Provisioned IOPS on storage is also set independently of the instance class and does not increase just by raising the class.

4. 04

   The license billing model has not been factored in

   Under SQL Server's license-included model, the license fee is tied to vCPU count. Even with the same total vCPU count, a different number-of-instances configuration can change the minimum configuration or redundancy approach per instance, so the total cost comparison is not a simple sum. Always calculate the amount with the AWS Pricing Calculator and your own contract terms.

5. 05

   Blast radius hasn't been treated as a design dimension

   The more you consolidate onto one instance, the wider the impact of that single instance's failure, maintenance, or a parameter-change mistake. Conversely, adding instances narrows the impact radius while increasing the sheer number of opportunities for a failure. When availability requirements differ by business function, the axis for a split decision is blast radius, not cost.

Diagnostic Steps

1. 1

   List the current configuration

   Read-only

   Use `aws rds describe-db-instances` to check the class, storage type, provisioned IOPS, Multi-AZ status, and the presence of read replicas.

2. 2

   Measure CPU as percentiles

   Read-only

   Pull CPUUtilization's p95, p99, and Maximum over a period that includes the busy season. The average alone is not enough to judge.

3. 3

   Measure memory sufficiency

   Read-only

   Look at the trend of FreeableMemory together with the engine's buffer cache hit ratio. If the hit ratio is low and FreeableMemory is also small, memory is the limiting factor.

4. 4

   Check whether I/O is hitting a ceiling

   Read-only

   Compare ReadIOPS+WriteIOPS against the provisioned IOPS, and ReadThroughput+WriteThroughput against the EBS bandwidth ceiling of the instance class. Refer to current AWS documentation for the ceiling values.

5. 5

   Inventory whether the workload can be separated

   Read-only

   Identify cross-database queries, shared master tables, and any distributed transactions. The more cross-cutting processing there is, the higher the cost of splitting.

6. 6

   Test candidate configurations

   Low

   Run a production-equivalent workload against a test instance restored from a snapshot, and measure how the metrics change on candidate classes. Avoid trial and error in production.

Solutions

Differences by Version and Environment

If This Doesn't Resolve It

• Check wait events inside the engine

  If things are slow without CPU or I/O hitting a ceiling, lock waits, latch waits, or network waits may dominate. This isn't an instance-size problem.

• Check whether a single query is limited to a single thread

  If a huge batch job isn't parallelized, adding vCPUs won't shrink its runtime. Check the query-side parallelism setting first.

• Check the connection pool configuration

  If DatabaseConnections is near its limit, the cause may be the application-side pool configuration rather than instance size.

• Cross-check storage's provisioned value against the measured value

  If the measured value is always well below the provisioned IOPS, storage is not the limiting factor. If it's pegged, changing the class won't help.

• Identify cross-cutting processing that will be needed after splitting

  Check whether nightly batch jobs or aggregation processing span multiple databases, based on running queries and job definitions.

Basis and Limitations of This Document

FAQ

Questions This Document Covers

• What determines throughput on RDS SQL Server
• Which is better, 3 × 8xlarge or 2 × 12xlarge
• Does adding RDS instances also speed up writes
• Should the database be split or consolidated onto one instance

What the Risk Labels Mean

• Read-onlyDoes not change data or settings.
• LowImpact is limited, but permissions and load should be checked.
• MediumMay affect performance, locking, or cost.
• HighMay cause an outage, data loss, or require recovery work.
• Expert Review RequiredRequires a separate review before applying to production.

GIIP's Scope of Support

The sizing decision itself is a one-time task once you have the measurements. What is hard is everything after that. The workload changes as the business grows, and a configuration that was right six months ago is not guaranteed to still be right today. At GIIP, an AI agent continuously collects CPU, memory, and I/O metrics for several databases on AWS and Azure and roughly 30 web services, and a human specialist judges whether a configuration review is needed once a trend approaches a ceiling. This treats sizing not as a one-off consultation but as ongoing work that starts from trend monitoring.

Related Services

• データベース性能チューニング
• AWSマネージド運用の範囲を確認する
• クラウドコスト最適化