6. Eligibility, Selection, and Inclusion Logic

6.1 Usage Eligibility

Usage that represents the consumption of processor, memory, or accelerator capacity contributes to the electricity figure. Usage that does not, such as support charges and reserved capacity fees, is retained for categorisation without contributing.

6.2 Instance Resolution

Greenpixie resolves each billing usage type to the instance that supplies it. The hardware is identified from that instance. Cloud provider billing catalogues express the same instance through several usage types. These include on-demand, spot, dedicated, and the managed service variants that run the same hardware under a different service prefix. The methodology normalises each of them to the underlying instance.

Some usage types name no instance at all, being application streaming and virtual desktop bundles, database proxy hours, serverless database capacity units, data processing units, and managed database sizes with no equivalent virtual machine size. For each of those, the cloud provider publishes a vCPU count and no hardware. Such a usage type takes the median electricity per vCPU-hour of comparable matched instance sizes for that cloud provider. Against that figure, Greenpixie records how it was produced.

6.3 Processor Matching

Each resolved instance is matched to published server measurements of its processor model. Where no published measurement carries that processor model, matching falls back through progressively broader processor criteria. Where a cloud provider states that an instance family runs on more than one processor, each processor is matched separately. The matched measurements for those processors are then combined into one curve, so that a processor with many published measurements does not displace one with few. A processor a cloud provider designs for its own fleet is instead scaled from a related processor, as described in Section 7.1.

Where Greenpixie cannot resolve the hardware behind a unit of cloud usage, either by matching it to published measurements or by scaling from a related processor, it estimates the electricity of that usage from per-unit rates that this methodology produces across the hardware it does resolve.

6.4 Drive Type and Capacity

Alongside the storage capacity sold with an instance size, each cloud provider states what kind of drive delivers it. Some of those statements name the drive outright, being an NVMe solid state drive or a mechanical hard disk drive. The size is then modelled as carrying drives of that kind. Other statements say only that the drives are solid state, without saying whether they are NVMe or SATA. Where that happens, the capacity of each drive determines which of the two the size is modelled as carrying. Cloud providers deploy NVMe solid state drives and SATA solid state drives over different capacity ranges.

A cloud provider publishes the storage an instance is sold with. It does not publish the drives its host mounts. Where the published capacity for an instance size is smaller than the largest drive that instance family is sold with, the size is apportioned a share of the drives its host mounts, on the basis that the host mounts whole drives and divides them between the instances it runs.

6.5 Host Configuration

A cloud provider does not publish how it packs instances onto a physical host, being how many instances of the instance size being calculated the host runs and how its memory slots are filled. Greenpixie models that host configuration from the number of hardware threads the host has and from the host memory topology of its processor, described in Section 5.5. The host's thread count is taken from the cloud provider's own documentation where the cloud provider publishes it, and otherwise from the matched server measurements. The modelled configuration determines the memory capacity per module and the share of host memory power attributable to one instance. Section 11.3 states how a figure derived this way should be read.