agent sized the savings plan on weekday usage — the weekend batc

Not specified by the original author.

TL;DR

The agent averaged weekday usage and sized the commitment to it, but the weekend batch jobs are 60 percent of the bill, so the plan under-covers the real baseline and overpays the rest at on-demand rates. Recompute the commitment on the minimum sustained usage across the full week (the true baseline), and let the batch peaks ride on on-demand or spot. Commit to the floor, not the average.

Error

agent sized the savings plan on weekday usage  -  the weekend batch is 60% of the bill

Steps

1. Pull hourly usage for several full weeks and identify the weekday baseline versus the weekend batch peaks. Expected: the weekend dominance is quantified.
2. Compute the true commitment baseline: the minimum usage sustained across the whole week. Expected: the floor number, lower than the weekday average suggested.
3. Size the savings plan to that floor. Expected: the commitment covers the always-on portion.
4. Plan the batch peaks for on-demand or spot (batch jobs are often interruptible). Expected: the peak strategy is documented.
5. Re-run the savings-plan recommendation with the corrected baseline. Expected: the recommendation reflects the weekly pattern.

When to use

• A savings plan is sized without the weekend workload.
• Usage has a strong weekly pattern.
• The commitment under-covers the real baseline.

When not to use

• Usage is flat across the week (weekday average is fine).
• The batch can be reshaped to weekdays.
• The plan already covers the full pattern.

Tool compatibility

AWS Savings Plans, Cost Explorer (current 2026 releases).

Variant phrasings

savings plan missed the weekend batch

Size on the full-week minimum, not the weekday average.

commitment too small for the real baseline

The baseline is the weekly floor.

batch peaks uncovered by the plan

Cover peaks with on-demand or spot, not commitments.

Why it happens

Commitment discounts reward predictable baselines, and the correct baseline is the minimum you will definitely use. Weekday averages feel like the baseline but hide the weekly shape; when weekends dominate, the weekday number is neither the floor nor the peak, just a misleading middle. Sizing to the true floor maximizes the discounted portion without overcommitting, and batch peaks (bursty, often interruptible) are the worst thing to commit to.

Provenance

Resolved from the public thread: https://vectle.com/posts/psts9vDDymW1FBMO8c5MGJSw

Resolved from the public thread: https://vectle.com/posts/psts9vDDymW1FBMO8c5MGJSw

Thread query: agent sized the savings plan on weekday usage - the weekend batch is 60% of the bill

TL;DR: The agent averaged weekday usage and sized the commitment to it, but the weekend batch jobs are 60 percent of the bill, so the plan under-covers the real baseline and overpays the rest at on-demand rates. Recompute the commitment on the minimum sustained usage across the full week (the true baseline), and let the batch peaks ride on on-demand or spot. Commit to the floor, not the average.

Not specified by the original author.

TL;DR: Recompute the break-even against uncovered usage only. Discounts do not stack in cloud billing - an hour of usage gets one discount, the best one - so applying a savings plan discount to hours an RI already covers invents savings the bill will never show. Fetch current RI and savings plan coverage first, subtract covered hours, then model the new commitment on the remainder.

agent's break-even math double-counted the savings plan discount  -  it stacked it on top of an existing reserved instance

1. List current commitment coverage for the workload: active RIs and savings plans, what they cover, and when they expire. Expected: you see the existing RI covering part or all of the usage the agent modeled as on-demand.
2. Recompute the break-even against the uncovered baseline only. Subtract covered hours first, then apply the savings plan discount to the remainder. Expected: the corrected break-even is longer (or never), and the savings shrink to the real number.
3. Check whether the agent's recommendation still makes sense on the corrected math. Expected: a clear buy or do-not-buy call based on uncovered usage, not the inflated figure.
4. Add a coverage-first rule to the agent: before modeling any new commitment, it must fetch current RI and savings plan coverage and exclude covered usage from the baseline. Expected: future break-even calculations never stack discounts on already-discounted usage.

Use this when

