agent priced Azure reservations against pay-as-you-go — the EA

Not specified by the original author.

TL;DR

An Enterprise Agreement discount already lowers what you pay below the public rate, so reservation math must start from the EA-discounted price. Pull the actual rate from the reservation recommendation or the rate card, compare against that, and the "savings" will be honest.

agent priced azure reservations against pay-as-you-go, the ea discount was already in effect

Use this when

• An Azure reservation recommendation shows savings that do not match realized bills.
• The math uses public pay-as-you-go prices while an EA is in effect.
• Finance questions why the reservation barely moved the invoice.

Not for this skill when

• There is no EA or the agreement expired. Pay-as-you-go is then the correct baseline.
• You are on MCA with negotiated pricing; the same principle applies but the rate source differs.

Steps

1. Confirm the EA is active and find the discount level on the enrollment. Verify: the rate card or price sheet shows the discounted unit price.
2. Get the reservation recommendation from Cost Management; it already accounts for the EA discount. Verify: the recommended savings match your manual math.
3. Recompute: (EA-discounted hourly rate minus reservation rate) times the committed hours. That is the real saving.
4. Check reservation utilization after purchase: low utilization erases the smaller-than-expected margin fast.
5. Document the EA discount as a baseline assumption in the recommendation so future math inherits it.

Variant phrasings

azure reservation savings lower than expected ea

The billing-side phrasing.

reservation recommendation ignored enterprise discount

The agent-mistake framing.

azure rate card vs pay as you go reservation math

The data-source question.

Compatibility: Azure Reservations under Enterprise Agreement enrollments; Cost Management reservation recommendations.

Why it happens

Public pricing pages are easy to scrape; EA price sheets are not. So the script prices against the public number and the EA discount, which is real money already saved, gets counted a second time as reservation savings. The recommendation looks brilliant and the invoice disagrees.

Edge cases / pitfalls

• EA discounts vary by service and tier; do not apply one blanket percentage to all reservation math.
• Reservation scope (shared vs single subscription) changes realized savings independently of the discount math.
• If the EA renews at a different discount, every open recommendation needs recomputing.

Provenance

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

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

Thread query: agent priced Azure reservations against pay-as-you-go - the EA discount was already in effect

TL;DR: An Enterprise Agreement discount already lowers what you pay below the public rate, so reservation math must start from the EA-discounted price. Pull the actual rate from the reservation recommendation or the rate card, compare against that, and the "savings" will be honest.

Not specified by the original author.

TL;DR: Rerun the comparison against the fleet's realized blended rate, not list price. List on-demand is the most expensive possible baseline, so it always flatters the RI. Pull total EC2 spend divided by total instance-hours from the billing data, split by on-demand versus spot, and compare the convertible RI against that number.

cost agent said a convertible RI would beat on-demand  -  it used list price for on-demand instead of the actual spot-mixed rate

1. Pull the fleet's actual blended compute rate from the billing data URIs total EC2 spend divided by total instance-hours over the analysis window, split by on-demand versus spot. Expected: a realized rate noticeably below list on-demand price, often 30 to 50 percent lower for spot-heavy fleets.
2. Rerun the convertible RI comparison against the blended rate, not list price. Expected: the RI advantage shrinks or disappears - many spot-mixed fleets beat convertible RIs on price.
3. Sanity-check what the RI actually buys beyond price: capacity reservations and rate stability have value even when the raw math is close. Expected: an explicit call on whether the non-price benefits justify the commitment.
4. Change the agent's comparison baseline: all RI versus on-demand math must use the realized blended rate from billing data, never list price. Expected: future recommendations reflect what the fleet actually pays.

Use this when

• An RI recommendation assumed list-price on-demand but the fleet uses spot
• The savings from a commitment look big until you check the actual blended rate
• You need commitment math based on realized rates, not catalog prices

Not for this skill when

• The fleet is 100 percent on-demand with no spot - list price is the right baseline
• Spot usage is tiny (under 5 percent) - the difference is noise, keep it simple
• You are comparing an RI against a future architecture rather than current usage - then modeled rates are appropriate

Variant phrasings

• ri vs on demand math used list price ignored spot discount
• convertible ri recommendation wrong baseline spot fleet
• how to compute blended ec2 rate for ri comparison
• agent said ri beats on demand but we run spot

Why it happens

List prices are one API call away; realized blended rates require joining billing data across purchase options. Agents take the easy path, and the easy path flatters the RI, because list on-demand is the most expensive possible baseline. The fleet's actual economics - the spot mix that already captures most of the discount - never enter the comparison.

Edge cases

• Spot prices spike during capacity crunches. Use a long enough window (3 to 6 months) that the blended rate includes at least one crunch.
• If the RI would replace spot usage, the comparison is RI versus spot, not RI versus blended. Be explicit about which hours the commitment actually covers.
• Convertible RIs can change family, but the rate comparison still needs the realized baseline. Convertibility fixes the wrong-family risk, not the wrong-baseline risk.

Provenance

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

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

Thread query: cost agent said a convertible RI would beat on-demand - it used list price for on-demand instead of the actual spot-mixed rate

TL;DR:

Not specified by the original author.

TL;DR

The reservation is a capacity commitment, and the region does not have the requested SKU available right now. Buy the reservation for a different SKU, a different region, or a shared scope, and confirm capacity before committing.

reservation order failed: not enough capacity for the requested SKU in this region

Use this when

• A reservation purchase fails with this capacity error.
• The SKU is a newer or constrained family in that region.
• You need the reservation active by a deadline.

Not for this skill when

• The purchase succeeds but the discount does not apply. That is a scope problem.
• An exchange fails. That is an eligibility problem.

Steps

1. Check regional capacity for the SKU: try the VM size availability in the target region. Verify: you know which SKUs actually have headroom there.
2. Pick the nearest alternative: same family in a nearby region, or a neighboring SKU size in the same region. Verify: the alternative meets the workload's needs.
3. Place the reservation for the available SKU or region. Verify: the order completes.
4. Scope the reservation (shared, subscription, or resource group) to match where the usage will run. Verify: the scope covers the intended subscriptions.
5. Confirm the discount applies in Cost Management within a day. Verify: usage shows the reservation discount.

Deadline variant

If the reservation must be live by a date, buy the available alternative now and plan a later exchange to the preferred SKU. Verify: the exchange rules allow the future swap.

Compatibility: Azure Reservations for VMs and other eligible services.

Why it happens

Reservations reserve real capacity, not just a price. Regions run out of specific SKUs, especially new families and GPU sizes, and the purchase API refuses rather than selling a commitment it cannot honor.

Edge cases / pitfalls

• Capacity changes over time; a SKU unavailable today may be available next week. Retry before redesigning.
• Buying in the wrong region to dodge the error discounts the wrong usage. Scope matters more than speed.
• Shared scope lets the reservation float to subscriptions where the SKU exists.
• Track reservation utilization; a capacity-forced SKU choice that goes unused still bills.

Provenance

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

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

Thread query: Azure "reservation order failed: not enough capacity for the requested SKU in this region"

TL;DR: The reservation is a capacity commitment, and the region does not have the requested SKU available right now. Buy the reservation for a different SKU, a different region, or a shared scope, and confirm capacity before committing.