When your FinOps team makes your carbon problem worse

FinOps and sustainability optimise for different variables. Most of the time they align — idle compute is both expensive and carbon-heavy, and fixing it reduces both the cloud bill and the emissions figure. But there are a surprising number of common FinOps decisions that decrease cost while increasing carbon, and for companies filing under CSRD or SB 253, those decisions show up as unexplained year-over-year spikes in a compliance document.

The grid intensity problem

Cloud regions are priced on infrastructure cost, not grid carbon intensity. The two do not correlate well.

Region              Provider    $/hr (m5.xlarge)   Grid intensity
────────────────────────────────────────────────────────────────────
eu-north-1          AWS         $0.192             7 gCO₂/kWh
us-west-2           AWS         $0.192             130 gCO₂/kWh
us-east-1           AWS         $0.192             380 gCO₂/kWh
us-east-2           AWS         $0.188             440 gCO₂/kWh   ← cheaper AND dirtier
ap-south-1          AWS         $0.172             713 gCO₂/kWh   ← cheapest APAC, dirtiest

eu-central-1        Azure       $0.203 (D4s_v5)    474 gCO₂/kWh
polandcentral       Azure       $0.173             640 gCO₂/kWh   ← cheapest EU, very dirty
swedencentral       Azure       $0.212             8 gCO₂/kWh     ← cleanest EU, costs more
────────────────────────────────────────────────────────────────────
Data: AWS/Azure list pricing, IEA 2024 annual averages

A FinOps migration from us-east-1 to us-east-2 saves 2% on compute cost and increases Scope 3 Category 1 carbon by 16%. A migration from eu-central-1 to polandcentral saves 15% and increases carbon 35%. Neither of these is a bad FinOps decision in isolation — but neither is a good sustainability decision, and both will show up as YoY increases in a CSRD filing without context.

The reserved instance trap

Reserved instances and savings plans are a core FinOps tool. Commit to 1 or 3 years of capacity in exchange for 30–60% cost reduction. From a cost perspective this is almost always the right call for baseline compute.

From a carbon perspective the story is more complicated. Reserved capacity that sits idle — because the reservation was sized for peak demand but actual demand is variable — produces carbon that is attributed to no useful work. The reservation locks in the energy consumption; what varies is whether you get anything out of it.

RESERVED INSTANCE SCENARIO:
  Reserved: m5.8xlarge, 1 year, us-east-1
  Average utilisation: 40%
  Annual cost:    $18,200 (reserved) vs $45,500 (on-demand) → $27,300 saved
  Annual carbon:  ~12 tCO₂e emitted regardless of utilisation

  If utilisation drops to 20%:
  FinOps view: still saving vs on-demand, sunk cost
  Carbon view: 60% of emitted carbon produced zero output
               Effective emission intensity: 2.5× what a right-sized instance would emit

  CSRD view:   Scope 3 Cat 1 emissions are correct (carbon was emitted)
               But if the filing shows 12 tCO₂e for 20% utilised capacity,
               the auditor will ask about the efficiency explanation

When a cost optimisation causes a compliance problem

The pattern looks like this. In Q3 2025, the FinOps team migrates three services to cheaper regions — ap-south-1 for APAC, polandcentral for EU, and us-east-2 for US-East. Cloud spend drops 18%. Win. In January 2026, the sustainability team files its CSRD report and Scope 3 Category 1 has increased 42% year-over-year. Nobody can explain why.

Q3 2025 FINOPS MIGRATION — CARBON IMPACT
────────────────────────────────────────────────────────────────
Service     Old region      New region        Cost    Carbon
────────────────────────────────────────────────────────────────
API tier    us-east-1       us-east-2         -2%     +16%
EU service  eu-central-1    polandcentral     -15%    +35%
APAC batch  ap-northeast-1  ap-south-1        -22%    +81%
────────────────────────────────────────────────────────────────
Blended     (across services)                 -18%    +42%
────────────────────────────────────────────────────────────────
Filing impact: unexplained 42% YoY increase in Scope 3 Cat 1
Auditor question: what changed in 2025?
Answer: a cost optimisation your FinOps team made in Q3

The problem is not that the FinOps decision was wrong — it may have been entirely correct given the business priorities at the time. The problem is that nobody was looking at cost and carbon together before the decision was made.

The solution: shared data, not separate teams

Cost data and carbon data come from the same source. Every billing row has a region, a service, and a usage quantity. Carbon is derived from that data with two additional lookups: instance TDP (hardware spec) and grid intensity (IEA regional average). FinOps teams should not need to ask the sustainability team for carbon impact — it should be visible on the same cost dashboard.

EMITCI APPROACH:
  One database row per billing record
  Columns: cost · energy · co2 · region · service · tags · data_source

  FinOps query:  SELECT service, SUM(cost) GROUP BY region
  Carbon query:  SELECT service, SUM(co2_grams) GROUP BY region

  Same data. Same segmentation. No integration required.

When EmitCI's cloud sync runs, it produces both the cost breakdown and the carbon breakdown from the same billing pull. The tag attribution is identical — if FinOps filters by Team=Platform, the carbon filter by Team=Platform shows the same scope. The recommendations EmitCI surfaces (right-size runner, migrate to cleaner region, add path filters) show both dollar savings and carbon savings side by side, so an engineer evaluating the recommendation sees both axes before acting.

What this means for CSRD and SB 253 filers

For companies that are in scope for CSRD or SB 253, the FinOps and sustainability reporting processes need to be connected before decisions are made, not after filings are submitted. Concretely:

Cost optimisation decisions that involve region changes should include a carbon impact assessment before sign-off. Reserved instance sizing decisions should include utilisation projections and the resulting effective carbon intensity. Any cross-region migration should be flagged to whoever owns the GHG inventory so the YoY change can be explained in the filing.

None of this requires slowing down FinOps work. It requires FinOps and sustainability to look at the same data source. That is what EmitCI's unified billing-and-carbon store is built for.