Most DR cost conversations are about the strategy: backup and restore, pilot light, warm standby, active-active. Everyone nods at the ladder. Cheaper rungs, slower recovery, done. Then someone adds "and we want guaranteed capacity in the DR region" and the ladder quietly collapses. Illustrative example (made-up rates, not any provider's price list, not a real client): ExampleCo protects 20 TB of data and 12 app nodes. Production compute is about $1,750/month at an assumed $0.20/hr per node. Monthly DR cost with rates I picked for illustration: - Backup and restore: ~$200 (cold copies plus some transfer) - Pilot light, no reserved capacity: ~$1,030 - Warm standby at 25% size, no reserved capacity: ~$1,470 - Active-active: ~$2,780 - Pilot light WITH 100% of prod compute reserved in the DR region: ~$2,780 Same bill as active-active, with the recovery time of pilot light. You are paying to hold seats you will probably never sit in. Capacity reservations bill whether or not you ever fail over. That is the point of them, and also the trap. Where the money actually goes: 1. Standing capacity (reservations or idle compute). Usually the biggest line. 2. A hot data replica: storage plus the always-on database replica. 3. Cross-region replication traffic. It scales with your daily change rate, not your data size, so measure the change rate. 4. Drills. Full-size compute for a few hours twice a year is cheap. Skipping them is not. What to do instead: - Tier workloads. Five services need a 15-minute RTO. Forty do not. Do not replicate everything at the top tier. - Replicate data, not compute. Compute can be rebuilt from IaC; data cannot. - Reserve only what the tier-1 failover needs, not 100% of prod. Size it from the tier list, not from fear. - Decide on purpose whether "capacity guaranteed" is worth the delta for each tier. Write the delta down. - Tag every DR resource so the standby bill shows up in showback as its own line. The model is attached: a small read-only Python script (stdlib only, rates in a config you edit). Run it with your own numbers. Review and test it before using the output in a business case. The figures above come from that script with placeholder rates, so verify against your provider's current pricing.

Your tagging is fine. Your showback is still going to start a fight. Showback rarely dies on tag coverage. It dies on the remainder: the shared Kubernetes cluster, NAT and egress, the support plan, observability, the platform team, commitment discounts, idle capacity. Somebody has to decide who pays for that, and the formula you pick decides the invoice more than the usage does. ILLUSTRATIVE example. ExampleCo, four teams (Checkout, Search, Data, Platform), one month, total bill 200,000. I ran it through a small Python script so every number below is computed, not vibes. Tag coverage: 92%. Looks great on a dashboard. Directly attributable to the team that consumes it: 60%. The gap is shared pools: the cluster, NAT, observability, support and tooling are all "tagged" to Platform or to nobody. Now allocate the 54,000 of general shared cost three ways. Same bill, three invoices: Checkout: even 58,000 / proportional 62,500 / driver-based 63,300 Data: even 74,000 / proportional 83,000 / driver-based 80,060 Search: even 41,500 / proportional 39,250 / driver-based 38,850 Platform: even 24,500 / proportional 13,250 / driver-based 15,790 Data's invoice moves by 9,000 depending only on a spreadsheet decision. Nobody changed a single resource. Now the part that kills trust. Checkout cuts its direct spend by 30%. The company saves 12,000.00. Under proportional allocation (the usual default), Checkout's invoice drops by 16,000.01, and Data (+2,500.00), Search (+1,250.01) and Platform (+250.00) all get a higher bill for doing nothing. Under driver-based allocation the others absorb +444.45 in total, only because support is still split by spend. Under even split, zero. Proportional is zero-sum and circular. Every saving one team makes is partly invoiced to its neighbours. Do that twice and nobody believes the numbers. Two more traps in the same example: Commitment discounts. The 18,000 commitment fee was bought from the Platform account. "Buyer pays" puts all 18,000 on Platform. Amortized by covered usage it is Checkout 4,500, Search 3,000, Data 10,500, and those teams can actually see their discount.

Your secrets manager doesn't bill you for the secret. It bills you for every time your code reads it. AWS Secrets Manager list price: $0.40 per secret per month, plus $0.05 per 10,000 API calls. Google Secret Manager: about $0.03 per 10,000 access operations after a small free tier. Azure Key Vault also bills per 10,000 operations (check the current number for your region, I didn't verify it). Prices are US list, checked 2026-10-13. The storage line is a rounding error. The read line is where it goes wrong. Illustrative example (invented service, not a real client): one API, one database password, 500 requests per second, and the code calls GetSecretValue on every request because "it's always fresh". 500 req/s x 2,592,000 seconds in a month = 1.296 billion reads. - AWS: 129,600 units of 10k x $0.05 = about $6,480/month for ONE secret - GCP: about $3,888/month - At 50 req/s: about $648 on AWS Now cache it in memory and refresh every 300 seconds, across 200 pods: 200 pods x 2,592,000 / 300 = 1.73 million reads = $8.64/month on AWS. With a one-hour TTL, $0.72. Same secret. Same security posture. Roughly 750x cheaper. And money is the mild failure mode. Secret stores have API rate limits. Per-request fetch means a traffic spike or a retry storm turns into throttled secret reads, and throttled secret reads mean your service can't authenticate to its own database. You built an outage generator out of your credential store. What to do: 1. Measure first. CloudTrail logs every GetSecretValue. Count calls per secret per principal per day (Athena SQL below). Most teams find 2-3 secrets generating most of the reads. 2. Cache in-process with a TTL plus jitter, so 200 pods don't refresh in the same second. 3. Refresh on auth failure, not just on TTL. Rotation is the reason people don't cache. If a call fails with a bad credential, force one refresh and retry once. That makes rotation safe. 4. Keep stale-on-error: if the secrets API is down or throttled, keep serving the last good value for a bounded time.

