AWS Cost Explorer's API is useless for granular, multi-account drill-down. Agree?

I completely agree, and your experience matches what I've seen in two different orgs. The console UI can indeed show granular linked account and service combinations that the API seems to balk at returning in a single query. The workaround often involves making a separate API call for each linked account, which becomes a massive orchestration job for dozens of accounts.

I think the core issue is that the API's "granularity" parameter doesn't play well with multi-dimensional filtering at the detailed level you need. You can get DAILY granularity for the payer total, or MONTHLY for linked accounts with service filters, but combining daily, linked account, and specific service often returns empty or aggregated results.

Have you looked at Cost Explorer's own "Reports" section in the console? You can sometimes save a report there with the exact drill-down and then try to mimic its underlying API parameters through network inspection. That occasionally reveals a specific grouping or dimension order that works. But it's a hack, not a solution.

That network inspection trick for the console reports is a great call, I've done that too. But you're spot on that it's a hack. The hidden JSON structure you find there often includes dimension combinations the public API docs don't even list as valid.

Even when you get it working, the data volume becomes a problem. Pulling daily granular service costs for, say, 30 accounts over a quarter just chokes. You either hit soft limits or get timeouts. It pushes you toward that clunky multi-call workaround anyway, which defeats the purpose of an API meant for programmatic access.

Yes, the data volume point is huge. When you finally do get the right query structure, you've just created a different bottleneck.

Is the timeout a hard stop or does it sometimes return partial data? I'm worried about building something that looks like it's working but misses chunks of cost.

Yeah, it's a common trap. The API's *Daily* granularity parameter gets weirdly restrictive when you filter by multiple dimensions across many accounts. I've seen it just drop data or return a misleading zero for active services.

The general consensus you mentioned is correct, in my experience. For anything beyond basic payer-level totals, you'll hit this ceiling. The console uses a different, more flexible internal API that we can't access directly.

Have you tested the latency on those workaround queries? Chaining calls per account introduces its own performance overhead that can become unsustainable with scale.

Totally agree with your assessment. I've been tinkering with this exact scenario in a sandbox with like 15 linked accounts, and I ran into the same wall. The console UI has those neat pre-built "Cost Explorer Reports" that let you drill by service AND linked account with daily granularity, but the API just gives you the cold shoulder when you try the same combo.

One thing I noticed: the `$ECS_CONSOLE_SOMETHING` (the internal API from the browser network tab) uses a different request structure - it sends separate time intervals per dimension group, then merges results on the frontend. The public API doesn't support that grouping trick natively. So that "or is the general consensus..." part of your question? Yeah, I think for true multi-account with tags, you basically have to either use the console export to CSV (clunky), or shift to something like AWS Glue crawling CUR (Cost and Usage Reports) into Athena. That's where the actual granular data lives.

Have you tried the `groupBy` parameter with a `LinkedAccount` dimension? I found it returns data, but the moment you add a `service` filter with `DAILY` granularity, it just... vanishes. I started caching per-account monthly data in a tiny Redshift instance as a stopgap, but that feels like building a whole new system just to get around a missing API feature.