Methodology

Our environmental impact calculations all use a Life Cycle Assessment (LCA) methodology. This means we take into account the manufacture, usage, and disposal of all our hardware. To perform this LCA, we follow the Product Category Rules (PCR), created by ADEME, the French Agency for Ecological Transition. The PCR was developed in collaboration with industry partners, including Exoscale.

The impact data we use in our calculations comes from ResilioDB, developed by Resilio. The calculations are performed using LCA-as-code, developed by Kleis Technology.

Concepts

The following key concepts form the building blocks of our impact estimation methodology.

Zones

Our infrastructure is divided into zones. Each zone maps directly to one data center.

You can read more on our Data centers page.

Hardware

The hardware included in our impact estimations falls into three categories:

1. Rack servers - stand-alone servers with CPUs, GPUs, RAM, storage, power supplies and cooling
2. Blade servers - servers with dedicated CPUs, GPUs, RAM, and storage, in a shared chassis that provides power and cooling
3. Network equipment - including switches and routers

All hardware is housed in a rack, which sits in a room in one of our data centers.

Types of impact

All impact estimates include two types of impact:

• Manufacture - impacts related to the manufacture, transport and disposal of hardware
• Usage - impacts related to resource consumption at runtime

Note that manufacture impacts are zone-independent, i.e. the impact is the same no matter where the hardware is deployed. Usage impacts are heavily zone-dependent, as the electricity mix and data center configuration are different in each zone.

Pools

Resource pools are groups of hardware that are either dedicated to a specific product (e.g. Instances or SOS), or mutualized between products (e.g. shared networking equipment).

An example is the pool of hypervisors and networking equipment used to run our Instances product in the ch-gva-2 zone.

Each piece of hardware belongs to exactly one pool, and its impact is allocated to users in proportion to their usage of that pool, versus the total usage across all users.

This means that the impact of a given Instance type will change each day, depending on the level of usage in the associated zone. The more users there are, the lower the impact attributed to each user. See the Limitations section below for the consequences of this.

Calculating impact

The overall impact of a user’s usage has two components:

• Service-specific impacts - e.g. the impact of running the Instances product
• Mutualized impacts - e.g. the impact of the data center cooling infrastructure

To calculate the impact of a user’s usage of a given product, we calculate the total impact of the pools involved in that usage. We then allocate the pool impacts based on the ratio of the user’s resources to the total resources across all users.

Pool impact

The impact of a pool has a manufacture component and a usage component:

impact_manufacture_pool = sum(impact_manufacture_hardware)
impact_usage_pool_per_hour = sum(impact_usage_hardware_per_hour)

Here impact_manufacture_pool is the total manufacture impact over the lifespan of the pool, while impact_usage_pool_per_hour is the usage impact for each hour the pool is running.

where

impact_usage_hardware_per_hour = power_consumption * electricity_impact_zone_per_kwh

• power_consumption is the average power consumption of a given piece of hardware in kilowatts
• electricity_impact_zone_per_kwh is the average impact of consuming 1 kWh of electricity from the grid in the given zone, taken from Electricity Maps

Allocation ratio

To allocate a share of the total pool impact to a given usage, we calculate two ratios. One is based on the resources used versus the total resources used in the pool, and the other on the duration of the usage versus the lifespan of the pool:

resources_ratio = resources / resources_pool_total
time_ratio = duration / lifespan_pool

Both duration and lifespan_pool are measured in hours.

The value of resources and resources_pool_total will vary depending on the product, and also on the type of impact we are calculating (see below).

Specifically:

impact_usage = resources_ratio_usage * duration * impact_usage_pool_per_hour
impact_manufacture = resources_ratio_manufacture * time_ratio * impact_manufacture_pool

impact = impact_usage + impact_manufacture

where resources_ratio_usage and resources_ratio_manufacture are product-specific, as discussed below.

Mutualized impacts

In addition to the service-specific impacts, we also add an estimate of the impact of mutualized resources, such as networking and data center infrastructure. These are added on top of the pool impacts calculated above.

Networking equipment is shared between all services in a zone, so its manufacture and usage impacts are shared among users of all services accordingly.

