Why consider emissions from Cloud?
Cloud services are computing services delivered over the internet, including storage, servers, databases, networking, software, and analytics.
Cloud and network infrastructures represents 15% of the overall energy consumption linked to digital, and this share is even higher for a company. But providers like Amazon (AWS), Google (GCP) or Microsoft (Azure), running the biggest datacenters, are really shady on their carbon impact and their electricity consumption. (cf. Carbone 4 article)
Since clients want to know the precise impact of their digital activities, we developed models through a list of hypothesis and retro-engineering work to evaluate the electricity consumed and impact of the amortization of servers used.
Each provider having its specificities, we developed one model for each of the biggest ones.
Cloud providers are developing their own carbon reporting tool, but for now only OVH and AWS has been rated sufficient to be used directly in our assessment. GCP is close to be used, and Azure is making progress, but still lack informations on the electricity part.
Differences vs. On-Prem/External Data Centers: 1.Deployment:-Cloud Services: Provided and managed by third-party vendors and accessed online. You usually pay what you consume (by hour of server, GB of storage used etc..)
On-Prem: Deployed within the organization's own facilities and managed internally (on-premise datacenter), or through a provider renting server rooms (external datacenter). You usually buy the physical hardware or rent it for a certain duration (1 month, 1 year). In this case, clients are usually able to collect their energy consumption and equipment inventory
Usually, the bigger the datacenter is, the more optimized is the energy consumption. There are also benefits with the capability of sharing the same machine between different users.
Scalability:-Cloud Services: Easily scalable with on-demand resources that can be stopped at any time, swapped with more efficient machines (pay-as-you-use model)
On-Prem: Scalability is limited by physical infrastructure and requires hardware upgrades. You need more infrastructure management and previsions.
Cost:-Cloud Services: Operate on a subscription or pay-as-you-go model, reducing upfront costs.
On-Prem: Involves significant initial investment in hardware and continuous maintenance expenses. This solution can still be cheaper in the long run.
Management:-Cloud Services: Management, updates, and maintenance are handled by the cloud provider.
On-Prem: The organization is responsible for all aspects of management, updates, and maintenance.
So while the goal between cloud services and on-prem datacenters is the same, this choice changes a lot for companies Cloud providers are often referred to as "black boxes" because:
Lack of Transparency: Users have limited visibility into the internal operations, infrastructure, and management practices of the cloud provider.
Control: Users cannot directly access or modify the underlying hardware and software configurations.
Proprietary Technologies: Providers use proprietary technologies and methods, which are not disclosed to customers.
This can make it difficult for users to fully understand how their data is handled and how services are managed. Cloud providers are providing dashboards (free or paid), but restrains access to non-necessary information, like the average workload (= actual work vs maximum work a server can achieve) of the machines you are using.
This means it is especially difficult to understand the GHG emissions linked to cloud purchases
Type of raw data
The types of GHG emissions of cloud providers are similar to on premise datacenters, and include:
Electricity Consumption: Emissions from generating the electricity used to power servers and data center operations.
Hardware Amortization: Emissions from manufacturing, transporting, and disposing of IT hardware.
Cooling: Emissions from coolant leaks (electricity used for cooling is in the 1st category).
Other Indirect Emissions: Emissions from buildings' amortization and employee commuting.
This final category is not taken into account in cloud models, because they are tough to quantify, and represent a small share of overall emissions.
How do we do?
The Greenly methodology uses "cost & usage" billing files to derive physical data. The study is indeed a physical study, which tracks electricity consumption, hardware depreciation, and refrigerant usage. It even differentiates emissions related to computation, data storage, and data transfer. It is therefore a strict and comprehensive methodology that allows for the best measurement of these emissions and understanding them to better reduce them. In particular, it is the best way to have a representation of cloud emissions per service and per country.
It also allows giving a representation of the countries in which cloud operations are run, and the associated carbon intensity of electricity.
Processing across referentials
The methodology is the same between GHG Protocol and BEGES
We always use the location-based approach for electricity, even though cloud providers are buying a lot of renewable energy contracts, because this approach is more representative of the real impact, and is aligned with the rest of our EF that are also using location-based approach.
Types of emission factors
Electricity: IEA emission factors
Hardware amortization: Based on the LCA of the Dell R740 server for the compute part, and a study from Louisville university for the storage
Refrigerant gas leaks: Using data in g/MWh from the ADEMExARCEP study, and the gas r-134-a as reference.
Data transfer: Only electricity consumption of the network is taken into account. to convert the GB transfered in kWh, we’re also using the ADEMExARCEP study figures.
How do we calculate emissions
In our cloud analysis, these emissions are splits between 4 different families of services.
Here is an example of the data used for the calculation:
With the date, name of the services used to map it in the right category and get information on the location and type of server/processor used, the quantity (unit depending on the category of the service) and the price. Compute: The usage of computation servers and processors (= computing power) to run applications, websites or processes.
The compute power consumed is measured in hours of vCPUs, which represent the usage of a share of one processor during one hour. Basically, each type of CPU has a number of CPUs “cores” - If they have 4 cores, they are theoretically able to run 4 computations at the same time. Each core can be separated in two “threads”, one thread forming one vCPU.
Each vCPU hour used doesn’t consume the same energy, depending one the processor behind it. To estimate the energy consumption, we are using the TDP (thermal design power) and an estimated workload of 40% on average. Note that the power consumption of a processor is high even when it is idle, so running one processor at 100% of its capacity is better than running two processors at 50%. We also calculate the impact of amortization of servers using data from R740 LCA and the number of vCPU used by the service purchased compared with the total number of vCPU available.
Finally, we calculate the impact of cooling using a proxy with the electricity consumption and a study from ADEME x ARCEP on European datacenters.
Storage: The storage is measured in GB.month (GB being Go for french speakers, so 1GB = 8 Gb). So 1 GB stored during one year is equivalent to 12 GB.month.
To compute the impact of storage linked to electricity and amortization, we base ourself on academical studies, along with the Dell R740 LCA for the impact of storage disks. We calculate the impact of cooling the same way than in the compute part. Transfer: The data transfer is measured in GB, and represents the amount of data transferred either between the datacenter of the client and their users, or data transferred internally between different locations and servers (to duplicate data for example).
We separate 3 types of data transfer:
Internet: For a data transfer using internet network, linked with the “outside world”. This is the most energy-consuming type of data transfer (40x the electricity consumption of the Inter-region) because it is less optimized (a lot of end-points)
Inter-region: For a data transfer between different countries but using the data center network, well optimized
Intra-region: For a data transfer between two servers located in the same datacenter.
The amortization of the network construction isn’t taken into account here, since the sources available are still highly incertain.
Others services: For all the services that we cannot map in on the 3 first categories (monitoring, support, security, logs, IP addresses…), we use this category that is assessed using an expense-based approach, applying the monetary ratio calculated in the first 3 categories. Orders of Magnitude Regarding Cloud Emissions:
Monetary Carbon Intensity:
Typically between 0.02 and 0.2 kgCO₂e/€.
Main Emission Types:-Electricity Consumption and Hardware Amortization are the primary sources.
On low-carbon electricity: ~60% hardware, ~40% electricity.
On high-carbon electricity: ~80% electricity, ~20% hardware.
What are the outputs?
The global outputs provided are emissions split by type (electricity, amortization, refrigerants) and by service (Compute, Storage, Transfer):
We can get more granular with the impact by location:
And also the impact per month
For the compute, we’re able to give results with the hour of vCPU consumed by type of processor, allowing us to compare the efficiency of the services used:
And for the transfer, impact split per type of transfer: