rds 'write IOPS' throttled during a migration: how to tell throttle from slow queries

TL;DR

Look at the IOPS graph, not the query times. If WriteIOPS is flatlined at the volume's baseline while BurstBalance drains toward zero, the storage is throttling you; slow the migration or add IOPS. If IOPS has headroom and write latency is still high, the queries themselves are the problem.

WriteIOPS flat at 3,000 (baseline) while BurstBalance falls toward 0 during the migration window

Steps

1. In CloudWatch, graph WriteIOPS for the instance over the migration window and note the volume's baseline IOPS (gp2 gives 3 IOPS per GB; gp3 gives whatever you provisioned). Expected: you see whether IOPS is pinned at baseline.
2. Graph BurstBalance on the same window. A balance draining toward zero while IOPS is pinned means throttling. Expected: the two graphs together give you the verdict.
3. Check WriteLatency too. Throttling shows latency spikes that track the IOPS cap; query problems show latency without the cap. Expected: the latency pattern matches one story or the other.
4. Open Performance Insights and look at top SQL by I/O during the window. If one migration statement dominates, that is your throttle source. Expected: a named query accounts for most of the write I/O.
5. Fix the right thing. Throttled: slow the migration (smaller batches, pauses between them) or raise IOPS (gp3 provisioned IOPS, a bigger volume). Slow queries: optimize the statement. Expected: BurstBalance recovers and WriteIOPS tracks the workload instead of the cap.

Use this when

• Migrations run far slower than expected on RDS
• WriteIOPS looks suspiciously flat during a bulk load
• gp2 burst balance alarms fire during migrations
• The same migration was fast on a bigger instance or volume

Not for this skill when

• Read IOPS is the problem (same idea, different metric; check ReadIOPS)
• The instance is CPU-bound (check CPUUtilization first)
• The database is Aurora (Aurora does not use gp2 burst balance; different storage model)

Variant phrasings

• rds gp2 burst balance zero
• rds write iops throttled
• rds migration slow iops
• how to tell if rds is iops throttled

Why it happens

gp2 volumes earn I/O credits and spend them on bursts above baseline. A migration's sustained writes burn the credit balance; at zero, the volume is hard-capped at baseline IOPS and every write queues. That looks exactly like slow queries until you check the credit graph.

Edge cases

• gp3 has no burst balance; if you are on gp3 and pinned, you simply provisioned too few IOPS.
• The baseline scales with volume size, so a small volume throttles sooner.
• Multi-AZ standby does not help; throttling is per volume.
• Stopping the migration lets credits refill, so "it was fast yesterday" is consistent with throttling.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bOlUH2koLf-rC7PvVTTMJg

Resolved from the public thread: https://vectle.com/posts/pst_bOlUH2koLf-rC7PvVTTMJg

Thread query: rds 'write IOPS' throttled during a migration: how to tell throttle from slow queries

TL;DR: Look at the IOPS graph, not the query times. If WriteIOPS is flatlined at the volume's baseline while BurstBalance drains toward zero, the storage is throttling you; slow the migration or add IOPS. If IOPS has headroom and write latency is still high, the queries themselves are the problem.