Your AWS bill is up sharply month over month and nobody knows why. Walk through how you would use AWS Cost Explorer — granularity, Group by and filters — to narrow the increase down to a specific cause.
answer
- narrow by when, then what, then why
- daily granularity before monthly totals
- group by service, then usage type
- billing data is roughly a day behind
- usage type names the actual billed thing
basics
~20 sSet AWS Cost Explorer to Daily granularity to find the day spend jumped, Group by Service to name the culprit, then filter to that service and regroup by Usage Type, Region or Linked Account until the charge line is identified.
solid answer
~50 sI work it as three narrowing passes. First **when**: switch granularity from Monthly to Daily so the increase shows up as a step or a ramp on a specific date — that alone often matches it to a deploy or a launch. Second **what**: keep the daily view and Group by Service, so I can see which service's line moved rather than reading a single total. Third **why**: filter down to that one service and re-group by Usage Type, which is the dimension that names the actual billed thing (`BoxUsage`, `DataTransfer-Out-Bytes`, `TimedStorage-ByteHrs`), then by Region, Instance Type or API Operation as needed. In an organization I also group by Linked Account early, to see whose account moved. Two caveats: Cost Explorer data refreshes at most about daily, so today is incomplete, and it aggregates line items — it will not name a resource id.
code
bash · 5 linesaws ce get-cost-and-usage \
--time-period Start=2026-07-01,End=2026-08-01 \
--granularity DAILY \
--metrics UnblendedCost \
--group-by Type=DIMENSION,Key=SERVICEgo deeper
Be ready to name the controls out loud: granularity, Group by, filter. Say you would switch to Daily, group by Service, then drill into Usage Type — that sequence alone is what the question is testing.
Explain what each dimension actually means — usage type versus API operation versus charge type — and why the data is roughly a day behind. Mention that hourly and resource-level detail are opt-in rather than assuming they are available.
Show diagnostic judgment: read the shape of the daily curve (step, ramp, sawtooth) as evidence about the cause, separate rate changes from quantity changes, and rule out credits and month length before escalating to a team.
Own the question of how a spend investigation should not depend on one person's console skill: what standing views, exports and per-account ownership exist so the first pass is already done when someone asks, and what that costs to maintain.
## What Cost Explorer actually shows AWS Cost Explorer is a reporting front end over your billing data — the same line items that make up the invoice, aggregated and charted. Two consequences follow immediately, and candidates who miss them chase ghosts. It is **not real time**. The billing pipeline refreshes the data at most about once a day, so the current day is always partial and even yesterday can still settle. If you look at a spike an hour after it happened, you will not see it. For minute-level signal you are in CloudWatch metrics territory, not billing. It is **aggregated**. Every point is a sum of billing line items grouped by whatever dimensions you chose. Cost Explorer answers "which kind of charge grew", not "which specific bucket or instance did it". As of 2026 it keeps roughly the last year of history for charting and can forecast forward, and it offers Monthly and Daily granularity by default; **Hourly granularity, and resource-level detail, are an opt-in setting that carries its own charge and a short retention window**. Do not assume they are on. ## The three narrowing passes **Pass 1 — when.** Switch granularity to Daily and widen the range to cover both months. The shape tells you the class of problem. A vertical step on one date usually means something was switched on: a new environment, a new service, a scale-out. A gradual ramp usually means accumulation — storage growing, log retention set to never expire, snapshots piling up. A sawtooth that only appears on weekdays points at scheduled or human-driven work. **Pass 2 — what.** Keep Daily and set **Group by: Service**. A single total is useless; the stacked-by-service chart shows exactly which band grew. In a multi-account organization, Group by **Linked Account** at the same time is often faster — the increase frequently belongs to one team's account, and that tells you who to talk to. (Attributing cost by team via tags and Cost Categories is a separate discipline, handled elsewhere.) **Pass 3 — why.** Now add a **filter** on the service you identified, and re-group. The dimension that usually cracks it is **Usage Type**, because usage types are the literal billed things and their names are self-describing: `USE1-BoxUsage:m5.xlarge` is on-demand compute hours in us-east-1, `TimedStorage-ByteHrs` is stored bytes over time, `DataTransfer-Out-Bytes` is egress, `Requests-Tier1` is request counts. Other dimensions worth knowing: **API Operation** (which call is being made — invaluable for S3 and other request-priced services), **Region**, **Instance Type**, **Availability Zone**, **Purchase Option** (On-Demand versus Spot versus reserved), and **Charge Type**, which separates plain usage from tax, credits, refunds and reservation fees. Filter and Group by are complementary: filter removes rows from consideration, Group by splits what remains into series. Filtering to one service and grouping by usage type is the workhorse combination. ## Reading the result honestly A few things routinely mislead: - **Month length.** February against March is a three-day handicap on anything hourly. Compare daily run rates, not month totals. - **Credits and refunds.** A credit expiring makes cost "rise" with no change in usage at all. Check the Charge Type dimension and the include/exclude settings for credits, refunds, taxes and support before declaring an incident. - **Which cost metric is selected.** The default is unblended cost; a month containing an upfront commitment payment will look alarming under that metric and calm under amortized. - **Rate versus quantity.** Cost is rate times usage. Cost Explorer can chart **Usage quantity** as well as cost — if quantity is flat and cost moved, the cause is a pricing or discount change, not your workload. ## Where the drill-down stops When the usage type is identified but you still need the individual resource — which of four hundred buckets, which volume — Cost Explorer has run out of resolution unless resource-level granularity is enabled. Per-resource attribution at that point comes from the detailed billing exports queried directly, which is a different tool and a different leaf. One last practical note: the Cost Explorer **API** is billed per request, so a script polling `GetCostAndUsage` on a tight loop is itself a cost line. Cache, and query with the granularity you actually need.
- You have found the day the cost stepped up, but the daily chart still shows no obvious service. What next?Two moves. Group by Charge Type to check whether the step is usage at all — an expiring credit or a tax change moves cost with flat usage. If it is genuinely usage, chart Usage quantity beside cost: a flat quantity with rising cost points at a rate or discount change, such as a commitment expiring, rather than at anything your workload did.
- Why would you group by API Operation rather than Usage Type?For request-priced services, the usage type may only say `Requests-Tier1` while the API Operation dimension names the specific call — `GetObject`, `PutObject`, `ListBucket`. That is what turns "request charges grew" into "something is listing this bucket in a loop", which is an actionable finding.
- Cost Explorer shows almost nothing for today. Is something broken?No — that is expected. Billing data refreshes at most about once a day, so the current day is partial and recent hours are missing entirely. Never diagnose a live incident from Cost Explorer; use it the next day, and use CloudWatch metrics for anything that needs to be seen within minutes.
saying these in an interview costs you the question
- Expecting Cost Explorer to update in real time
- Comparing month totals without adjusting for month length
- Reading one total instead of grouping by service
- Assuming Cost Explorer names the individual resource
- Ignoring credits and refunds as a cause of an apparent rise