The EBS Archive tier is "75% cheaper". Per GB-month, that's true: $0.0125 versus $0.05 for a standard snapshot (US list prices, checked 2026-10-09, verify your region). Per snapshot, it can be the opposite. Standard snapshots are incremental. You pay only for the blocks that changed since the previous snapshot. When you archive one, AWS converts it into a full snapshot (that's in the EBS docs). So you stop paying for a small delta and start paying for the whole volume. Illustrative example, invented numbers: A 500 GiB volume, daily snapshots in one chain. The month-end snapshot holds 20 GiB of blocks that are unique to it. - Standard: 20 GiB x $0.05 = $1.00 per month - Archived: 500 GiB x $0.0125 = $6.25 per month Six times more expensive, after a change that was supposed to save 75%. And it gets worse: a restore costs $0.03 per GB once (500 GiB = $15), and deleting or permanently restoring before 90 days bills you the remaining days. The break-even is one line of arithmetic: 0.0125 / 0.05 = 25%. Archive only wins when the snapshot's own incremental data is more than a quarter of the volume, and you will keep it 90+ days. Where it genuinely wins: - The ONLY snapshot you're keeping of a retired volume (end of project, decommissioned server) - Snapshots of high-churn volumes where each snapshot really is 25%+ new data - Compliance copies you must keep for years and will almost never restore Where it loses: archiving month-ends out of a healthy daily chain. That is the most common "optimization" I'd expect to see, and AWS Backup's cold tier uses the same archive tier, so the same math applies to lifecycle rules. Honest caveat: the unique size of a snapshot in a chain is not shown anywhere in the console, and deleting a neighbour moves blocks onto the survivors. The EBS direct APIs (ListChangedBlocks) give you a good estimate. I wrote a read-only audit script (orphans plus the 25% check). Reply "audit" below and I'll share it. The boring money is usually elsewhere: snapshots of volumes that no longer exist, AMIs deregistered years ago with snapshots left behind, and "keep 365 dailies" because nobody revisited the policy.

Here's a BigQuery billing rule that surprises nearly everyone who reads it for the first time. When an editions reservation autoscales, Google bills the slots it scaled to, not the slots your query used. Three rules from Google's own autoscaling docs explain the gap: 1. Autoscaling rounds up to a multiple of 50. If a query needs 60 slots, you're billed for 100. 2. You pay for scaled slots even if the job that triggered the scale-up fails. 3. By default, every scale-up is held for at least 60 seconds, and a new peak restarts that window. Rule 3 does the damage. One big ETL job per hour barely notices it. A BI dashboard that fires a 3-second query every 20 seconds never lets the window close, so the reservation sits at 100 slots all business day. Illustrative math (invented org, US Enterprise pay-as-you-go $0.06/slot-hour, list price as of 3 Oct 2026, 220 business hours a month): - Slots the queries actually used: 60 slots x 3 s every 20 s = about 9 slots on average = about $119/month - What the default autoscaler bills: 100 slots held continuously = about $1,320/month - Same workload with fluid scaling on: 100 slots for ~3 s of every 20 = about $198/month That's an 11x gap between the work done and the bill, caused entirely by query shape. The fix list, cheapest first: - Measure before you touch anything. Compare autoscale slot-minutes from INFORMATION_SCHEMA.RESERVATIONS_TIMELINE with the slot time your jobs actually consumed from JOBS_TIMELINE. Google says outright that the JOBS view will not match your bill. Use the billing export as the source of truth. - Turn on BigQuery fluid scaling for the reservation. It's opt-in. It removes the one-minute minimum and keeps per-second billing. It doesn't fix the 50-slot rounding. - Put spiky BI traffic in a different reservation from steady ETL. Idle slots are only shared within the same edition and region, so plan the split on purpose. - Give steady load a baseline and buy commitments for it ($0.048 one year, $0.036 three years on Enterprise as of today). Let autoscale handle real bursts only.