Introduction
Someone asked me last week whether Cost Explorer works like Resource Explorer, just for billing. It’s a reasonable guess. Same suffix, same console, both let you slice things by region. The guess is wrong in a way that costs people real time, so it’s worth pulling apart.
One is a search index. The other is a reporting engine. They share a word.
Resource Explorer is a search index
Not a query API. Not a live view of your account. An index, in the Elasticsearch sense: a denormalised copy of a subset of your resource metadata, kept somewhere else, updated asynchronously.
The architecture is worth understanding because every quirk of the service falls out of it.
Each region where the service is turned on gets a local index holding resources in that region. One region in the account can hold the aggregator index, which receives replicated copies from all the others. Cross-region search only works from the aggregator region. Search from anywhere else and you get that region’s resources and nothing more.
You get exactly one aggregator index per account. To move it, you demote the existing one to local, wait 24 hours, then promote the new one. This catches people mid-migration who assumed they could just flip it.
What actually gets indexed is thin: ARN, resource ID, region, resource type. Tags come along only if the view is configured to include them, which is a flag you pass at view creation:
| aws resource-explorer-2 create-view \ –view-name all-resources \ –included-properties Name=tags |
Forget that flag, and you’ll spend an afternoon wondering why tag:env=prod returns nothing.
Eventual consistency, and I do mean eventual
AWS documents this plainly and people still get bitten. A new resource reaches its local index in a few minutes. Replication onward to the aggregator index takes longer. Initial indexing and full replication across the service can take up to 36 hours.
So the failure mode is specific and nasty: you create something in ap-south-1, search from your aggregator in us-east-1, get nothing, and conclude the resource type isn’t supported. It might just not have arrived yet.
The practical rule: Resource Explorer is for finding things you built last week. It is not a verification tool for things you built five minutes ago, and it is definitely not something to put in a CI gate that checks whether a deploy created what it should have. Use the service’s own describe API for that.
To check the supported list use the following command:
| aws resource-explorer-2 list-supported-resource-types \ –output json –no-cli-pager \ | jq -r ‘.ResourceTypes[].ResourceType’ | sort |
Cost Explorer is not a resource tool at all
This is the part that trips people. Cost Explorer has a region dimension, so it looks like it knows about regions the way Resource Explorer does. It doesn’t. Region is a column you group by in a billing aggregate. The service has no concept of a resource existing; it only knows that some usage was attributed to some dimension.
Ask it “what did I spend on NAT Gateways in eu-west-1 last month” and it answers immediately. Ask it “which NAT Gateway cost me $340” and you’re mostly out of luck.
Mostly, not entirely, and the exception matters if you’re writing about this. Cost Explorer does have an opt-in for hourly and resource-level data. It looks back 14 days, and resource-level detail covers EC2 only. Billing is $0.00000033 per usage record per day, about $0.01 per 1,000 usage records a month. One instance running continuously generates 336 records (24 hours x 14 days) and costs around $0.003 a month.
So: an EC2 instance from last Tuesday, fine. A NAT Gateway, an EBS volume, an S3 bucket, or anything at all from six weeks ago, no. For those you need the Cost and Usage Report with Include resource IDs enabled, which lands in lineItem/ResourceId.
Two things about that checkbox nobody tells you until it’s too late. It is not retroactive — turning it on today does nothing for last month, and backfilling means a support request. And if the report was created with Overwrite versioning, you cannot edit the resource-IDs setting at all. You create a new report.
Picking the right tool –
| Resource Explorer | Cost Explorer | CUR with resource IDs | |
| Answers | does it exist | what did it cost | which one cost it |
| Granularity | resource | service, usage type, region | resource |
| History | current state only | 13 months daily | as long as you have kept it |
| Hourly | n/a | 14 days, opt-in | yes |
| Freshness | minutes to 36 hours | about 24 hours | up to 24 hours |
| Cost | free | free in console, $0.01 per API request | S3 storage plus Athena scans |
| Retroactive | index warms on its own | yes | no, only from the day you enable it |
Conclusion
Resource Explorer answers whether this exists and where. Cost Explorer answers what this category costs. Neither answers which specific thing is costing me money, which is the question you actually have at 2 am, and which only the Cost and Usage Report with resource IDs enabled can answer.
The trap is that both services are cheap or free to start and quietly bad at the job you’ll eventually hand them. Turn Resource Explorer on early so the index is warm. Turn CUR resource IDs on early so you have history when you need it. Neither can be retrofitted onto the past.