Commitment Pricing Workflow

When This Applies

User mentions: “should I buy a reserved instance / RI”, “how much would a savings plan save”, “compare 1-year vs 3-year”, “RI vs DSP”, “commitment pricing for RDS”, “No Upfront / Partial Upfront / All Upfront”, Multi-AZ pricing. Do NOT use this workflow for Aurora — Aurora has a separate commitment-pricing skill with different rules (Aurora DSP is 1yr-only; Aurora RIs interact with I/O-Optimized).

Tasks

1. Acquire Workload Parameters

The analyzer supports two modes.

Live single-instance: DB instance identifier, region. Offline: instance type, engine (mysql, mariadb, or postgres), number of instances, region, optional --multi-az flag.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST ask which engine (mysql, mariadb, or postgres) for offline mode
• You MUST confirm captured parameters before running the analyzer
• You SHOULD ask about the user’s confidence horizon (1 vs 3 years)
• You MUST NOT default the engine — RDS RIs are engine-specific, and a wrong engine produces wrong numbers

2. Run the Analyzer

Constraints:

• You MUST use the script; RI and DSP math is non-trivial and combines multiple API surfaces
• You MUST pass --region and (for offline mode) --engine matching the workload
• You SHOULD pass --format json (the analyzer emits JSON) and present the results as a formatted table to the user

3. Interpret Coverage Limits

Constraints:

• You MUST surface the script’s notes array — these cover common misconceptions
• You MUST NOT claim DSP savings for instance families the analyzer marks as ineligible (r5, r6g, older). DSP only covers latest-generation families (r7g, r7i, r8g, r8gd, m7g, m7i, c7g, c7i, x8g).
• You MUST explain Multi-AZ RI pricing: Multi-AZ RIs cost more than Single-AZ, and a Single-AZ RI does NOT cover a Multi-AZ instance. The user must buy the correct deployment type.
• For RDS, there is NO Serverless option — do NOT mention ACU pricing, scale-to-zero, or any Aurora-specific concepts
• You SHOULD cite commitment-basics.md for RI vs DSP mechanics and commitment-scenarios.md for workload-pattern decisions

4. Present Results

Every comparison MUST include:

1. A table: On-Demand, 1yr RI (best payment option), 3yr RI, 1yr DSP, 3yr DSP
2. Each row’s monthly cost, savings vs On-Demand in dollars AND percentage, upfront payment, term
3. A clear recommendation with the winning option and reasoning
4. Tradeoffs: family lock-in, cash flow, upgrade plans, Multi-AZ considerations, region lock-in
5. The script’s notes when present (DSP ineligibility, Multi-AZ separation, etc.)

Constraints:

• You MUST cite both dollar and percentage savings — neither alone is sufficient (dollars alone hide the scale; percentages alone hide the magnitude)
• You MUST show upfront payment when non-zero — cash-flow impact matters for finance approval
• You MUST NOT run any purchase API (purchase-reserved-db-instances-offering, Savings Plans purchase calls) because this workflow is advisory-only
• You MAY reference the AWS console path (RDS → Reserved Instances, or Billing → Savings Plans) so the user knows where to execute the commitment manually

5. Scenario Guidance

For workload-pattern questions, pull guidance from commitment-scenarios.md.

Constraints:

• You SHOULD match the user’s workload to a scenario in the scenarios reference and explain why
• You MUST NOT recommend 3yr terms for workloads the user indicates may be retired within the term, because RIs and DSPs are use-it-or-lose-it
• You MUST warn that RDS RIs do NOT transfer to Aurora if the user is considering Aurora migration within the term — different engine, different commitment product
• You MUST warn that RDS RIs are region-locked if the user is considering moving the workload to a different region

Troubleshooting

• Instance not found: Wrong identifier or region. Verify with aws rds describe-db-instances --region <region>.
• RI/DSP fetch returns empty: Newly launched instance types or non-standard regions. Offer offline mode.
• 3-year DSP: A 3-year Database Savings Plan exists for RDS (unlike Aurora which is 1yr only). Present both 1yr and 3yr DSP options.
• DSP not available for this family: Instance family older than DSP coverage. Explain RI is the only option; suggest migration to newer family.
• Multi-AZ confusion: Multi-AZ RIs are separate offerings from Single-AZ. The user must match the deployment type.

References

• commitment-basics.md — RI vs DSP mechanics, payment options, break-even, RDS-vs-Aurora differences
• commitment-scenarios.md — workload-pattern decision scenarios and quick decision tree