Carbon emissions
Carbon emissions are computed from the cost sources you’ve already connected. There’s no separate carbon catalogue, and Plutus reuses your existing AWS, GCP, or Azure cost connection. Each provider still has to publish its emissions data, so you may need to enable an export or grant a role on the provider side. See Collectors for what each one needs.
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 substitutes one for the other in stored data. 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. The Carbon view and the dashboard card open on Market-based.
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 | What has to be set up |
|---|---|---|---|
| AWS | Carbon data export via S3 (manifest-first, same machinery as Cost and Usage Reports) | Location-based, market-based | The carbon export bucket must be set on the connection. Without it, AWS carbon is skipped. |
| GCP | Carbon Footprint BigQuery export | Location-based, market-based | A Carbon Footprint export to BigQuery. The dataset defaults to your billing dataset. |
| Azure | Carbon Optimization API | Market-based only | The connection needs the Carbon Optimization reader role. |
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.
Each sync fetches only the trailing 15 months, and the retention purge deletes any month
older than your tier’s window. A re-sync therefore can’t restore months that were purged,
and it never reaches further back than 15 months.