Carbon emissions
Carbon emissions are computed from the cost sources you’ve already connected. There’s no separate carbon catalogue and no extra credentials to enter — if AWS, GCP, or Azure is already syncing cost data, Plutus reads that provider’s emissions export using the same connection.
Market-based vs. location-based
Section titled “Market-based vs. location-based”Cloud providers report emissions two ways. Location-based uses the average emissions intensity of the physical grid a region draws power from. Market-based accounts for any energy contracts and renewable-energy purchases the provider has made for that capacity, which usually produces a lower figure than location-based for the same usage.
The two numbers answer different questions and are never comparable to each other. Plutus never sums them, never averages them, and never defaults one in for the other. A row without an explicit methodology and unit is refused when it’s written, and every read takes exactly one basis — the Carbon view’s methodology toggle switches which one you’re looking at, it doesn’t blend them.
Example: your AWS emissions for March are 12.4 t CO2e location-based and 3.1 t CO2e market-based, reflecting renewable energy credits AWS purchased for the regions you use. Switching the toggle from Location-based to Market-based changes the number from 12.4 to 3.1 — it does not add or average them into some other figure.
Where you see it
Section titled “Where you see it”- Carbon view (
/carbon) — monthly emissions, the methodology toggle, a service/region breakdown, and the measured reporting lag per source. - Dashboard card — the trailing four published months, plus which methodology basis is shown and the current reporting lag.
Carbon is a separate page from Cost Explorer, not a mode of it. Cost Explorer’s controls are built around daily granularity; carbon data publishes monthly and arrives with a reporting lag measured in months, so plotting it on a daily chart would render mostly empty.
Reporting lag
Section titled “Reporting lag”Providers don’t publish emissions data for a month until well after that month ends — often a full quarter later. Plutus measures this lag per source from what’s actually been published so far, rather than assuming a fixed delay. If AWS’s most recent published month is January and today is April, the measured lag reflects that gap; it isn’t a hardcoded “3 months” constant that could drift from reality as a provider changes its own publishing cadence.
Collectors
Section titled “Collectors”| Source | Mechanism | Methodology bases |
|---|---|---|
| AWS | Carbon data export via S3 (manifest-first, same machinery as Cost and Usage Reports) | Location-based, market-based |
| GCP | Carbon Footprint BigQuery export | Location-based, market-based |
| Azure | Carbon Optimization API | Location-based, market-based |
Carbon data rides the same sync as cost data but fetches at most weekly, even if the cost sync itself runs more often. A monthly, quarter-delayed dataset doesn’t need to be re-requested every time the cost sync runs.
Retention
Section titled “Retention”Carbon data retention follows the same tier-based retention_days window as cost data.
Unlike cost data, this loss is recoverable: providers publish multi-year emissions history,
so re-syncing after a retention purge backfills what was deleted.