Methodology

Our environmental impact calculations all use a Lifecycle 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 Recommendations (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 Zones page.

Hardware

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

Rack servers - stand-alone servers with CPUs, GPUs, RAM, storage, power supplies and cooling
Blade servers - servers with dedicated CPUs, GPUs, RAM, and storage, in a shared chassis, providing shared power and cooling
Network equipment - including switches and routers

All hardware exists in a rack, which exists in a room in one of our data centers.

Types of impact

All impact estimates include two types of impact:

Manufacture - impacts related to building, transporting and disposing 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 datacenter 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).

Each piece of hardware belongs to exactly one pool, and its impact is allocated to users proportional to their usage of that pool.

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

Calculating impact

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, then share the pool impacts based on the proportion of resources consumed.

Pool impact

The total impact of a pool is:

impact_pool = impact_manufacture_pool + impact_usage_pool

where

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

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 ElectricityMaps

Allocation ratio

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

resources_ratio = resources / resources_pool_total
time_ratio = duration / lifespan_pool

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, and discussed below:

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 available 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 available 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 100%

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 are different for the 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 = 100 * power_draw_cpu / power_draw_total
pct_weight_gpu = 100 * power_draw_gpu / power_draw_total
pct_weight_ram = 100 * power_draw_ram / power_draw_total
pct_weight_storage = 100 * 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 = 100 * impact_manufacture_cpu / impact_manufacture_total
pct_weight_gpu = 100 * impact_manufacture_gpu / impact_manufacture_total
pct_weight_ram = 100 * impact_manufacture_ram / impact_manufacture_total
pct_weight_storage = 100 * 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 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

Meaning we simply divide the user’s storage by the total storage available in the pool, and share total pool impact based on this ratio.

Shortcomings

There are several trade-offs inherent in the PCR methodology, which are discussed below.

Pooling

Pooling resources is key to the PCR methodology, and without it, the methodology would be unfeasible to implement at scale. 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:

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.
Hardware lifespan is averaged. Users using older hardware will see no change in impact versus newer hardware with the same resource allocation.

Idle resources

The PCR methodology does not include a factor to account for the level of utilization within a pool. For example, the impact of a given Instance is always the same, regardless of whether that is the only Instance running in an otherwise idle pool, or whether the pool is almost full.

This is good because it means that impact estimations are consistent, and not dependent on levels of activity on the provider’s hardware. However, it does mean that idle machines are ignored in impact calculations, and the impact of a provider’s own (in)efficiency must be accounted for elsewhere.

Last updated on September 2, 2026