/amazon-aurora-mysql

Aurora I/O-Optimized — Worked Examples

Companion to instructions.md. Pricing constants, cost formulas, the data-quality table, and skipped: true handling are in pricing-tables.md.

Worked example — offline assessment

User: 2× db.r6g.2xlarge, 800 GiB storage, 1.2 billion I/O requests per month, region us-east-1 (assumed), no AWS credentials.

Agent response pattern:

1. Announce reference: "Loading references/io-optimized-instructions.md."

2. Print the script command as text:

   python3 scripts/io_optimized_analyzer.py offline \
     --instance db.r6g.2xlarge --num-instances 2 \
     --storage-gib 800 --monthly-io-millions 1200

3. Compute inline (db.r6g.2xlarge Standard rate $1.038/hr):

   • Standard compute: $1.038/hr × 730 × 2 = $1,515/mo.
   • Standard storage: 800 × $0.10 = $80/mo.
   • Standard I/O: 1,200 × $0.20 = $240/mo.
   • Standard total: $1,515 + $80 + $240 = $1,835/mo.
   • I/O-Optimized compute: $1.038 × 1.30 × 730 × 2 = $1,970/mo.
   • I/O-Optimized storage: 800 × $0.225 = $180/mo.
   • I/O-Optimized total: $1,970 + $180 + $0 = $2,150/mo.
   • I/O as % of Standard: $240 / $1,835 = 13.1%. Below 25% threshold.
   • Switch cost: +$315/mo ($2,150 − $1,835).

4. Recommendation: Standard (stay). I/O is ~13% of total, below the 25% breakeven. Switching would cost ~$315/mo more (+17%). Revisit only if monthly I/O exceeds ~2.5 billion requests at this storage size.

Worked example — insufficient data

User: cluster new-cluster-2026 only 4 days old. Should I use I/O-Optimized?

Agent response pattern:

1. Announce reference: "Loading references/io-optimized-instructions.md."

2. State the data-quality finding: 4 days of data is insufficient for a decision. The 25% breakeven rule depends on a representative sample of monthly I/O, and 4 days does NOT capture:

   • Weekday vs weekend variance — weekend I/O is commonly 40–60% lower than weekday; a 4-day window starting Tuesday would over-estimate monthly I/O by ~20%.
   • End-of-month / end-of-period spikes — reporting loads, batch windows, month-close jobs.

3. Surface the 30-day storage-type switch cooldown (Standard → I/O-Optimized direction only): switching to I/O-Optimized is limited to once every 30 days, while reverting to Standard is allowed at any time — so a decision to move to I/O-Optimized on thin data is a month-long commitment.

4. Recommend the user wait at least 14 days (minimum) before re-evaluating; ideally 30 days to capture at least one full monthly cycle.

5. Print the re-evaluation command for when they're ready:

   python3 scripts/io_optimized_analyzer.py \
     --cluster new-cluster-2026 --region <their-region> --days 30

6. Mention the specific CloudWatch metrics to watch in the meantime: VolumeReadIOPs and VolumeWriteIOPs under AWS/RDS with dimension DBClusterIdentifier=new-cluster-2026. Also monitor VolumeBytesUsed for storage-growth trends.

Worked example — skipped: true for an empty cluster

User: "Run the commitment pricing analyzer on my Aurora cluster paused-cluster-1 in us-east-1."

Though this is a commitment-pricing prompt, the same skipped: true semantics apply — and if the cluster has no instances, both commitment-pricing AND I/O-Optimized analyzers skip it.

Agent response pattern:

1. Announce reference: "Loading references/commitment-pricing-instructions.md (also relevant: references/io-optimized-instructions.md §skipped: true)."
2. After describe-db-clusters returns DBClusterMembers: [], surface: skipped: true, reason: "no DB instances — likely last writer/reader deleted, paused, or mid-migration".
3. Explain common causes: last reader/writer instance deleted (no compute attached), a paused cluster, or a cluster mid-migration. Note: a Blue/Green switchover or modify-db-instance reboot does NOT empty DBClusterMembers and will not trigger this skip.
4. Next steps:
   • If last instance deleted / paused: resume the cluster (create a DB instance in it), let it run for 14+ days, then re-run the assessment.
5. Do NOT suggest the cluster does not exist; it exists, just without compute.