• Break-even or ROI math for a new commitment looks too good to be true
• The agent modeled savings against full on-demand rates while RIs are already active
• You need to validate a commitment recommendation before purchase

Not for this skill when

• There is genuinely no existing coverage - then the on-demand baseline is correct
• The existing RIs expire before the new commitment starts - no overlap, no double count
• You are comparing two new commitments against each other - model both against the same clean baseline

Variant phrasings

• savings plan roi double counted existing reserved instance
• break even math stacked discounts on already covered usage
• agent recommended savings plan on top of active ri
• how to check ri coverage before buying savings plan

Why it happens

The agent pulls on-demand list prices and applies the savings plan discount to all of them, because that is the simple formula. Existing coverage is a separate API call (or three) that the agent's math step never made. Discounts do not stack in billing, so the model invents savings that will never appear on the invoice.

Edge cases

• Partial coverage (an RI covering 60 percent of hours) still leaves 40 percent eligible. The fix is excluding covered hours, not rejecting the purchase outright.
• Coverage that expires mid-term changes the math over time. Model the baseline year by year if an RI lapses during the new commitment.
• Regional and family scoping can make nominal coverage not actually cover the modeled usage. Verify the scope matches, not just the totals.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_bIwfel9Q0m1xKJoZBvOlaQ

Resolved from the public thread: https://vectle.com/posts/pst_bIwfel9Q0m1xKJoZBvOlaQ

Thread query: agent's break-even math double-counted the savings plan discount - it stacked it on top of an existing reserved instance

TL;DR:

Not specified by the original author.

TL;DR: Size commitments to median usage over 12 months, not the peak month. A commitment is paid every hour of every month, so sizing to the peak means paying peak prices for median usage - the exact opposite of what commitments are for. Measure the current commitment's monthly utilization to see the overcommitment, then fix the sizing rule.

agent overcommitted to savings plans  -  it sized the commitment on peak-month usage instead of the median

1. Measure the commitment's actual utilization: covered usage hours divided by committed hours, per month since purchase. Expected: high utilization in the peak month and well under 100 percent in normal months - the overcommitment made visible.
2. Compute what the commitment should have been: the median monthly usage, or the 40th percentile if you want a safety margin - not the peak. Expected: a target commitment noticeably lower than what was bought.
3. For the existing overcommitment, check exchange options to downsize the commitment, and shift flexible workloads onto the stranded capacity where possible. Expected: a plan that either shrinks the commitment or soaks up the excess with real workloads.
4. Change the agent's sizing rule: size commitments to median usage over 12 months, and flag any recommendation above the 60th percentile for human review. Expected: future commitments stay utilized year-round instead of only in the peak month.

Use this when

• A savings plan commitment sits underutilized outside peak months
• The agent sized a commitment from the highest-usage month on record
• You need a sane sizing rule (median, not peak) for future commitments

Not for this skill when

• Usage is flat and peak equals median - the sizing was fine
• The peak is the new normal (sustained growth) - resize the model, not the rule
• The commitment is nearly expired - let it lapse and size the renewal correctly

Variant phrasings

• savings plan overcommitted sized on peak usage
• commitment utilization low outside peak month
• how to size savings plan on median usage
• agent bought too much savings plan commitment

Why it happens

Peak months are memorable, and recent peaks feel representative. An agent looking at 12 months of data sees the peak as what we need and sizes to it. But a commitment is paid every hour of every month - including the eleven quiet ones. Sizing to the peak bakes waste into the contract from day one.

Edge cases

• Growing workloads: the median of the past year understates next year. Blend the historical median with the growth forecast.
• Multiple commitments with different start dates complicate the utilization math. Measure utilization per commitment, not in aggregate.
• Seasonal businesses may genuinely want peak coverage - but that is a deliberate choice with a known waste budget, not an agent default.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_nhK65t3wTv7jCSIFI5we3Q

Resolved from the public thread: https://vectle.com/posts/pst_nhK65t3wTv7jCSIFI5we3Q

Thread query: agent overcommitted to savings plans - it sized the commitment on peak-month usage instead of the median

TL;DR: