Setting the file. One moment.
Chapter 57 · Amazon Aurora MySQL
Subchapter 57.4
references/commitment-pricing-scenarios.mdMarkdown4 KBView on GitHub
Match the user’s workload to one of these patterns, then recommend accordingly.
Example: e-commerce backend on db.r7g.2xlarge, two readers + one writer, running 24/7 for the last 2 years, no plan to migrate.
Recommendation: 3yr All-Upfront RI for the writer and baseline readers. Highest savings (~55-60% off on-demand).
Watch out: If you might migrate to r8g before the term ends, the RI doesn’t transfer — you’d be paying for unused r7g capacity. In that case, 1yr RI or DSP is safer.
Example: Stable workload, but the team is actively evaluating newer instance generations and may switch within 12-18 months.
Recommendation: 1yr DSP. Covers Gen-7 and newer Aurora instance families (does NOT cover r6g/r5 or older — use RIs for those). Up to ~20% discount on provisioned instances (up to ~35% on serverless). Family-agnostic within the Gen-7+ set; you keep the freedom to switch generations or move to serverless mid-term.
Example: Batch processing jobs that run 8 hours/day, 5 days a week. Effective utilization ~24%.
Recommendation: Stay on-demand, or consider switching to Aurora serverless. RI break-even is ~40-50% utilization — below that, commitments cost more than on-demand. If a migration to serverless is viable, the auto-scale-to-zero benefit often beats any commitment.
Example: Aurora serverless cluster, min 2 ACU / max 32 ACU, averaging 6 ACU over the month.
Recommendation: RIs don’t apply. Compare 1yr DSP (on the average ACU commitment) vs on-demand. DSP typically saves 20-30% on ACU-hours. Only commit to the baseline ACU level you’re confident will be consumed 24/7 — the hourly $/hr commitment bills whether you use it or not.
Example: 10 clusters, mix of r6g (legacy), r7g (new), and serverless.
Recommendation: Hybrid.
Model each segment separately in the analyzer. A single account-wide DSP can span the new-gen provisioned + serverless portions, while RIs cover the legacy fleet.
Example: Production cluster on db.r7g.4xlarge using Aurora I/O-Optimized (30% compute premium).
Recommendation: Both RI and DSP can discount I/O-Optimized compute. RIs apply to the full I/O-Optimized rate, but I/O-Optimized consumes ~30% more normalized units per hour than Aurora Standard, so to fully cover an I/O-Optimized cluster with RIs you must purchase ~30% more reserved units (or rely on RI size flexibility). DSP covers I/O-Optimized ACU/compute usage automatically without that extra step and stays family-agnostic, which is often simpler for I/O-Optimized fleets — run the numbers; the analyzer accounts for the 1.3x factor when you pass --io-optimized.
Example: App being migrated off Aurora to DynamoDB / Redshift within 6-12 months.
Recommendation: No commitment. RI and DSP are use-it-or-lose-it for the full term. The break-even point on a 1yr commitment assumes full-term usage; shutting down at month 8 wastes 4 months of commitment.
Is the cluster Aurora serverless?
├── YES → Only DSP. Compare DSP 1yr vs on-demand.
└── NO
├── Is utilization < 40%? → Stay on-demand (or move to serverless)
├── Is the instance family r6g / older?
│ ├── YES → RI only (DSP doesn't cover). 1yr vs 3yr based on confidence.
│ └── NO → Compare RI vs DSP. DSP if flexibility matters, 3yr RI if locked in.
└── Is the cluster I/O-Optimized? → Lean DSP for simplicity; if using RI, buy ~30% more reserved units (or use size flexibility) since I/O-Optimized consumes 1.3x normalized units.Never commit to more than your steady baseline. A cluster that runs at 10 ACU most of the time but spikes to 40 should commit only to 10 ACU worth of DSP — the spikes can stay on-demand.
For RIs, commit to instances that run 24/7 (the writer always, long-lived readers). Do not RI a reader that’s torn down during off-hours.