Cost Explorer is the free, built-in lens on your AWS bill — and most teams use maybe 10% of it. This guide covers the views that actually find waste (group-by service/account/tag/usage-type, daily vs monthly, amortized vs unblended), the RI/Savings Plans recommendation and coverage/utilization reports, forecasting, the API + CUR for the analysis Cost Explorer can't do — and where a partner reads the data and does the rework, often AWS-funded.
Cost Explorer is the visualization and reporting layer on top of AWS's billing data. It is the first place to look when the bill moves, and the wrong place to look when you need line-item, resource-level forensics — that is what the Cost and Usage Report is for.
Mechanically, Cost Explorer reads from the same billing pipeline that produces your invoice and the Cost and Usage Report (CUR), and pre-aggregates it into a fast, filterable, charted UI in the Billing console. The UI is free. You can slice roughly the last 14 months of history (treat ~14 months as the working figure; check your console for the exact range), forecast up to 12 months forward, and save reports you reopen later.
Two things trip people up: granularity and cost type. Granularity defaults to Monthly, which hides the day a spike started — switch it to Daily for almost every investigation (Hourly + resource-level is opt-in and metered, worth enabling only when you genuinely need that detail). Cost type (amortized vs unblended vs blended, section IV) changes what the same chart means — get it wrong and your Savings Plan looks like a giant one-day charge instead of a smoothed monthly benefit.
What Cost Explorer is not: it is not a per-resource bill (it tells you EC2-Other jumped $4,000, not which volume or NAT Gateway — for that you use paid resource granularity or the CUR in Athena), and it is not an action tool. No button buys a Savings Plan, terminates an idle instance, or migrates gp2 to gp3; it surfaces the recommendation and you execute elsewhere. That gap between "the chart shows $30K/month of removable spend" and "the spend is actually gone" is the entire job — and where most savings die in a backlog.
Cost Explorer = "why did the number move, and where is the money?" Budgets = "tell me before it moves again." CUR = "exactly which resource, to the cent." Third-party BI = "all of that across accounts, plus chargeback and exec dashboards." You usually run all four; Cost Explorer is where you start.
Ninety percent of the value in Cost Explorer comes from four group-by dimensions and one granularity toggle. Learn these five controls and you can answer almost any "why is the bill X" question in under five minutes.
Every report is the same primitive — a time axis, a cost metric, a granularity, a group-by dimension, and filters; change the group-by and you change the question. Here is the order an experienced practitioner runs them in.
Start here every time. Group by Service, granularity Monthly, last 6 months. Within thirty seconds you see the shape: which 4–5 services are 80% of the spend (almost always EC2, RDS, S3, data transfer / "EC2-Other", and one surprise), and which are trending up — your map before you zoom into any one territory.
The classic gotcha: "EC2-Other" is not EC2 compute — it is the catch-all for EBS volumes, snapshots, NAT Gateway data processing, and inter-AZ / inter-region data transfer attributed to EC2. When it is large and growing, re-group by Usage Type to split it apart.
If you run AWS Organizations (and you should), group by Linked Account from the management account to see spend per account — useful when your strategy is one-account-per-team or per-environment. Pair it with a filter: narrow to a single linked account, then re-group by Service inside it to see, say, the staging account's breakdown in isolation — where oversized non-prod resources love to hide because nobody watches staging's invoice.
The most underused and most powerful dimension. Usage Type is the granular SKU: BoxUsage:m5.xlarge, EBS:VolumeUsage.gp3, NatGateway-Bytes, DataTransfer-Out-Bytes, USE1-USE2-AWS-Out-Bytes (cross-region), and so on. Group by it and you stop guessing — you see that the data-transfer line is specifically cross-AZ chatter, or that EBS spend is mostly old gp2 volumes you can convert to gp3 for ~20% less. Use the "Usage Type Group" pre-rollup (e.g. "EC2: Data Transfer - Inter-AZ") when the raw list is too noisy — the fastest way to confirm whether a NAT Gateway or cross-AZ traffic is silently eating your bill (see the NAT Gateway cost sibling).
Group by a Cost Allocation Tag — Team, Environment, Service, CostCenter — and the bill finally maps to your org chart instead of AWS's service taxonomy. This is the dimension finance actually wants: "what did the Payments team spend," not "what did DynamoDB cost." The hard prerequisite: the tag must be activated in the Billing console, and activation is not retroactive (it applies from activation forward, on resources that carry it). Untagged spend lands in a "(not tagged)" bucket — and if that bucket is large, your tagging hygiene is the real problem. Fixing it (activation + a tag policy + backfill, often enforced with an SCP) is the groundwork the Cost Allocation Tags sibling covers.
Monthly granularity tells you the bill went up $9K. Daily granularity tells you it started on the 14th — which lines up with a deploy, a config change, or a forgotten test cluster. For any "why did this month jump" question, switch to Daily first; the start date is usually the whole answer. Reserve Hourly (opt-in, paid) for autoscaling and scheduling questions where the time-of-day pattern is the point.
Once you know the controls, waste-hunting in Cost Explorer is a repeatable 20-minute loop. The goal is to separate three different problems — something changed (movers), something is broken (anomalies), and something is simply unused (idle) — because each has a different fix.
Run these three passes in order. Most teams surface 20–40% of removable or commit-able spend the first time through; the partner-led audits CloudRoute routes typically land in that band before any deep architectural work.
The honest caveat on all four: finding is the easy part. Terminating a "zombie" that is actually a quarterly batch job, or right-sizing a database that needs headroom for month-end, is how you cause an outage instead of a saving. This is why CloudRoute routes the read-and-rework to a partner who validates each candidate against utilization history before touching anything.
The same Cost Explorer chart shows wildly different stories depending on the cost type you select. Pick the wrong one and you will misread your Savings Plan as a one-time charge, or under-count what a workload truly costs. This is the single most common Cost Explorer misread.
Cost Explorer lets you switch the cost metric. The three that matter:
The practical rule: use amortized to understand and allocate cost, and unblended to tie a number back to the literal invoice. Showing leadership an unblended chart right after buying a Savings Plan — and watching them panic at a "huge unexpected charge" that is actually a year of savings paid upfront — is a rite of passage worth skipping.
Commitments are the single biggest lever on most AWS bills — up to ~70%+ off on-demand. Cost Explorer has three dedicated report families for them: purchase recommendations, coverage, and utilization. Used together they tell you what to buy, how much of your usage is protected, and whether you are wasting the commitments you already own.
First, the 2026 lay of the land. Savings Plans have largely replaced Reserved Instances for compute: Compute Savings Plans are flexible (across EC2, Fargate, and Lambda regardless of family/size/region, slightly smaller discount); EC2 Instance Savings Plans lock to a family in a region for a deeper discount. Reserved Instances still matter for RDS, ElastiCache, Redshift, and OpenSearch. All come in 1- and 3-year terms with No / Partial / All Upfront options — longer term and more upfront means a bigger discount for less flexibility.
The Savings Plans and RI recommendation reports analyze your recent usage (a 7-, 30-, or 60-day lookback) and propose a specific commitment — an hourly Savings Plans commitment in $/hour, or a count of RIs — with estimated monthly savings and a payback period, modeling different term/upfront combinations so you see the flexibility-vs-discount trade in dollars.
The judgment the tool cannot make: how stable is the usage it extrapolates from? A 60-day lookback that includes a one-off load test over-recommends; a team mid-migration to Graviton should commit cautiously. This is where "buy what it says" goes wrong — the Savings Plans and Reserved Instances siblings go deep on sizing the commitment to your real baseline.
The coverage report answers "what percentage of my eligible on-demand usage is covered by a commitment?" Low coverage (say 40%) means most of your steady-state compute is paying full on-demand price — money on the table. Near-100% coverage on fluctuating usage risks over-commitment. A healthy target is covering your stable baseline (often 70–85% of eligible compute) with Savings Plans and letting genuinely variable load run on-demand or Spot.
Utilization is the other side of coverage: of the commitments you already own, how much are you actually using? A Savings Plan or RI at 80% utilization means 20% of what you pre-paid for is wasted because the matching usage disappeared — a downsized fleet, a migrated workload, a decommissioned service. Below ~95% is a live leak. The fix is adjusting future commitments (RIs can sometimes be sold on the Reserved Instance Marketplace; Savings Plans cannot, so they must be grown into).
Commitments trade flexibility for discount. A 3-year All-Upfront Savings Plan is the cheapest per-hour rate and the least reversible decision you will make on AWS — if your architecture shifts (Graviton, Spot, a re-platform, a big customer churns), you are still paying. The right move is usually a layered commitment: cover the boring, stable baseline deeply, leave headroom for change, and revisit quarterly. Buying one giant 3-year plan off a noisy 60-day recommendation is the most expensive "optimization" mistake we see.
Cost Explorer does three more things worth knowing: it forecasts forward, it exposes everything via an API you can wire into your own tooling, and it hands off to the Cost and Usage Report when you need detail it structurally cannot provide.
Forecasting: Cost Explorer projects up to 12 months forward from your historical pattern, with a confidence band (an 80% prediction interval by default) — the same engine AWS Budgets uses for "forecasted to exceed" alerts. Useful for "are we on track to blow the quarter," with the caveat that it extrapolates the past and cannot know about the launch or migration you have planned. Group-by works here too, so you can forecast a single team's trajectory, not just the org total.
The Cost Explorer API (GetCostAndUsage, GetSavingsPlansCoverage, GetRightsizingRecommendation, and friends) exposes every view programmatically — how you push spend numbers into Slack, a dashboard, or a weekly report without opening the console. Each paid request runs about $0.01, so batch it for scheduled reporting.
When Cost Explorer is not enough, the Cost and Usage Report (CUR) is the escape hatch — the most granular billing data AWS produces (hourly or daily, line-item, resource-level, every dimension and tag), delivered to S3 and queried with Athena or loaded into a BI tool. CUR is what you reach for when you need "exactly which EBS volume, which hour, attributed to which cost center." The trade is setup and SQL effort: CUR is a data source, not a UI.
A partner-led audit uses all three together — Cost Explorer to find the territory, CUR to nail the exact resources, the API/CUR to prove the savings after the rework.
Cost Explorer is excellent at what it does and quietly silent about what it does not. Knowing the edges keeps you from concluding "the data is wrong" when it is actually the tool working as designed.
The hardest part of AWS cost optimization is not finding the waste — Cost Explorer does that in an afternoon. It is doing the rework safely while shipping product, and then proving it stuck. That is the work CloudRoute routes to a vetted partner, and for qualifying engagements AWS funds it.
The honest economics: AWS funds partner-led cost-optimization and Well-Architected engagements through its partner programs — the partner is paid through AWS, and a Well-Architected Review can unlock remediation credits that cover the rework. For a qualifying, credit-eligible engagement, you cut your bill for $0: the partner does the reading, the rework, and proves the new run-rate, and you do not see an invoice. Where an engagement does not qualify, it is a vetted-partner referral that pays for itself out of the savings rather than out of pocket.
Concretely, a partner-led pass off your Cost Explorer data typically: confirms the top movers and idle/zombie resources, right-sizes the oversized fleet (against real utilization, not a guess), layers the correct Savings Plans against your stable baseline, converts gp2→gp3 and cleans up unattached volumes/old snapshots, attacks NAT Gateway and cross-AZ data transfer, and stands up the governance — activated Cost Allocation Tags, Budgets with forecast alerts, and Cost Anomaly Detection — so the savings do not erode back.
Grant read-only Cost Explorer + CUR access (or share exports), spend ~30 minutes on a scoping call, and approve the change plan — the partner does the analysis and the rework. For qualifying engagements the cost to you is $0: AWS funds it and CloudRoute is paid by the partner, not by you.
These are not competitors so much as layers: Cost Explorer is where you start, CUR is the raw truth underneath it, and third-party BI sits on top of CUR for scale, multi-account rollups, and the dashboards finance actually opens. Most serious setups use all three.
| Dimension | Cost Explorer | Cost & Usage Report (CUR) | Third-party BI (e.g. on CUR) |
|---|---|---|---|
| What it is | Built-in charted UI on billing data | Raw line-item billing export to S3 | Analytics/dashboard layer over CUR |
| Granularity | Service → Usage Type; resource/hourly opt-in (paid) | Resource-level, hourly, every tag | As granular as CUR, modeled into views |
| Setup effort | None — open the console | Moderate (S3 + Athena/Glue + SQL) | Connector + config; SaaS or self-host |
| Speed to an answer | Seconds, interactive | Minutes (write a query) | Seconds once dashboards are built |
| Recommendations (RI/SP, right-size) | Built-in reports | No — data only | Yes, usually richer + automated |
| Multi-account / chargeback | By linked account + tag | Full detail, but you build it | Strong — showback/chargeback out of the box |
| History | ~14 months rolling | However long you retain in S3 | However long the tool/CUR retains |
| Cost | Free UI; ~$0.01/API request | S3 + Athena query costs (cheap) | Subscription or % of spend |
| Best for | Fast diagnosis + native recommendations | Per-resource forensics + custom analysis | Org-wide visibility, chargeback, exec dashboards |
Situation: The bill had crept from ~$31K to ~$47K/month over two quarters with no matching jump in customers. The team read Cost Explorer the shallow way — Monthly, grouped by Service — so all they knew was "EC2 and EC2-Other are big and going up." No Savings Plans at all (everything on-demand), no activated cost-allocation tags, Cost Anomaly Detection off. The one engineer who understood the bill was 80% allocated to the product roadmap and had no time to chase it.
What CloudRoute did: Routed within 20 hours to a US-based AWS partner with a FinOps / Well-Architected track record. The partner re-read Cost Explorer properly — Daily granularity, grouped by Usage Type — and split "EC2-Other" apart in minutes: roughly half was cross-AZ data transfer from a chatty service mesh and an under-used NAT Gateway in a dev account, the rest old gp2 volumes and unattached EBS. Compute Optimizer flagged a ~40% oversized fleet; the coverage report showed 0% Savings Plans coverage on a very stable baseline. After validating each candidate against CUR + utilization history, they right-sized the fleet, added VPC endpoints and consolidated AZ traffic to kill the NAT/cross-AZ bleed, converted gp2→gp3 and deleted orphaned volumes/snapshots, and layered a 1-year Compute Savings Plan covering ~80% of the baseline — then activated cost-allocation tags (deny-on-untagged SCP), Budgets with forecast alerts, and Cost Anomaly Detection.
Outcome: Steady-state spend fell ~34% — from ~$47K to ~$31K/month — within seven weeks, validated in Cost Explorer on amortized cost so the new Savings Plan read as smooth monthly benefit, not a one-day spike. The next real anomaly (a runaway log pipeline into CloudWatch) was caught by a forecast alert on day 2 instead of on the invoice. Because the engagement qualified for AWS funding, the customer paid $0 for the audit and rework — CloudRoute's commission came from the partner.
bill creep reversed: ~$16K/mo · steady-state cut: ~34% · SP coverage: 0% → ~80% of baseline · governance live: <2 weeks · cost to customer: $0
CloudRoute routes you to a vetted AWS partner who reads your Cost Explorer + CUR and does the rework — right-sizing, Savings Plans, idle cleanup, data-transfer fixes, and the governance to keep it. For qualifying engagements AWS funds it, so you cut the bill for $0.