Scope 2 · Purchased Electricity · Digital & Data-Centre Emissions
Cloud Storage Carbon Footprint Calculator — Operational & Embodied Emissions by Media, Region & Redundancy
Estimate the operational (Scope 2) and embodied (Scope 3 Category 1) emissions of stored data, from logical capacity through the redundancy multiplier, storage-media energy intensity, data-centre PUE, and the location-based grid factor. Built for infrastructure operators reporting their own data-centre electricity and for teams sizing the storage line of a digital-services inventory.
Calculation chain (per storage line, then summed). The calculator resolves each storage line from logical capacity to emissions in four steps: physical capacity = logical TB × redundancy factor; device energy = physical TB × storage-media intensity (kWh per TB-year) × reporting years; facility energy = device energy × PUE; and operational emissions = facility energy × the location-based grid factor. Every line is computed separately and summed, because media type, redundancy, and region can differ line by line.
Logical vs physical capacity — the redundancy multiplier. The capacity you provision is logical; the capacity that actually spins (and draws power, and was manufactured) is physical. Cloud object stores replicate or erasure-code data for durability, so physical capacity is typically well above logical. The calculator applies a per-line redundancy factor — none (1×), erasure/RAID (1.4×), triple-replica (3×), or geo-redundant (2×) — and scales both operational energy and embodied carbon by the physical figure. This provisioned-versus-logical split is the single largest accuracy lever in storage accounting, and it is surfaced prominently in the result (a physical/logical capacity chip).
Storage-media energy intensity. Different media draw very different power per unit stored. The calculator carries intensity coefficients for hot SSD, nearline HDD, HDD-backed object storage, and cold/archive tape, expressed in kWh per TB-year, derived from the Cloud Carbon Footprint “Cloud Jewels” storage coefficients. SSD is the most power-hungry per terabyte; spinning HDD is roughly half; tape archive is an order of magnitude lower — though the tape figure is a conservative, low-confidence placeholder pending a dedicated tape-library life-cycle study, and should be treated as indicative rather than assurance-grade.
PUE — the data-centre wrapper. Power usage effectiveness converts the energy drawn by the storage hardware into the total facility energy, capturing cooling, power distribution, and overhead. The calculator offers hyperscale (1.1–1.2) and enterprise (1.5–1.7) presets from the data-centre PUE dataset, plus a custom entry, and defaults to a hyperscale-typical 1.2. Facility energy scales linearly with PUE, so the choice between a hyperscale and a legacy enterprise room can move the result by 40% or more.
Grid factor — region is the biggest lever. Operational emissions are facility energy times the location-based grid carbon intensity for the country the data centre sits in. The calculator reads the same grid factor path as the Scope 2 Electricity Calculator — the location-based national factor by country code (DEFRA for the UK, Ember Yearly Electricity elsewhere, EPA eGRID for the US) — so the numbers are consistent across the two tools. Because national grid intensities span more than a twentyfold range, the same data in a low-carbon grid versus a coal-heavy one produces wildly different footprints from identical hardware.
Operational and embodied are reported separately. The Scope 2 operational figure is the hero result. An optional embodied line (Scope 3 Category 1) estimates the amortised manufacturing carbon of the drives — physical TB × per-TB embodied factor ÷ useful life × years — and is reported alongside the operational total, never blended into it. The default embodied factors are enterprise-drive LCA figures; a conservative consumer-grade sensitivity (roughly fifteen times higher) is available as a second toggle for stress-testing.
Provider modes. A generic by-country mode is the default. A Google Cloud mode instead reads per-region carbon-free-energy data and shows a market-based guide alongside the location-based figure; an AWS mode carries a single illustrative region; Azure is qualitative-only, with no substituted factor. Where a provider does not publish a usable regional factor, the calculator never silently swaps in another provider’s number.
What this calculator does not do. It does not decide your organisational or operational boundary, apply a market-based contractual instrument (beyond the Google CFE guide), model network/egress emissions, or assert a Software Carbon Intensity score. It produces the storage line; the boundary decision, the market-based overlay, and any SCI rating are separate steps.
Location-based annual average for the hosting country’s grid.
1 year = annual footprint. Storage and embodied both scale with the period.
Blank = MasterBrain default (HDD 5 yr).
Blank = MasterBrain default (SSD 5 yr).
Redundancy (physical:logical capacity ratio) is set per storage line above — the single biggest accuracy lever. Cold/archive (tape) energy and embodied are conservative low-confidence estimates.
Add your stored data and pick a grid above to calculate
Results appear instantly. The scope split, per-class breakdown, tier-to-archive scenario, region ladder and full audit trail appear after calculation. Location-based Scope 2 by default; add embodied (Scope 3) with one toggle.
Results are indicative location-based Scope 2 (purchased-electricity) estimates for data at rest in the cloud, allocated with the Cloud Carbon Footprint “Cloud Jewels” per-terabyte storage coefficients (HDD 0.65 / SSD 1.2 Wh per TB-hour) applied to physical capacity (logical data × redundancy), multiplied by data-centre PUE and regional grid carbon intensity (AR6-100). The optional embodied line amortises drive-manufacturing carbon (enterprise LCAs — Seagate / Western Digital, or the conservative consumer-grade Tannu & Nair figures — via MasterBrain, AR5-100) over the drive life — reported as Scope 3, never blended into Scope 2. This is a transparent allocation estimate, not metered billing data; reconcile against your provider’s account-level carbon report. Cold/archive (tape) energy and embodied are conservative, low-confidence estimates. Microsoft Azure is not covered by the grid data layer. The 24/7 carbon-free-energy figure is a market-based guide, not a contractual instrument. Confirm capacities, redundancy and grid factors against your own records, and where material proceed to third-party verification under ISO 14064-3.
A terabyte in the cloud feels weightless — a line item on an invoice, a slider in a console. But every terabyte you keep is a slice of a spinning disk in a cooled room drawing grid power every hour of every day, multiplied by however many copies the provider keeps for durability, for as long as you retain it.
Stored data has no idle state: it emits continuously, and most of the footprint is decided before a single byte is written — by the media, the redundancy, and above all the grid.
Cloud storage emissions = logical TB × redundancy × media intensity (kWh/TB·yr) × PUE × grid factor. The grid region is the biggest lever: identical data can vary more than tenfold between a low-carbon and a coal-heavy grid.
What a cloud-storage footprint actually measures
A cloud-storage carbon footprint is the greenhouse-gas emission of keeping data on disk over a period of time: the electricity the storage hardware and its cooling draw (operational, Scope 2) and, optionally, the amortised manufacturing carbon of the drives themselves (embodied, Scope 3 Category 1). Unlike a one-off compute job, storage emits continuously for as long as the data is retained — the accounting unit is capacity multiplied by time, not a single transaction.
Two readers, two scopes — operator vs buyer
“Cloud storage carbon” hides two different questions, and which one you are asking decides how the footprint is scoped.
The infrastructure operator
You run the data centre — or you are accounting for a specific facility’s storage estate. The electricity the storage hardware draws is your Scope 2 (purchased electricity), and the drives you bought are your Scope 3 Category 2 capital goods or Category 1 purchased goods. This calculator’s operational output is a Scope 2 figure computed from your own energy chain — media intensity, PUE, and grid factor — and is the mode this tool is built around.
The SaaS / cloud buyer
You buy storage as a service and never see the hardware. The provider’s electricity is your Scope 3 Category 1 (purchased services). A physical energy-chain estimate like this one gives a defensible activity-based number where the provider publishes no allocated figure — but where you only hold spend, a spend-based estimate via the Scope 3 Category 1 Spend-Based Calculator is the honest fallback. Prefer a provider’s own allocated figure when one exists.
The same kilowatt-hour is Scope 2 for the operator and Scope 3 Category 1 for the buyer — it is never double-counted within one entity, but it appears in both inventories across the value chain. Decide which side of the boundary you are on before you read the result: the operator reports the electricity directly; the buyer reports it as a purchased service and should reach for the provider’s allocated number first, this activity-based estimate second, and a spend-based proxy last.
Scope boundary — what’s in, what’s elsewhere
| Covered in this calculator | Out of scope — separate tool or framework |
|---|---|
| Operational electricity of stored data (media intensity × PUE × grid), Scope 2 location-based | Compute, VM, and container runtime energy — see the Cloud Compute Calculator |
| Amortised embodied manufacturing carbon of storage drives (optional Scope 3 Cat 1 line) | Full IT-asset lifecycle and end-of-life / e-waste — see the IT Asset & E-Waste Lifecycle Calculator |
| The data-centre PUE wrapper applied to storage energy | Standalone facility PUE modelling — see the Data Centre PUE Calculator |
| Location-based grid emissions by country / region | Market-based contractual instruments (RECs, PPAs, residual mix) — beyond the Google CFE guide, handled in the Scope 2 Electricity Calculator |
| The storage line of a digital-services inventory | Data transfer / egress, CDN, and end-user network energy — see the Website Digital Carbon Calculator |
How the calculation works — the storage energy-to-emissions chain
Each storage line resolves through one chain, computed per line and summed at the estate level:
Physical TB = Logical TB × Redundancy factor
Device kWh = Physical TB × Media intensity (kWh/TB·yr) × Years
Facility kWh = Device kWh × PUE
Scope 2 (tCO₂e) = Facility kWh × Grid factor (kg CO₂e/kWh) ÷ 1000
Four multipliers stand between the capacity you provision and the emissions you report, and each is a decision the accountant makes explicit rather than a fixed constant:
- Redundancy factor — converts logical (provisioned) capacity to physical (spinning) capacity. The most under-counted term; see §3.
- Media intensity — the kWh drawn per terabyte-year, set by whether the data lives on SSD, HDD, or tape; see §4.
- Years — the reporting period. Storage emits continuously, so the footprint is capacity × time; a one-year default is typical.
- PUE — the facility overhead multiplier for cooling and power distribution; see §5.
- Grid factor — the location-based carbon intensity of the electricity, set by region; see §6, and the largest single lever.
Because the chain is a product of independent multipliers, the emissions respond proportionally to each. Halving redundancy, moving from enterprise to hyperscale PUE, or relocating to a grid a third as carbon-intensive each cut the result by the same proportion. That makes the storage footprint unusually tractable — there are only five numbers to move, and three of them (redundancy, PUE, region) are architectural choices rather than physical constants.
Logical vs physical — the redundancy multiplier
The most common error in storage accounting is to compute emissions from the capacity you provisioned rather than the capacity that physically exists. Cloud object stores keep multiple copies — or erasure-coded fragments — of every object for durability, so the physical footprint is materially larger than the logical one. Both operational energy and embodied carbon scale with the physical figure, so getting this multiplier right is the single biggest accuracy improvement available.
| Redundancy mode | Physical multiplier | Typical use |
|---|---|---|
| None (single copy) | 1× | Scratch, cache, reproducible data where loss is tolerable |
| Erasure coding / RAID | ≈1.4× | Durable object storage with parity overhead rather than full copies |
| Geo-redundant | 2× | Data mirrored across two regions for disaster recovery |
| Triple replica | 3× | Default durability model for many block and object stores |
Reporting on logical capacity alone understates a triple-replicated store by two-thirds. If you provision 500 TB on a 3× store, the emissions belong to 1,500 physical TB — the drives that spin, draw power, and were manufactured. The calculator surfaces this split as a physical/logical chip precisely because it is so easy to miss; confirm which figure your provider’s capacity report gives you before entering it.
Storage media and their energy intensity
Storage media differ sharply in power drawn per terabyte stored. SSD delivers low latency at a higher energy cost per terabyte; spinning HDD is roughly half the intensity; tape archive is an order of magnitude lower but comes with retrieval latency measured in minutes to hours. The calculator carries a per-terabyte-year intensity for each, derived from the Cloud Carbon Footprint “Cloud Jewels” storage coefficients.
Hot / SSD — 10.52 kWh/TB·yr
Solid-state, low-latency tier for active data. Highest energy intensity per terabyte of the mainstream media because of the power draw per unit of flash capacity. The right choice for data that must be read fast and often — and the wrong place to leave data that is rarely touched.
Nearline / HDD & object — 5.70 kWh/TB·yr
Spinning disk for nearline and HDD-backed object storage. Roughly half the intensity of SSD per terabyte, and the workhorse tier for the bulk of stored data. HDD-backed object storage carries the same intensity as nearline HDD in the model.
Cold / archive (tape) — ~0.5 kWh/TB·yr
Tape libraries for archival data draw almost no power at rest — an order of magnitude below spinning disk. Note this figure is a conservative, low-confidence placeholder pending a dedicated tape-library life-cycle study; treat archive-tier results as indicative rather than assurance-grade.
Media choice and retention policy are the same lever seen twice. Moving cold data off SSD onto HDD roughly halves its operational intensity; moving genuinely archival data onto tape cuts it by an order of magnitude again. The largest media saving on most estates is not a technology swap but a lifecycle policy — automatically demoting data down the tiers as it ages, so hot capacity holds only what is actually hot.
PUE — why the data-centre wrapper matters
Power usage effectiveness is the ratio of total facility energy to the energy drawn by the IT hardware itself. A PUE of 1.2 means that for every kilowatt-hour the drives consume, the facility draws 1.2 — the extra 0.2 going to cooling, power conversion, and overhead. The calculator multiplies device energy by PUE to get facility energy, so the result scales linearly with the number chosen.
| Facility class | PUE range (calculator preset) | Characterisation |
|---|---|---|
| Hyperscale | 1.1 – 1.2 | Purpose-built cloud data centres with advanced cooling; the default 1.2 is hyperscale-typical |
| Enterprise | 1.5 – 1.7 | Legacy corporate and colocation rooms with older cooling and higher overhead |
| Custom | User-entered | Where a facility publishes its own measured annualised PUE — use it in preference to a preset |
The gap between a hyperscale 1.1 and an enterprise 1.7 is roughly 55% additional facility energy for identical hardware — larger than most media choices and comparable to a mid-range grid difference. Where a provider or facility publishes a measured annualised PUE, enter it as a custom value; the presets are defaults for when it is unknown. For standalone facility modelling and the KPI definitions behind the ratio, see the Data Centre PUE Calculator and the paired data-centre PUE operational methodology.
Grid carbon intensity — region is the biggest lever
Facility energy becomes emissions when multiplied by the grid’s carbon intensity — and national grid intensities span a range no other term in the chain comes close to. The calculator reads the location-based factor by country code, the same path the Scope 2 Electricity Calculator uses, so a storage figure and an electricity figure for the same region are consistent.
DEFRA 2026 (GB) · Ember Yearly Electricity 2025 (other countries) · EPA eGRID 2023 (US). Location-based national averages, live MasterBrain values.
Norway to India is roughly a twentyfourfold span — the widest of any input. A storage estate is often more portable than a compute workload, because latency tolerance is higher for cold and nearline data. That makes region selection a genuine decarbonisation lever for archival and backup tiers, not just a reporting artefact: the same drives, the same redundancy, and the same PUE produce an order-of-magnitude different footprint depending only on where the data centre sits.
The grid factor is location-based — it reflects the physical grid the facility draws from. A market-based figure using contractual instruments (renewable energy certificates, power purchase agreements) can differ substantially and is reported separately under the GHG Protocol Scope 2 dual-reporting rule. The Google Cloud mode surfaces a carbon-free-energy market-based guide alongside the location-based number; for a full market-based treatment with a residual mix, use the Scope 2 Electricity Calculator. Never net a market-based claim into a location-based total.
Operational vs embodied storage carbon
The electricity a drive consumes is only part of its footprint. Manufacturing the drive carries embodied carbon — the mining, fabrication, and assembly emissions banked before it ever spins. The calculator reports this as an optional Scope 3 Category 1 line, amortised over the drive’s useful life and scaled to physical capacity, and it is never blended into the Scope 2 operational hero — the two are different scopes and different decisions.
| Dimension | Operational (Scope 2) | Embodied (Scope 3 Cat 1) |
|---|---|---|
| What it captures | Electricity drawn by drives and cooling over the period | Amortised manufacturing carbon of the drives |
| Formula term | Facility kWh × grid factor | Physical TB × per-TB embodied ÷ useful life × years |
| Default factor basis | Cloud Jewels intensity × live grid factor | Enterprise-drive LCA (HDD 1.2, SSD 2.5, tape 0.05 kg CO₂e/TB) |
| Useful life amortisation | n/a — continuous | HDD / SSD 5 years; tape 15 years |
| Sensitivity available | Grid region, PUE | Consumer-grade drive LCA (~15× higher: HDD 20, SSD 160 kg CO₂e/TB) |
Embodied factors vary by more than an order of magnitude between enterprise and consumer sources. The calculator defaults to enterprise-drive LCA figures because cloud estates run datacenter-grade hardware, but a conservative consumer-grade sensitivity (roughly fifteen times higher) is available for stress-testing. If you report an embodied line, state which basis you used and treat the consumer figure as an upper bound, not a central estimate. For full asset-lifecycle and end-of-life accounting, the operational-plus-embodied split here is a subset — the IT Asset & E-Waste Lifecycle Calculator covers the whole life.
Inputs this calculator needs — and where to source them
Storage accounting is a capacity-and-configuration exercise: the arithmetic is a product of five terms, and the difficulty is sourcing each honestly. The inputs below drive every result.
| Input | Unit | Primary source | Fallback source |
|---|---|---|---|
| Logical capacity | TB | Cloud provider capacity/billing report (logical stored bytes) | Storage console usage metrics |
| Redundancy mode | Multiplier | Storage-class configuration (replication / erasure-coding policy) | Provider default for the storage class (often 3×) |
| Storage media / tier | Class | Storage class (hot / nearline / cold / archive) from the provider | Infer from access-tier naming; default nearline HDD for bulk data |
| PUE | Ratio | Facility’s published annualised PUE (custom entry) | Hyperscale (1.1–1.2) or enterprise (1.5–1.7) preset |
| Region / country | Country code | Data-centre region from the provider console | Billing region; provider region-to-country mapping |
| Reporting period | Years | Inventory reporting year (default 1) | — |
The two inputs most often taken wrong are capacity basis and region. Confirm whether the provider’s capacity figure is logical or already physical before applying the redundancy multiplier — double-counting redundancy is as common as ignoring it. And map the cloud region to the correct country: a region name like “europe-west” resolves to a specific country grid, and getting it wrong can swing the result several-fold given the grid spread in §6.
Worked example — 100 TB across three grid regions
This example reproduces exactly against the live calculator. It holds everything constant except the grid region, to isolate the single largest lever. The configuration is 100 TB logical, nearline HDD, triple-replica (3×), PUE 1.2 (hyperscale-typical), one year. All grid and intensity numbers are live MasterBrain rows, stamped MasterBrain v2026.26.
The shared energy chain
Every region shares the same energy figure, because only the grid factor changes:
Physical TB = 100 × 3 = 300 TB
Device kWh = 300 × 5.70 × 1 = 1,710 kWh
Facility kWh = 1,710 × 1.2 = 2,052 kWh/yr
What changes between regions is only the final multiplication by the grid factor.
Region-by-region result
| Region | Facility energy | Grid factor (kg CO₂e/kWh) | Scope 2 (tCO₂e/yr) |
|---|---|---|---|
| France (fra) | 2,052 kWh | 0.04144 | 0.085 |
| United Kingdom (gbr) | 2,052 kWh | 0.13096 | 0.269 |
| India (ind) | 2,052 kWh | 0.67013 | 1.375 |
The arithmetic makes the chain concrete: 2,052 kWh × 0.13096 kg CO₂e/kWh = 268.7 kg, or 0.269 tCO₂e, for the UK. Identical data, identical hardware, identical redundancy and PUE — and a roughly sixteenfold spread between France and India, driven entirely by the grid the data centre draws from. This is the lesson of storage accounting in one table: the architecture decisions matter, but region dominates.
The calculator’s built-in default example is a useful reproducibility anchor: 500 TB nearline HDD, triple-replica, UK grid, PUE 1.2, one year yields 1.344 tCO₂e (physical 1,500 TB, 10,260 kWh facility energy). If your inputs match those and the result differs, the MasterBrain version or a grid-factor refresh has moved underneath the example — check the version stamp on your result against the MB v2026.26 stamp on this page.
Cloud storage vs compute and other digital footprints
Storage is one line of a digital-services inventory, and it behaves differently from the others. Compute scales with utilisation and runs intermittently; storage scales with capacity and runs continuously. Understanding where storage sits relative to its siblings keeps the boundary clean and points to the right tool for each line.
| Digital line | Accounting unit | Dominant lever | Tool |
|---|---|---|---|
| Cloud storage | Capacity × time (TB-year) | Grid region, then redundancy | This calculator |
| Cloud compute | vCPU-hours / utilisation | Utilisation and grid region | Cloud Compute Calculator |
| AI training / inference | Compute-hours per run | Hardware efficiency and grid | AI Compute Calculator |
| Data centre facility | Total facility energy | PUE and grid | Data Centre PUE Calculator |
| Website / data transfer | Bytes transferred | Data volume and network path | Website Digital Carbon Calculator |
The Cloud Compute Calculator is the direct sibling — it explicitly defers the storage line to this tool, so the two together cover the compute-plus-storage core of a cloud inventory. For a single service-level intensity number across the whole stack, the Software Carbon Intensity Calculator applies the ISO/IEC 21031 SCI specification.
Reducing storage emissions — levers that move the number
Because the footprint is a product of five terms, every reduction lever maps to one of them. Ranked by typical impact on a mature estate:
- Region placement (grid factor). The widest lever. Siting archival and backup tiers in low-carbon-grid regions can cut their footprint by an order of magnitude with no change to hardware or durability. Latency-tolerant data is the portable candidate.
- Retention and lifecycle policy (capacity × time). The footprint is capacity multiplied by time — deleting or archiving stale data reduces both. Automated lifecycle rules that demote and eventually expire cold data attack the largest term directly.
- Redundancy right-sizing (physical multiplier). Not all data needs triple replication. Moving reproducible or low-criticality data from 3× replication to erasure coding cuts its physical footprint by more than half.
- Tiering across media (intensity). Demoting cold data from SSD to HDD halves its intensity; moving genuine archives to tape cuts it an order of magnitude further.
- Facility efficiency (PUE). Consolidating from legacy enterprise rooms into hyperscale or efficient colocation cuts the PUE overhead — often the only lever available to a pure cloud buyer is provider and region selection, which bundles PUE and grid together.
The two largest levers — region and retention — are not hardware problems. They are policy and placement decisions that a data owner controls without touching the storage stack. Most estates carry a long tail of cold data sitting on hot media in a high-carbon region, retained past any real need; addressing that tail typically beats any single technology swap.
Reporting context — GHG Protocol, SCI, IFRS S2, CSRD, SWD
A cloud-storage figure feeds several disclosure surfaces depending on which side of the boundary you sit and which regime you report under. The frameworks below cover the disclosure context.
| Framework | Role for cloud-storage emissions | Where the figure lands |
|---|---|---|
| GHG Protocol (Corporate + Scope 3) | The accounting standard. Storage electricity is Scope 2 for the operator and Scope 3 Category 1 for the buyer; the dual-reporting rule governs location- vs market-based. | Scope 2 (operator) or Scope 3 Cat 1 (buyer) |
| Software Carbon Intensity — ISO/IEC 21031 | The service-intensity specification. Storage energy is one component of the SCI score for a software system, expressed per functional unit. | SCI component — see the SCI Calculator |
| Sustainable Web Design Model | Per-byte digital-carbon estimation. Storage is one term in the broader digital-service footprint the SWD model frames. | Digital-service inventory line |
| ISO/IEC 30134 & Uptime Institute PUE | The KPI definitions behind the facility wrapper — PUE, and related data-centre efficiency metrics used to justify the multiplier. | Facility-efficiency disclosure input |
| IFRS S2 / CSRD ESRS E1 | The disclosure mandates. Both require Scope 2 and material Scope 3 disclosure; a cloud-storage line rolls into the entity’s Scope 2 or Cat 1 total. | Annual climate / sustainability statement |
Data sources, factor versioning, and update transparency
The complete underlying reference — every factor in this section, versioned with full source provenance and downloadable as CSV with a citable Zenodo DOI — is published as the Google Cloud region carbon-intensity dataset.
Storage intensity and embodied factors
Operational intensity coefficients derive from the Cloud Carbon Footprint “Cloud Jewels” storage coefficients (HDD 0.65 Wh/TB-h, SSD 1.2 Wh/TB-h, annualised over 8,766 hours), giving nearline HDD and HDD-backed object storage 5.70 kWh/TB·yr, hot SSD 10.52 kWh/TB·yr, and cold/archive tape a conservative ~0.5 kWh/TB·yr. Embodied factors use enterprise-drive LCA figures (HDD 1.2, SSD 2.5, tape 0.05 kg CO₂e/TB) as the default, with a consumer-grade sensitivity (HDD 20, SSD 160 kg CO₂e/TB) available as an upper bound.
| Factor | Value | Basis | Source |
|---|---|---|---|
| Hot / SSD intensity | 10.52 kWh/TB·yr | 1.2 Wh/TB-h × 8,766 h | Cloud Carbon Footprint “Cloud Jewels” 2024 |
| Nearline / HDD & object intensity | 5.70 kWh/TB·yr | 0.65 Wh/TB-h × 8,766 h | Cloud Carbon Footprint “Cloud Jewels” 2024 |
| Cold / archive (tape) intensity | ~0.5 kWh/TB·yr (low confidence) | Tape-library overhead estimate | Placeholder pending dedicated tape LCA |
| Embodied — enterprise (HDD / SSD / tape) | 1.2 / 2.5 / 0.05 kg CO₂e/TB | Enterprise-drive LCA, amortised | Seagate Exos/Nytro + WD FY2022 |
| Embodied — consumer sensitivity (HDD / SSD) | 20 / 160 kg CO₂e/TB | Consumer-grade upper bound | Tannu & Nair (arXiv:2207.10793) |
| Grid factor (location-based) | Per country | National average, location-based | DEFRA 2026 (GB) / Ember 2025 / EPA eGRID 2023 (US) |
Grid and PUE — shared datasets
Grid factors are the same location-based national rows the Scope 2 Electricity Calculator reads — GB from DEFRA, other countries from Ember Yearly Electricity, the US from EPA eGRID — so a storage figure and an electricity figure for the same region reconcile. PUE presets come from the data-centre PUE dataset shared with the Data Centre PUE Calculator.
MasterBrain versioning
The storage-intensity, embodied, and redundancy factors ship as a dedicated MasterBrain family, and grid factors refresh annually (DEFRA each June for the UK; Ember on its yearly cycle). The worked example was computed against MasterBrain v2026.26. Each result is stamped with the version it was computed against, so a figure computed against one vintage and the same figure against a later one are distinguishable in restatement work.
Frequently asked questions
It depends almost entirely on redundancy, media, PUE, and grid region — there is no single number. As a worked reference, 1 TB of logical nearline-HDD data on a triple-replica store (3 physical TB) at PUE 1.2 draws about 20.5 kWh of facility energy a year; on the UK grid that is roughly 2.7 kg CO₂e, on the French grid about 0.85 kg, and on the Indian grid about 13.7 kg. The tenfold-plus spread is why a per-TB figure is only meaningful with its configuration and region stated.
For a given quantity of stored data, HDD is roughly half the operational intensity of SSD per terabyte — about 5.70 versus 10.52 kWh/TB·yr in this calculator, from the Cloud Jewels coefficients. SSD earns its higher energy cost through low latency, so it is the right medium for hot, frequently accessed data and the wrong place to leave cold data. Embodied carbon per terabyte is also higher for SSD on the enterprise-LCA default. The greenest move is usually tiering: keep only genuinely hot data on SSD and demote the rest.
Because emissions scale with physical capacity, not the logical capacity you provision. A triple-replicated store holds three physical copies of every byte, so 500 TB logical is 1,500 TB physical — three times the drives spinning, drawing power, and manufactured. Computing emissions from the logical figure understates a 3× store by two-thirds. The calculator applies a redundancy multiplier per storage line and surfaces the physical/logical split explicitly, because it is the most commonly missed term.
Yes, for operational emissions — storage draws power continuously for as long as data is retained, so the footprint is capacity multiplied by time. Deleting or archiving stale data reduces the capacity term directly and, on a replicated store, removes several physical copies. The embodied (manufacturing) carbon of drives already made is sunk, but freeing capacity defers or avoids buying more. Automated lifecycle policies that expire cold data attack the largest lever on most estates.
It depends which side of the boundary you are on. If you operate the data centre, the storage electricity is your Scope 2 (purchased electricity) and the drives are Scope 3 capital or purchased goods. If you buy storage as a service, the provider’s electricity is your Scope 3 Category 1 (purchased services). The same kilowatt-hour is Scope 2 for the operator and Scope 3 for the buyer across the value chain. This calculator’s operational output is a Scope 2 figure; a buyer can use it as an activity-based Cat 1 estimate, but should prefer a provider’s allocated figure where one exists.
Report both — the GHG Protocol Scope 2 dual-reporting rule requires a location-based figure and, where you hold contractual instruments, a market-based one. This calculator’s core output is location-based, reflecting the physical grid the facility draws from. The Google Cloud mode surfaces a carbon-free-energy market-based guide alongside it; for a full market-based treatment with renewable instruments and a residual mix, use the Scope 2 Electricity Calculator. Never net a market-based claim into a location-based total.
Grid carbon intensity. National grids span more than a twentyfold range — from around 0.028 kg CO₂e/kWh in Norway to about 0.670 in India on the calculator’s live values. Because emissions are facility energy times the grid factor, identical data, hardware, redundancy, and PUE produce an order-of-magnitude different footprint depending only on where the data centre sits. For latency-tolerant archival and backup data, region placement is a genuine decarbonisation lever, not just a reporting artefact.
Optionally, and reported separately. An embodied toggle adds a Scope 3 Category 1 line — physical TB × per-TB embodied factor ÷ useful life × years — using enterprise-drive LCA figures by default (HDD 1.2, SSD 2.5 kg CO₂e/TB), with a consumer-grade sensitivity roughly fifteen times higher available as an upper bound. It is never blended into the Scope 2 operational hero. For full asset-lifecycle and end-of-life accounting, the IT Asset & E-Waste Lifecycle Calculator covers the whole life.
Treat it as indicative, not assurance-grade. The cold/archive intensity (~0.5 kWh/TB·yr) and the tape embodied factor are conservative, low-confidence placeholders pending a dedicated tape-library life-cycle study. Tape genuinely draws far less power than spinning disk at rest, so the order-of-magnitude advantage is real, but the precise figure carries more uncertainty than the HDD and SSD coefficients. If the archive tier is material to your result, flag the assumption in your disclosure.
This calculator is activity-based — it needs capacity, media, redundancy, region, and PUE, not spend. Where you hold only a storage bill and no capacity or configuration data, a spend-based estimate via the Scope 3 Category 1 Spend-Based Calculator is the honest fallback, at lower data quality. The activity-based route here is more accurate and more auditable, so gather capacity and region from the provider console where you can, and reserve spend-based estimation for the tail you cannot resolve.
Methodology notes and limitations
Boundary. The calculator produces the storage line only — operational electricity of stored data (Scope 2) and an optional amortised embodied line (Scope 3 Category 1). Compute, network/egress, and end-of-life are separate lines with their own tools. It does not decide your organisational or operational boundary.
Operational factors. Storage-media intensity uses the Cloud Carbon Footprint “Cloud Jewels” coefficients annualised over 8,766 hours. These are coefficient-based averages, not measured drive telemetry; a facility with unusually dense or sparse utilisation will differ from the coefficient.
Cold/archive is low-confidence. The tape intensity (~0.5 kWh/TB·yr) and tape embodied factor are conservative placeholders pending a dedicated tape-library LCA. Archive-tier results are indicative; flag the assumption where the tier is material.
Embodied is amortised and basis-dependent. The embodied line amortises manufacturing carbon over the drive’s useful life (HDD/SSD 5 years, tape 15) and scales to physical capacity. Enterprise-drive LCA is the default because cloud estates run datacenter-grade hardware; the consumer-grade sensitivity (~15× higher) is an upper bound for stress-testing, not a central estimate. State which basis a reported embodied figure uses.
Redundancy is user-declared. The calculator applies the redundancy multiplier you select per line; it does not detect your provider’s actual replication policy. Confirm whether the provider’s capacity report is logical or physical before entering it, to avoid double-counting or omitting redundancy.
Grid factor is location-based. The core output uses the location-based national grid factor by country code. Market-based reporting (RECs, PPAs, residual mix) is a separate treatment; beyond the Google CFE guide, use the Scope 2 Electricity Calculator. Never net a market-based claim into a location-based total. Provider modes other than the generic by-country path (Google CFE, AWS single-region, Azure qualitative) carry their own caveats and never substitute one provider’s factor for another.
Factor currency. Grid factors refresh annually and the storage factors ship as a dedicated MasterBrain family; each result carries a version stamp. Values on this page reflect MasterBrain v2026.26 and will move as the data layer refreshes — resolve live values from the calculator, not from the worked example.
No assurance opinion. Results are estimates and do not constitute an assurance opinion. They should be reviewed by a qualified practitioner before use in IFRS S2 disclosures, CSRD ESRS E1 datapoints, or an SCI rating, and reconciled against provider capacity reports and any published facility PUE.