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.

On February 1, 2027, Azure reservations stop being exchangeable for anything savings plans cover: VMs, Dedicated Host, App Service, SQL Database and similar. That's four months away, and it's easy to read as a footnote. It isn't. What changes (Microsoft Learn, pages updated July and September 2026): 1. Reservations bought on or after Feb 1, 2027 for those services can't be exchanged. At all. 2. Reservations bought before that date keep exactly one final exchange. 3. Refunds don't change: cancelled commitment is capped at $50,000 per billing profile or enrollment in a rolling 12 months. Refunds that come out of an exchange don't count against the cap. Microsoft says a 12% early-termination fee might arrive in the future. 4. Trade-in to a savings plan is unchanged. But a savings plan can never be exchanged for anything afterwards. 5. Not affected: Azure VMware Solution and anything else savings plans don't cover. Instance size flexibility stays. The part that bites: today, exchanges are unlimited. After Feb 1 you get one per reservation. So every exchange you already know you'll need (the VM series you're moving off, the region you're consolidating out of, the App Service plan you're retiring) is free to do now and costs you your last move later. Second trap: the "safe" exit. When you trade reservations in for a savings plan, the portal proposes an hourly commitment derived from the money left in the reservations. Microsoft's own doc warns it might not be large enough to cover the same VMs. A savings plan usually gives a smaller discount than a reservation for the same SKU, and the remaining money is spread over a brand-new term. Illustrative numbers (invented, check your own SKUs in the pricing calculator): 20 VMs at $0.40/hr on-demand. Reservation rate $0.24/hr (40% off) = $4.80/hr. Savings plan rate $0.28/hr (30% off). Accept a $4.80/hr savings plan and it covers about 17 VMs; the other 3 run on-demand. You now pay about $5.94/hr. That's roughly $10k a year extra for flexibility you may never use.