Setting the file. One moment.
Chapter 57 · Amazon Aurora MySQL
Subchapter 57.8
references/io-optimized-data-collection.mdMarkdown4 KBView on GitHub
The analyzer pulls these from the AWS/RDS namespace at cluster level:
| Metric | Statistic | Purpose |
|---|---|---|
VolumeReadIOPs | Sum | Read I/O requests (billed ops) |
VolumeWriteIOPs | Sum | Write I/O requests (billed ops) |
VolumeBytesUsed | Average | Storage GiB (for storage cost) |
Dimension: DBClusterIdentifier. Metrics are pulled at 1-hour granularity and summed over the lookback window.
Note on naming: Despite the name “IOPs”, VolumeReadIOPs and VolumeWriteIOPs report I/O request counts per 5-minute period, not per-second rates. The script normalizes them accordingly.
describe-db-clusters and describe-db-instances provide:
storage_type: aurora = Standard, aurora-iopt1 = I/O-Optimized)VolumeBytesUsed)The analyzer extrapolates observed I/O to a 30-day (730-hour) month:
monthly_io = (observed_io / observed_hours) × 730Minimum viable window: 7 days. Below this, Aurora workloads often miss a full weekly cycle (weekdays vs weekends can differ 3-5×), producing misleading extrapolations.
The script sets data_quality accordingly:
< 3 days: insufficient — do not recommend a switch on this data3-7 days: short — recommendation flagged as tentative7-14 days: adequate — recommendation reliable14+ days: good — recommendation high-confidenceThe 30-day limit on changing a cluster’s storage type (via modify-db-cluster --storage-type) is one-directional: switching Standard (aurora) → I/O-Optimized (aurora-iopt1) is limited to once every 30 days per cluster, while reverting I/O-Optimized → Standard can be done at any time (no cooldown). So a premature switch into I/O-Optimized is not a 30-day cost lock-in — you can revert to Standard immediately. The real cost of churning is that, once you revert, you cannot re-enable I/O-Optimized again for another 30 days.
When the data_quality tag is insufficient or short, the cost of a bad decision is the one-way commitment in the Standard → I/O-Optimized direction: if you switch in on thin data and then want to switch in again after a better read of the workload, you are gated by the 30-day cooldown on that direction. Surface this cooldown to the user as part of the reasoning to wait. Do not describe the Standard → I/O-Optimized direction as freely repeatable; that direction is a meaningful commitment (reverting to Standard, by contrast, is always available).
Aurora I/O-Optimized pricing applies at the cluster level. Compute cost is the sum of all instance-hours in the cluster:
compute_monthly = Σ (instance_price_per_hour × 730) for each instance in clusterThe 30% premium multiplies the full compute cost. A cluster with one writer + two readers multiplies the premium by 3× the base instance cost.
I/O billing counts all reads and writes across all instances in the cluster — readers are billed for their reads. The analyzer sums CloudWatch volume I/O across the cluster, which already reflects this.
For Aurora serverless, the analyzer uses observed ACU-hours from ServerlessDatabaseCapacity to compute compute cost. The 30% I/O-Optimized premium applies to the ACU-hour rate, same as provisioned.
When AWS credentials aren’t available, the user provides:
--instance <type> — e.g., db.r6g.2xlarge--num-instances <N> — total instances in the cluster--storage-gib <N> — cluster volume size--monthly-io-millions <N> — estimated monthly I/O requests in millionsThe user can get monthly I/O from the Cost Explorer (filter on “Amazon Relational Database Service” + usage type containing StorageIOUsage) or from the AWS billing console line items.