The Difference Between One Large RDS Instance and Several Smaller Instances

この文書の適用条件

そのまま実行できるコマンド

# 対象: 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

結果の読み方

こういう状況で使います

• 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

考えられる原因（可能性の高い順）

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.

確認手順

1. 1

   List the current configuration

   参照のみ

   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

   参照のみ

   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

   参照のみ

   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

   参照のみ

   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

   参照のみ

   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

   低

   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.

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 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.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• 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

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

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.

関連サービス

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