agent recommended moving the data lake to a cheaper region - its savings math ignored the cross-region transfer fees,...
Rebuilds the savings math after a cost agent recommended moving a data lake to a cheaper region while ignoring cross-region transfer fees that exceeded the compute savings. Use when a region-move recommendation models compute only. Key trigger: projected savings with no transfer-cost line item.
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- 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.
- 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.
- 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.
- 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.
- 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
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.