agent's savings math used usd list prices for the eu accounts —

Not specified by the original author.

TL;DR

The agent priced EU savings with USD list prices, but the accounts pay in euros and the exchange rate moved, wiping out the supposed savings. Redo the math in each account's billing currency using current exchange rates, and report savings per currency. Exchange rates are a cost input, not a rounding detail.

Error

agent's savings math used usd list prices for the eu accounts  -  the exchange rate swing ate the savings

Steps

1. Confirm the currency mismatch: the EU accounts' bills are in euros while the math used dollars. Expected: the billing currencies are verified.
2. Get the current exchange rate (and the rate trend, to see the swing). Expected: the rate move that ate the savings is quantified.
3. Recompute the savings in euros with the current rate. Expected: the true savings (or loss) per account is known.
4. Change the agent to price every account in its own billing currency, converting only for rollup reporting. Expected: per-currency math is the default.
5. Re-run the savings analysis. Expected: the recommendations reflect real, currency-aware savings.

When to use

• Savings math crosses billing currencies.
• Exchange-rate moves invalidate USD-based calculations.
• Multi-currency cloud portfolios.

When not to use

• All accounts bill in one currency.
• The rate move is negligible.
• The savings are in usage reduction, not price arbitrage.

Tool compatibility

AWS, GCP, Azure multi-currency billing (current 2026 releases).

Variant phrasings

usd math on eur bills

Price in the billing currency.

fx swing erased the savings

Include the exchange rate as a cost input.

cross-currency savings miscalculated

Compute per currency, convert only for rollups.

Why it happens

Cloud list prices are published in USD, which makes USD the convenient modeling currency, but accounts in other regions pay in local currency at the prevailing rate. When the rate moves, the USD-modeled savings and the actual bill diverge, sometimes past zero. Currency-aware math treats the exchange rate as what it is: a variable cost that belongs in the equation.

Provenance

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

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

Thread query: agent's savings math used usd list prices for the eu accounts - the exchange rate swing ate the savings

TL;DR: The agent priced EU savings with USD list prices, but the accounts pay in euros and the exchange rate moved, wiping out the supposed savings. Redo the math in each account's billing currency using current exchange rates, and report savings per currency. Exchange rates are a cost input, not a rounding detail.

Not specified by the original author.

TL;DR: Pull the actual cross-region transfer spend from the cost and usage report before believing any region-move recommendation. In this case the transfer fees were larger than the compute delta, so the move loses money every month. Make the transfer line item mandatory in the agent's savings template, computed from real replicated gigabytes, never assumed zero.

Representative numbers from the incident:

projected compute savings from region move: $1,150 / month
actual S3 cross-region replication charges: $2,860 / month

1. Get current transfer spend grouped by usage type from Cost Explorer for the last three full months. Command: aws ce get-cost-and-usage --time-period Start=2026-07-01,End=2026-10-01 --granularity MONTHLY --metrics BlendedCost --group-by Type=DIMENSION,Key [your value] --filter file://transfer-filter.json Expected: monthly transfer totals you can compare against the claimed compute savings.

2. Measure how much data actually moves: check S3 replication metrics and CloudWatch replication bytes for the lake buckets. Expected: a gigabytes-per-month figure for every replication rule, not a guess.

3. Multiply replicated gigabytes by the cross-region transfer rate for the source region and add it as an explicit line in the savings model. Expected: a transfer line item that is either clearly smaller than the compute delta or kills the recommendation.

4. If the transfer cost wins, flip the recommendation: keep the lake where it is and move the compute to the data instead, or drop the idea entirely. Expected: a written decision with both line items visible, signed off by a human.

5. Patch the agent's savings template so a region recommendation cannot be emitted with a zero or missing transfer line when replication rules exist on the involved buckets. Expected: the next recommendation either includes the math or refuses to recommend.

Use this when

• An agent recommends moving storage, a data lake, or a database to a cheaper region
• The savings model shows compute or storage rates only, with no data-transfer line
• S3 cross-region replication, database read replicas, or backup copies cross region boundaries
• Someone asks why the bill went up after a move that was supposed to save money

Not for this skill when

• The move involves compute only with no data gravity, such as stateless workers pulling from a queue
• Traffic stays inside one region, where transfer between AZs or to same-region services has different pricing
• You are pricing CloudFront egress or Direct Connect, which follow different rate cards

Variant phrasings

• cross region data transfer costs more than the savings
• S3 replication charges wiped out the rightsizing savings
• data transfer fees bigger than compute savings
• region move increased the bill

Why it happens

Agents model the prices they can see. Instance hourly rates are one API call away, while transfer pricing hides inside usage-type line items in the CUR that the agent never queried. Transfer feels free because moving data inside one region mostly is, so the model silently extends that assumption across region boundaries where it is wrong by dollars per gigabyte.

Edge cases

• Transfer into a region is often free while transfer out is charged, so the direction of replication decides who pays
• One source replicating to two destination regions pays the transfer charge twice
• S3 Transfer Acceleration, CloudFront origin fetches, and inter-region VPC peering each have their own rates that a single transfer line will miss
• Rates differ by source region, so a model built on us-east-1 numbers is wrong for eu-west-1

Provenance

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

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

Thread query: agent recommended moving the data lake to a cheaper region - its savings math ignored the cross-region transfer fees, which were bigger

TL;DR:

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.