The data center impacts are also shared between all users in the zone, covering the construction and disposal of the building itself, as well as cooling and power infrastructure.

Product-specific details

As discussed above, each product will have a slightly different methodology. The difference is in how we calculate the ratio of the user’s resources to the total resources across all users in the pool (i.e. the value for resources_ratio_usage and resources_ratio_manufacture).

Instances

Each Instance type has allocated vCPUs, GPUs, RAM, and attached storage (note that block storage is treated as a separate product). Each GPU has an amount of video random-access memory (VRAM).

We calculate Instance impact using the ratio of these resources to the total amount of each resource in the pool, as outlined in the PCR. Specifically:

alloc_vcpu = pct_weight_cpu * (vcpu_instance / vcpu_pool)
alloc_gpu = pct_weight_gpu * (vram_instance / vram_pool)
alloc_ram = pct_weight_ram * (ram_instance / ram_pool)
alloc_storage = pct_weight_storage * (storage_instance / storage_pool)

resources_ratio = alloc_vcpu + alloc_gpu + alloc_ram + alloc_storage

where

• vcpu_instance, vram_instance, ram_instance, storage_instance are the vCPU, VRAM, RAM, and storage allocated to the Instance respectively
• vcpu_pool, vram_pool, ram_pool, storage_pool are the total vCPU, VRAM, RAM, and storage allocated to all users in the pool
• pct_weight_cpu, pct_weight_gpu, pct_weight_ram, pct_weight_storage are the weights assigned to each component, and reflect how much impact we attribute to each (see below); note that these sum to 1

Component weights

The values of pct_weight_cpu, pct_weight_gpu, pct_weight_ram, and pct_weight_storage reflect how much weight we give to each component when calculating impact, and differ between usage and manufacture impacts.

When calculating usage impact, these weights are based on the average relative power draw of each component type in the pool. Specifically:

power_draw_total = power_draw_cpu + power_draw_gpu + power_draw_ram + power_draw_storage

pct_weight_cpu = power_draw_cpu / power_draw_total
pct_weight_gpu = power_draw_gpu / power_draw_total
pct_weight_ram = power_draw_ram / power_draw_total
pct_weight_storage = power_draw_storage / power_draw_total

When calculating manufacture impact, these weights are based on the manufacture impact of each type of component:

impact_manufacture_total = impact_manufacture_cpu + impact_manufacture_gpu + impact_manufacture_ram + impact_manufacture_storage

pct_weight_cpu = impact_manufacture_cpu / impact_manufacture_total
pct_weight_gpu = impact_manufacture_gpu / impact_manufacture_total
pct_weight_ram = impact_manufacture_ram / impact_manufacture_total
pct_weight_storage = impact_manufacture_storage / impact_manufacture_total

Object and block storage

Both object and block storage follow the same methodology, based on the ratio of a user’s storage to the total storage across all users in the pool. To calculate object and block storage impact, we use the following:

resources_ratio_usage = storage_user / storage_pool
resources_ratio_manufacture = storage_user / storage_pool

That is, we divide the user’s storage by the total storage of all users in the pool, and allocate the total pool impact based on this ratio.

Limitations

Pooling

Pooling resources is key to the PCR methodology, and without it, the methodology would be difficult to implement at scale across heterogeneous hardware. Without pooling, we would need to track specific hosts, utilization, and power consumption for every workload, which is difficult in a production cloud. Collecting and standardizing this data across all products is even more difficult.

While pooling brings many advantages, it also brings the following issues:

1. Workloads do not see the impact of the specific hardware they use. Instead, they see an average impact of all the hardware used to run that product.

2. Hardware lifespan is averaged. Users running on older hardware will see no change in impact versus newer hardware with the same resource allocation.

Sharing impacts based on total usage

The PCR methodology shares impacts using the ratio between a user’s own consumption, and the total consumption of all users. This has the benefit of accounting for idle resources: users see a higher impact in zones with lower overall utilization.

However, this means that a large part of a user’s reported impact is out of their control. Impact is based on the activity of other users and how efficiently the provider manages the utilization of their infrastructure.

This also means that the impact of a given service will vary day to day, as the usage of that service changes, making it harder for users to do like-for-like comparisons over time.