AWS Cost Explorer is a genuinely useful tool. It'll show you a clean breakdown of spend by service, by region, by tag — color-coded graphs, trend lines, the works. You can slice it a dozen ways and feel like you have a handle on your infrastructure costs.
Then the bill comes in and you're still surprised.
This happens to almost every team I talk to that's been running on AWS for more than a year. The data is all there in Cost Explorer. The context isn't. And without context, you're optimizing the wrong things.
Here's what the tool doesn't surface — and what it costs you.
Egress Fees Are Buried Three Layers Deep
AWS charges you to get your data out. That's not a secret. But the way it shows up in Cost Explorer obscures how much of your bill it actually represents.
Egress costs roll up under "EC2-Other" in the default view. Not "Data Transfer." Not "Egress." EC2-Other — a catch-all category that also includes Elastic IPs, NAT Gateway processing, and a handful of other charges. To find your actual egress spend, you need to filter by Usage Type, know to look for DataTransfer-Out-Bytes, and do the math yourself across regions.
Most teams don't do this. They see EC2 as their biggest line item, assume it's compute, and go hunting for instance right-sizing opportunities. Sometimes that's the right call. Sometimes you're spending $8K/month on egress and you don't know it.
A realistic scenario: a SaaS company running a customer-facing application in us-west-2 with 50TB of outbound traffic per month. At AWS's standard egress rate of $0.09/GB, that's $4,608/month — just to send data to users. That number doesn't appear anywhere in Cost Explorer's default dashboard. You have to know to look.
This is by design. I'm not saying AWS is being malicious, but they're not exactly motivated to make that line item obvious.
Reserved Instance Coverage Looks Better Than It Is
Cost Explorer has a Reserved Instance utilization report. It'll tell you what percentage of your RIs are being used and estimate your savings versus on-demand. On the surface, this looks like exactly the kind of visibility you'd want.
The problem is what it doesn't measure: opportunity cost from over-provisioned reservations.
When you commit to a 1-year or 3-year RI, you're betting on a specific instance family and size staying relevant to your workload. Teams that bought m5.2xlarge reservations in 2021 and migrated half their fleet to Graviton in 2023 are still paying for those commitments. Cost Explorer shows the RI as "utilized" if anything is running on it — even if you're using a Convertible RI to apply it to an instance type that's 30% less efficient for your workload than what you'd actually choose today.
You end up in a situation where your RI utilization report says 94%, your savings plan is "on track," and you're still overpaying because the baseline you committed against was wrong to begin with. The tool tells you you're doing well. Your CFO wonders why the cloud bill keeps climbing.
The Tag Coverage Problem Nobody Talks About
Cost allocation tags are how you're supposed to track spend by team, product, or environment. AWS makes it easy to create tags. It does almost nothing to enforce them.
Here's what this looks like in practice: your platform team sets up a tagging policy in 2022. Engineers follow it for the resources they provision manually. Then someone spins up an RDS instance through a quick Terraform module that didn't have the tag block, a Lambda function gets created by a third-party integration, and an S3 bucket from a proof-of-concept never gets cleaned up or tagged. Six months later, 23% of your infrastructure spend is sitting in the "untagged" bucket in Cost Explorer.
You can see the untagged spend. You can't see what it is without going resource by resource through the console.
# This is how you actually find untagged resources at scale
aws resourcegroupstaggingapi get-resources \
--tag-filters Key=environment \
--resource-type-filters ec2:instance \
--query 'ResourceTagMappingList[?Tags[?Key==`environment`] == `[]`]'
That command will show you EC2 instances missing an environment tag. You'll need to run variations of it across every resource type you care about. There's no single Cost Explorer view that does this for you.
The result: you can't accurately charge back costs to teams, you can't identify waste by environment, and you can't make confident decisions about where to cut without accidentally killing something important.
Idle Resources Don't Show Up as "Idle"
Cost Explorer shows you what resources are running and what they cost. It doesn't tell you which ones are doing nothing useful.
An EC2 instance running at 2% CPU utilization 24/7 looks identical to one running at 85% in Cost Explorer's service breakdown. Both show up as compute spend. Neither is flagged as a problem. You'd need to cross-reference with CloudWatch metrics — manually, or through a separate tool — to identify the idle one.
AWS Trusted Advisor will flag some of this, but only if you're on Business or Enterprise support (starting at $100/month or 10% of your monthly bill, whichever is higher). Cost Explorer itself won't do it.
What this typically looks like in a real environment: development instances that engineers spun up for testing and never terminated, staging environments that run 24/7 but only get used during business hours, load balancers with no registered targets, RDS instances with zero connections in the past 30 days. I've seen teams with $3,000-5,000/month in completely idle resources that had been sitting there for over a year because nobody's job it was to find them.
The fix isn't a better dashboard. It's a process: scheduled audits, automated shutdown policies for dev environments, lifecycle policies on storage. But you can't build that process if you think Cost Explorer's graphs mean you have visibility.
What Transparent Pricing Actually Looks Like
I want to be direct about something: the complexity I'm describing isn't accidental. When pricing has enough layers — on-demand rates, spot pricing, savings plans, reserved instances, tiered egress, regional variations, support tiers — it becomes genuinely difficult to know what you're paying or why. That difficulty serves the vendor more than it serves you.
This is one of the reasons we built IDACORE the way we did. Flat monthly pricing. No egress fees on traffic within Idaho. No support tier that gates you from getting help. When a healthcare SaaS company running HIPAA-regulated workloads moved their primary application stack to us, their first question was "what are the gotchas?" The answer was that there weren't any — their $40K/month AWS bill came down to $26K, and the difference wasn't optimization tricks or reserved instance gymnastics. It was the base rate and the absence of egress charges on workloads where their user base is concentrated in the Treasure Valley anyway.
That's not a pitch against using AWS for everything. If you need 22 global regions and 200+ services, AWS is the right tool. But if your users are in Boise and your data needs to stay in Idaho — for compliance reasons, latency reasons, or both — you're paying for global infrastructure you're not using, and Cost Explorer is showing you a detailed breakdown of that overpayment without telling you it's happening.
Sub-5ms latency to the Boise metro versus 20-40ms from AWS's Oregon region matters for certain workloads. Data residency in Idaho matters for HIPAA-covered healthcare organizations and state agencies. Neither of those factors shows up in Cost Explorer. They're not billing line items. But they're real costs — either in performance you're not getting or compliance risk you're carrying.
Getting Honest About What You're Actually Spending
If you want a real picture of your AWS costs, Cost Explorer is the starting point, not the finish line. Here's what actually gives you the full picture:
Run a Cost and Usage Report (CUR) export to S3 and query it with Athena. The CUR has line-item detail that Cost Explorer's UI never surfaces — including the actual egress breakdown, all the resource IDs, and usage type codes that tell you exactly what you're being charged for.
-- Find your actual egress spend from CUR data
SELECT
line_item_usage_type,
SUM(line_item_unblended_cost) as total_cost,
SUM(line_item_usage_amount) as total_gb
FROM your_cur_table
WHERE line_item_usage_type LIKE '%DataTransfer-Out%'
AND line_item_usage_start_date >= DATE '2024-01-01'
GROUP BY line_item_usage_type
ORDER BY total_cost DESC;
Audit your tag coverage before you trust any cost allocation report. Use the Resource Groups Tagging API or a tool like Steampipe to find untagged resources across your account.
And honestly — if you're running workloads where your users are in the Pacific Northwest and your data has Idaho residency requirements, run the numbers on what you'd actually pay with a regional provider. Not because AWS is bad, but because you should know what you're getting for what you're paying.
Cost Explorer is a mirror. It shows you the shape of your spending. It doesn't tell you whether that shape makes sense for your business.
If any of this sounds familiar — the surprise bills, the untagged resources, the egress fees hiding in EC2-Other — we're happy to walk through your current AWS spend and show you exactly what a comparable workload would cost at IDACORE, with flat pricing and no egress surprises. Get a real cost comparison for your infrastructure.
