Add embodied emissions to storage

[jnioche]

Closes #102.

Adds embodied_emissions_co2eq_g to the Storage modules for both AWS and Azure, amortised over a five year service life. Until now embodied emissions were only estimated for compute instances and LLM inference, following CCF, which models them for compute usage types only.

Values

	HDD	SSD
basis	30 kg CO2eq per drive, divided by an assumed 15 TB	0.055 kg CO2eq per GB
life	43800 h	43800 h
coefficient	4.566e-5 g/GB-hour	1.256e-3 g/GB-hour
works out at	0.40 kg CO2eq per TB-year	11 kg CO2eq per TB-year

The two media are modelled on different bases because they behave differently. A hard drive costs roughly the same to manufacture whatever its capacity, since the platters, motor, actuator, casing and PCB are near-fixed for a 3.5" unit and areal density does the work. An SSD's die area scales with capacity.

Why 30 kg per drive

Four independent sources land within 8 % of each other across a 40x span of drive capacities, which is itself the evidence for treating HDD embodied carbon as capacity independent:

source	stated as	capacity behind it	per drive
Boavizta / Umweltbundesamt 2021	31.11 kg per unit	modelled capacity-independent	31.1 kg
Seagate Exos X22 LCA, via Tailpipe	0.0013 kg/GB	22 TB	28.7 kg
Seagate	0.27 kg/TB-year	~22.6 TB	~30.5 kg
Tannu & Nair 2023, 24 vendor LCAs	SEF 0.02 kg/GB	sample spans 512 GB to 6 TB	~30 kg at their mean

If manufacturing carbon tracked bytes, those would differ by 40x rather than 8 %.

Note that the Tannu & Nair rate cannot be applied per GB to current hardware: 0.02 kg/GB encodes the drive sizes of a pre-2023 LCA corpus and overstates per-byte embodied carbon by about an order of magnitude. Their Table 1 also gives 1 TB CAPEX as 20 kg at five years, not the 40 kg quoted second-hand in #102, which is the ten year column and includes a replacement drive.

For SSD, Boavizta's die-area formula (0.052 kg/GB) and the 2025 Embodied Carbon Footprint of 3D NAND Memories study (0.056) agree within 8 %. Tannu & Nair's 0.16 kg/GB is roughly 3x higher because 3D NAND layer scaling has cut per-GB manufacturing carbon since their corpus closed.

The assumed 15 TB drive is the installed-fleet average implied by Backblaze's 2025 Drive Stats (341,664 drives: 25.13 % at 0 to 12 TB, 52.06 % at 14 to 16 TB, 22.81 % at 20 TB+). That is the right basis for bytes sitting on hardware bought over several years; current nearline shipments average nearer 22 TB, which would give 0.27 kg per TB-year instead of 0.40.

All four inputs are configuration keys (hdd_embodied_kg_per_drive, hdd_capacity_gb, ssd_embodied_kg_per_gb, storage_lifetime_hours), wired into the four default configs.

Notes

The replication factor applies to embodied as it does to energy: the same bytes occupy that many times more physical drives.

On Azure, hdd_capacity_gb describes the physical drive, not a Managed Disk SKU. The provisioned size of a P10 or S4 volume says nothing about the drive underneath it, so the capacities in MANAGED_DISKS must not be substituted here. Flagged in the javadoc so it does not get "fixed" later.

One consequence worth knowing before merging: SSD-backed storage becomes embodied-dominated. A gp3 volume comes out at roughly 11 kg CO2eq per TB-year embodied against about 4 kg operational, so EBS lines shift materially in any total-emissions ranking.

Incidentally

The AmazonDocDB case in the AWS provideArgsWithType was flagged isSSD=false although AmazonDocDB is in SSD_SERVICES. The energy assertion never caught it because its tolerance was wider than the gap between the two coefficients. Flag corrected and the tolerances tightened from 1e-4 to 1e-12 on both providers.

The numeric parameter reader moved to Utils.doubleParam now that both modules need it.

Still stale

The sample query output in docs/src/tutorial/results.md shows NULL embodied for the S3 and EBS rows. Those will be populated after this change, but the table comes from a real run rather than a bundled dataset, and the AmazonECS / FargateTask row cannot be derived arithmetically because its energy comes from Serverless while its embodied would come from the Fargate ephemeral-storage rows grouped under the same operation. Worth regenerating separately.

[dpol1]

LGTM. One thing I noticed: Boavizta amortises servers over 35040 h (4 years), here storage is 43800. Deliberate?

[jnioche]

LGTM. One thing I noticed: Boavizta amortises servers over 35040 h (4 years), here storage is 43800. Deliberate?

the five years follows Amazon's disclosed useful life for servers and networking equipment, the assumption is that it is the same for drives.

It is an accounting estimate, not a drive replacement policy, and it covers servers and networking equipment as an asset class. AWS does not break out storage media separately, so applying it to a hard drive is an inference on my part.

Tannu and Nair also use 5 years.

As for Tailpipe => The resulting embodied carbon is attributed over a 5.7-year equipment replacement cycle, the average service life of data center equipment reported in the [2024 Lawrence Berkeley National Laboratory data center energy report](https://eta.lbl.gov/publications/2024-lbnl-data-center-energy-usage-report), in proportion to how long the storage is held, in the same way as the other components above.

So 5 felt like a reasonable value. It is configurable anyway