Commitment Pricing Instructions

When This Applies

User mentions: Reserved Instance, RI, Savings Plan, DSP, commitment pricing, No/Partial/All Upfront, 1-year vs 3-year, or whether a commitment is worth buying.

Critical edge case: cluster has no DB instances (skipped: true)

Before running ANY analysis on a specific cluster, check whether it has DB instances attached. If aws rds describe-db-clusters --db-cluster-identifier <id> returns an empty DBClusterMembers: [] array, OR the analyzer returns skipped: true, the cluster EXISTS but has no compute — you CANNOT run a commitment-pricing analysis on it.

See skipped-cluster.md for the cluster-name heuristic (treat empty / no-instances identifiers as skipped), the causes (last instance deleted, paused, mid-migration), the required response template, and the MUST NOT guardrails.

Tasks

1. Acquire Workload Parameters

Modes:

• Live single-cluster: cluster identifier, region.
• Live fleet: region.
• Offline — provisioned: instance type, number of instances, region, optional --io-optimized flag.
• Offline — Aurora serverless: average ACU (steady baseline), region, optional --io-optimized flag.

Constraints for parameter acquisition:

• You MUST ask for all required parameters upfront in a single prompt
• You MUST detect Aurora serverless clusters in live mode and warn the user — only DSP applies; RIs do not
• You MUST warn that Database Savings Plans bill the committed hourly rate continuously, including during auto-pause periods — the user pays the committed rate even when the cluster is scaled to zero ACU
• You MUST recommend sizing the DSP commitment at or below average ACU usage to avoid overpaying during low-usage or auto-pause periods
• You MUST confirm captured parameters before running the analyzer
• You SHOULD ask about the user’s confidence horizon (1 vs 3 years) — it shapes the recommendation

2. Run the Analyzer

Constraints:

• You MUST use the script; RI and DSP math (including I/O-Optimized premium allocation) is non-trivial and must be handled consistently
• You MUST pass --region matching the workload’s region
• You SHOULD prefer --format json when post-processing and --format table for direct user display

3. Handle Skipped Clusters

The analyzer returns skipped: true for clusters with no DB instances (last writer/reader deleted, paused, or mid-migration) — no compute to commit to. An auto-paused scale-to-zero serverless instance still appears in the cluster and is analyzable; it is not an empty cluster.

Constraints:

• You MUST surface skipped clusters to the user with the script’s reason string
• You MUST NOT attempt to force a commitment comparison on a skipped cluster

4. Interpret Coverage Limits

Constraints:

• You MUST surface the script’s notes array to the user — these are the most common misconceptions
• You MUST NOT claim DSP savings for an instance family the analyzer marks as ineligible (r6g, r5, and older) because DSP only covers latest-gen families
• You MUST explain the I/O-Optimized RI vs DSP math honestly — both RI and DSP cover the full I/O-Optimized instance-hour price (base + 30% premium). With RIs, an I/O-Optimized instance consumes ~1.3x the normalized RI units of the equivalent Standard instance, so you buy ~30% more RI units (size flexibility rounds fractions) to fully cover it — no portion is forced to on-demand. DSP covers I/O-Optimized automatically and is family-agnostic, so it needs no extra-unit calculation. That operational simplicity — not a coverage gap in RIs — is why DSP is often the easier commitment vehicle for I/O-Optimized fleets.

5. Present Results

Every comparison MUST include:

1. A row-by-row table: On-Demand, 1yr RI (best payment option), 3yr RI, 1yr DSP
2. Each row’s monthly cost, savings vs On-Demand in both dollars AND percentage, upfront payment, and term length
3. A clear recommendation with the winning option and reasoning
4. Tradeoffs relevant to the decision (family lock-in, cash flow, upgrade plans)
5. The script’s notes when present (DSP ineligibility, I/O-Optimized interaction)

Constraints:

• You MUST cite both dollar and percentage savings for each option
• You MUST show upfront payment when non-zero — it is a material cash-flow consideration
• You MUST NOT run any purchase API because this workflow estimates, not commits
• You MAY reference the AWS console path for users who want to proceed (RDS → Reserved Instances, or Billing → Savings Plans)

6. Scenario Guidance

For workload-pattern questions (steady vs variable, fleet mix, migration horizon), pull guidance from scenarios.md.

Constraints:

• You SHOULD match the user’s workload to a scenario in the reference and explain why
• You MUST NOT recommend 3yr terms for workloads the user indicates may be retired or migrated within the term

Troubleshooting

See worked-examples.md §Troubleshooting for common failure modes: cluster-not-found, empty offerings, 3-year DSP requests, DSP-ineligible families, over-baseline commits, and max-capacity=0 auto-pause warnings.

Deep-Dive References

Run the analyzer when shell is available; otherwise compute inline using the references below.

• skipped-cluster.md — no-compute heuristic, required response template, MUST NOT guardrails.
• mechanics.md — DSP-vs-RI family coverage table, Aurora us-east-1 discount-rate table, savings formula, serverless + DSP gotchas. Offline rates: ../serverless-advisory/formulas-and-examples.md §Provisioned compute pricing.
• worked-examples.md — three agent response patterns plus Troubleshooting.
• basics.md — RI vs DSP mechanics, size flexibility, payment options, coverage limits.
• scenarios.md — workload-pattern scenarios plus a decision tree.