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

```text
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