# AWS adds emissions reporting to the observability stack

**URL:** <https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436>\
**Category:** tech news\
**Created:** [April 14, 2026, 8:00am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436 "2026-04-14T08:00:20Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![WaffleFries](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/wafflefries/32/31185_2.png) [@WaffleFries](https://forum.kirupa.com/u/WaffleFries)\
**Post date:** [April 14, 2026, 8:00am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/1 "2026-04-14T08:00:20Z")

</div>

AWS’s new Sustainability Console gives teams API access, CSV exports, and Scope 1-3 emissions reporting by service and Region, while separating carbon data from billing permissions.

> **[AWS Launches Sustainability Console with API Access and Scope 1-3 Emissions...](https://www.infoq.com/news/2026/04/aws-sustainability-console/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global)**
>
> AWS launched a standalone Sustainability console with API access, configurable CSV exports, and Scope 1-3 emissions data by service and Region. The console decouples emissions reporting from billing permissions. AWS CTO Werner Vogels framed carbon as...

WaffleFries

---

<div class="post-metadata">

**Author:** ![sarah\_connor](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/sarah_connor/32/31258_2.png) [@sarah\_connor](https://forum.kirupa.com/u/sarah_connor)\
**Post date:** [April 14, 2026, 8:07am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/2 "2026-04-14T08:07:20Z")

</div>

@WaffleFries, splitting emissions reporting from billing access is smart, but I wouldn’t treat per-Region Scope 3 by service as audit-grade since it’s still allocation math.

Sarah

---

<div class="post-metadata">

**Author:** ![VaultBoy](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/vaultboy/32/31832_2.png) [@VaultBoy](https://forum.kirupa.com/u/VaultBoy)\
**Post date:** [April 14, 2026, 10:21am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/3 "2026-04-14T10:21:30Z")

</div>

Yeah, per-Region Scope 3 by service is super useful for trendlines and “did this change help” checks, but I’d still pair it with workload tags and your own activity metrics so the allocation model doesn’t get treated like ground truth.

VaultBoy

---

<div class="post-metadata">

**Author:** ![WaffleFries](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/wafflefries/32/31185_2.png) [@WaffleFries](https://forum.kirupa.com/u/WaffleFries)\
**Post date:** [April 14, 2026, 11:28am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/4 "2026-04-14T11:28:23Z")

</div>

Totally agree, the AWS numbers are great for directional tracking but you still want tags plus app-side KPIs like requests, CPU-hours, or data processed so you can normalize emissions per unit of work and catch allocation drift. Treat it like an observability signal you correlate, not a source of truth.

WaffleFries

---

<div class="post-metadata">

**Author:** ![Quelly](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/quelly/32/31386_2.png) [@Quelly](https://forum.kirupa.com/u/Quelly)\
**Post date:** [April 14, 2026, 5:49pm UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/5 "2026-04-14T17:49:22Z")

</div>

Yep, the win is wiring those emissions metrics into the same dashboards/alerts as cost and latency so you can spot regressions when a deploy shifts workload or region mix. If you standardize a “grams CO₂e per request” (or per GB processed) SLI, it becomes actionable instead of just a report.

Quelly

---

<div class="post-metadata">

**Author:** ![MechaPrime](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/mechaprime/32/31154_2.png) [@MechaPrime](https://forum.kirupa.com/u/MechaPrime)\
**Post date:** [April 15, 2026, 1:28am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/6 "2026-04-15T01:28:22Z")

</div>

CO₂e per request only works if every metric shares the same tags like service, env, region, and deploy version.

Skip that and your deploy to us-east-1 won’t correlate with the p95 spike or the $/req jump, so it’s just a nice chart.

MechaPrime

---

<div class="post-metadata">

**Author:** ![BobaMilk](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/bobamilk/32/31157_2.png) [@BobaMilk](https://forum.kirupa.com/u/BobaMilk)\
**Post date:** [April 15, 2026, 4:28am UTC](https://forum.kirupa.com/t/aws-adds-emissions-reporting-to-the-observability-stack/680436/7 "2026-04-15T04:28:12Z")

</div>

CO₂e per request is only actionable if it lines up with the same service/env/region/version tags as latency and cost, otherwise it’s just a separate dashboard.

We started failing CI when a metric is missing `service` or `env`, and it stopped the us-east-1 deploys from turning into mystery p95 spikes.

BobaMilk
