IO Optimized Pricing Tables

Pricing constants (us-east-1)

These us-east-1 constants are only a fallback baseline. AWS does not publish a fixed regional multiplier, and Standard vs I/O-Optimized rates do not scale by an identical regional factor — storage, instance, and I/O rates each vary independently by region. For any non-us-east-1 region, the agent MUST use the analyzer’s live per-region, per-component rates fetched from the AWS Pricing API rather than applying an estimated multiplier. Any offline cross-region approximation is a rough estimate with no AWS-published basis.

Monthly cost formulas

Standard total = (compute_$hr × 730 × num_instances) + (storage_GiB × $0.10) + (monthly_io_millions × $0.20)

I/O-Optimized total = (compute_$hr × 1.30 × 730 × num_instances) + (storage_GiB × $0.225) + 0 (no I/O charge)

I/O as % of Standard total = (monthly_io_millions × $0.20) / Standard_total × 100

Data-quality / lookback-window table

The storage-type switch has a 30-day cooldown that applies to the 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. Do NOT recommend a Standard → I/O-Optimized switch on thin data because that direction commits you to the outcome for a full month.

Why weekly patterns matter: most OLTP clusters see 40–60% lower I/O on weekends. A cluster that looks like 20% I/O on Mon–Thu can average 14% over a full week. The script’s extrapolation over short windows does not capture this. Always wait at least one full week of observation, and recommend 14 days minimum before committing.

skipped: true — what it means

The analyzer returns skipped: true when a cluster has no DB instances attached. This is NOT a “cluster not found” — the cluster exists, but there is no compute to price.

Common causes:

• Paused Aurora cluster — a cluster whose last reader/writer was actually deleted. Storage still exists. (Note: an Aurora serverless instance that has auto-paused at scale-to-zero stays in DBClusterMembers with status available and IS analyzable — it is not an empty cluster and is not skipped.)
• (Not a zero-instance cause) Instance being replaced/rebooting — an operation like a Blue/Green switchover or a modify-db-instance reboot does NOT empty DBClusterMembers; the instance is still listed as a member (just briefly in a rebooting/replacing state), so the cluster is NOT skipped for empty membership.

When the analyzer skips a cluster, you MUST:

1. Surface the skipped: true result verbatim with the reason string.
2. Name the likely cause (last instance deleted, paused, or mid-migration).
3. Offer appropriate next steps:
   • Last instance deleted / paused: resume the cluster (attach a writer), let it run for 14+ days, then re-run the assessment.
4. NOT attempt to force a comparison or include the cluster in fleet dollar totals.

Troubleshooting

“Cluster not found”. Wrong cluster ID or region. Verify with aws rds describe-db-clusters --region <region>.

CloudWatch returns zero I/O data. Cluster is new, paused, or wrong region. Confirm with aws cloudwatch list-metrics --namespace AWS/RDS --dimensions Name=DBClusterIdentifier,Value=<cluster>. If genuinely idle, Standard is correct.

Live pricing fetch fails (ExpiredToken / AccessDenied). Refresh credentials. Script falls back to static us-east-1 pricing; flag that caveat.

“Skipped — no DB instances”. A paused cluster or one whose last reader/writer was deleted (an empty cluster still incurs storage charges). Restore or add an instance before assessing the Standard vs I/O-Optimized decision. (Note: Aurora Limitless Database — which is locked to I/O-Optimized — is an Aurora PostgreSQL-only capability and does not apply to Aurora MySQL.)

Result close to the 25% threshold (22–28%). May flip month-to-month. Monitor 1–2 months before committing, especially if seasonal.