Comprendre les résultats des calculettes carbone des clouds providers

Ecrit par Boavizta le .

Il est de plus en plus souvent demandé aux DSI d’inclure les impacts de leurs ressources externalisées dans leurs bilans environnementaux (scope 3 dans une vision bilan carbone). Pour répondre à ces besoins d’évaluation, les principaux clouds providers proposent des calculettes pour estimer les émissions carbone liées à l’utilisation de leurs services. Communiquer les impacts associés aux usages de ses clients implique, d’une part, l’évaluation des différents postes d’impacts dans le périmètre choisi et d’autre part, d’allouer ces impacts à chacun de ses clients. Ceci est d’autant plus important que les services Cloud sont fortement mutualisés.

Ce procédé est fortement dépendant du périmètre et des règles d’allocations choisies. Il est donc nécessaire de se demander :

  • À quoi correspondent ces chiffres ?
  • Comment les expliquer ?
  • Quel niveau de transparence est-il donné ?

Nous présentons dans cet article les calculettes des trois principaux cloud providers : AZURE, GCP & AWS à travers leur périmètre d’une part et leur mode d’allocation d’autre part.

Les méthodes mises en œuvre étant en constante évolution, cet article est susceptible d’évoluer dans le temps. Les informations actuelles valent pour le 30 avril 2023. Ce travail étant collaboratif, n’hésitez pas à nous faire part d’éventuelles erreurs ou demandes d’évolutions.

Vocabulaire

  • Scope 1, 2 & 3 : https://www.territoires-climat.ademe.fr/ressource/42-14

  • Allocation : Le processus d’allocation vise à distribuer les impacts d’une ressource dite multifonctionnelle (qui sert plusieurs usages). Dans le cadre du cloud, de nombreuses ressources servent plusieurs usages (refroidissements, réseaux, services internes, …).

  • Location-based : La méthode location-based calcule les émissions liées à la consommation d’électricité en fonction du mix électrique de la région où a lieu la consommation.

  • Market-based : La méthode market-based calcule les émissions liées à la consommation d’électricité en fonction de l’électricité achetée par le consommateur. Certains acteurs proposent un double affichage - location-based & market based à titre indicatif. Boavizta plaide pour une utilisation systématique des méthodes location-based. Quand les deux chiffres sont reportés, ceux évalués avec une méthode location-based doivent être réutilisés.

  • Top-down : Les méthodes top-down visent à établir des impacts environnementaux en distribuant les impacts globaux d’un système sur l’ensemble des unités fonctionnelles fournies par le système. L’avantage de cette approche est qu’elle est relativement simple à comprendre et à mettre en œuvre. L’inconvénient est qu’elle tend à moyenner les impacts des différents usages évalués.

  • Bottom-up : Les méthodes bottom-up visent à agréger les impacts des différentes ressources nécessaires à la mise en œuvre de l’usage évalué (équipement, opérations, services de tiers, etc.).

  • Overhead : On appelle overhead l’ensemble des équipements techniques non-IT présents dans les DC qui sont nécessaires au bon fonctionnement des services. On peut citer le système d’alimentation, le système de refroidissement, l’éclairage….

La calculette carbone d’Azure

Sources

Périmètre couvert par la calculatrice carbone

Scope 1

Certaines émissions du scope 1 sont prises en compte, mais leur périmètre n’est pas précisé dans la méthodologie de Microsoft.

Scope 2

Concernant le Scope 2, la consommation électrique est mesurée aux portes des datacenters. Microsoft obtient ainsi l’ensemble de la consommation électrique consommée au sein de chaque datacenter.

Les émissions sont communiquées en market-based. Il est possible de retrouver une métrique en location-based de manière contournée en ajoutant les émissions “sauvées” par les énergies renouvelables au market-based. Pour rappel, le GHG Protocol recommande le report de deux chiffres. Il existe de nombreux arguments pour ne considérer que l’approche location-based.

Le guide méthodologique du Bilan Carbone (ADEME/ABC) est clair à ce sujet :

Le Bilan Carbone® a vocation à refléter une réalité physique et non une appellation commerciale. La production d’électricité renouvelable est rarement autoconsommée, et est donc très souvent connectée au réseau national : cette production « verte » s’inscrit donc dans le mix électrique national. Le développement des énergies « vertes » a pour conséquence la réduction du facteur d’émission du mix électrique national.

Par ailleurs, l’utilisation du market-based par un client d’Azure ne lui permet pas de suivre ses progrès de réduction d’empreinte.

Scope 3

Pour le Scope 3, les émissions liées aux phases d’extraction des matières premières, de fabrication et de fin de vie des équipements IT sont prises en compte. Les émissions liées au transport sont néanmoins exclues. Microsoft mentionne l’utilisation d’une méthode d’analyse de cycle de vie qui n’est pas rendue disponible.

Mise à jour des données

Les données liées aux scopes 1, 2 et 3 sont mises à jour sur une base mensuelle.

Conclusion

Au-delà du manque de transparence sur le scope 1 et 3, il manque au périmètre de Microsoft une partie du Scope 3, à savoir les émissions liées au transport des équipements IT, aux bâtiments, au transport des salariés et également aux équipements techniques (non-IT) du datacenter.

Allocation

Évaluer l’impact d’une région

Les impacts des Scopes 1 et 2 sont modélisés au niveau de chaque datacenter. Les impacts du Scope 3 sont évalués en agrégeant les impacts de la fabrication et de la fin de vie de tous les équipements IT au niveau de chacun des datacenters. De cette manière, Microsoft récupère les impacts scope 1, 2 & 3 pour chacun de ses datacenters. Les impacts des datacenters sont ensuite agrégés par région.

Allouer l’impact d’une région à un usage

Pour allouer les impacts d’une région aux différents types de services qu’elle opère, Microsoft utilise une méthode top-down basée sur une métrique de coût qui normalise la consommation de ses services IaaS, PaaS et SaaS. En combinant la quantité totale d’unités consommées pour chaque type de service et l’impact total d’une région, Microsoft obtient l’impact total par type de service par région. Puisque seuls les usages finaux (IaaS, PaaS et SaaS) sont comptabilisés, mais que l’ensemble des impacts de la région sont considérés, les usages des services internes sont distribués proportionnellement aux services finaux en fonction de leur importance dans la région.

Finalement, les impacts de chacun des services sont attribués aux clients en fonction de la quantité de métrique de coût normalisé unitaire consommée pour chaque service et pour chaque région.

schéma Azure

L’approche de Microsoft permet de distribuer l’ensemble des impacts considérés aux services vendus. Cependant, la construction d’une clef d’allocation unique : “unité de coût normalisé” qui dimensionne les résultats n’est pas transparente. Ceci est un problème d’importance quand on sait qu’une telle clef d’allocation s’éloigne des effets physiques réellement à l’œuvre. En effet, la relation coût / empreinte est de moins en moins étroite au fur et à mesure que l’on monte dans les couches de services qui offre des niveaux de mutualisation importants : assez étroite pour l’IaaS, un peu moins étroite pour le PaaS, jusqu’à assez vague pour du SaaS.

Émissions dites “évitées”

Azure partage également les émissions dites “évitées” en comparaison à une infrastructure on-premise. Nous ne rentrerons pas dans le détail des limites méthodologiques qui sont déjà présentées dans cet article : https://boavizta.org/blog/les-reductions-d-emissions-de-co2-promises-par-les-cloud-providers-sont-elles-realistes

La calculette carbone de GCP

Seul la méthodologie mis en œuvre pour Google Cloud Platform (GCP) est considéré ici. Nous ne considérons donc pas Google Workplace.

Sources

Périmètre

Scope 1

Les émissions liées au Scope 1 sont en partie prises en compte. Google prend en compte les émissions liées à la combustion de ressources fossiles sur les sites des datacenters et de la consommation de la flotte de véhicules thermiques. Ils communiquent sur le fait que les émissions liées à des fuites de liquides de refroidissement ne sont pour le moment pas prises en compte.

Scope 2

Concernant le Scope 2, Google suit une approche bottom-up en prenant en compte la consommation électrique des équipements IT (compute, storage, network) ainsi que de l’overhead. L’approche bottom-up permet une plus fine allocation des consommations aux services. Cependant, elle tend à perdre une partie du périmètre. On peut penser qu’il existe dans les datacenters des consommations liées à d’autres éléments tels que les équipements IT des collaborateurs. Ces consommations sont peut-être négligeables.

Les émissions liées au Scope 2 sont communiquées à la fois en market-based et en location-based, ce qui est la recommandation du GHG Protocol. Cependant, il existe de nombreux arguments pour ne considérer que l’approche location-based. Les intensités carbone en location-based sont évaluées sur une base horaire à partir des données d’ElectricityMaps.

Scope 3

Enfin, Google prend en compte un Scope 3 quasiment complet avec les émissions liées à la fabrication des ressources IT, du bâtiment, des déplacements de leurs collaborateurs avec une méthode bottom-up. Google communique sur le fait que les émissions liées à la fin de vie des équipements ne sont pas prises en compte. Selon Google, la méthode de prise en compte des impacts du Scope 3 amonts liés aux équipements IT suit une approche d’analyse de cycle de vie. Celle-ci n’est néanmoins pas détaillée.

Mise à jour des données

Les données liées au scope 3 sont mises à jour sur une base mensuelle. Une durée de vie de 4 ans est utilisée pour exclure du scope 3 le matériel. Les données liées au Scope 2 sont mises à jour sur une base horaire. Les facteurs d’impact de l’électricité utilisés sont mis à jour sur une base horaire.

Conclusion

On notera que le périmètre de la calculette de Google est assez transparent sur les éléments pris en compte et ceux non pris en compte. La difficulté à prendre en compte les éléments hors périmètre peut expliquer leur non prise en compte (manque de méthodes, de données, …). On peut regretter le manque de transparence sur les données d’analyse de cycle de vie qui sont à la base de l’évaluation des impacts.

Allocation

Les impacts liés au Scope 2 sont alloués à chacun des services disponibles dans la région de façon spécifique en fonction du type d’impact :

Allocation scope 2 sur chaque service de la consommation des équipements IT utilisés

La consommation électrique des équipements IT utilisés par les services est allouée à chacun des services qu’elle opère en fonction du pourcentage de temps CPU utilisé par ce service dans l’heure. Cette règle d’allocation permet de distribuer la consommation d’une machine opérant plusieurs services en une heure.

Allocation scope 2 sur chaque service de la consommation des équipements IT IDLE

Puisque nous sommes dans une approche bottom-up, il est nécessaire de prendre également en compte la consommation associée aux équipements IT non utilisés. La consommation des machines IDLE est allouée en fonction de la proportion d’équipements IT utilisés par chacun des services (équipement IT en phase de run). Google considère à juste titre que les machines IDLE servent à fournir la haute disponibilité, l’allocation par ressources consommées permet d’attribuer les impacts de ces ressources en fonction du potentiel de réservation supplémentaire nécessaire à chacun des services.

Allocation scope 2 sur chaque service de l’overhead

Pour être exhaustif, il est également nécessaire de prendre en compte la consommation liée à l’overhead. Celle-ci est attribuée à chaque machine en fonction de sa propre consommation électrique. L’attribution est faite pour chacune des zones et sous-zones du DC. La consommation d’un serveur est donc considérée comme étant sa propre consommation associée à la consommation de “son overhead”.

Allocation scope 2 sur chaque service de l’impact des services internes

À ce stade, Google a une consommation électrique horaire par service pour les services internes et les services vendus. Les impacts liés aux services internes sont attribués aux services vendus proportionnellement à l’usage des services internes par les services vendus.

Allocation Scope 2 aux clients utilisant un service

Les mécanismes d’allocations décrits ci-dessus permettent d’obtenir une consommation électrique horaire par service vendu par région. Les impacts associés sont évalués selon la méthodologie location based à partir des données fournies par ElectricityMaps.

Enfin, les impacts liés au Scope 2 de chacun des services sont alloués à chaque client en fonction de la quantité consommée sur la quantité totale délivrée, avec une clé de répartition liée à la facturation (Stock Keeping Unit SKU). Comme pour Azure, une telle clef d’allocation s’éloigne des effets physiques réellement à l’œuvre. Cependant, elle n’est utilisée que pour l’allocation finale aux utilisateurs et non pour calculer les impacts des services (qui suivent une approche bottom-up). Les valeurs en SKU de chacun des services est disponible pour les utilisateurs.

Allocation des scopes 1 et 3 aux clients

Les impacts liés au Scope 1 & 3 sont alloués de manière top-down non régionalisé. L’ensemble des impacts Scope 1 & 3 mondiaux de GCP sont distribués aux clients en fonction de la proportion d’énergie consommée par client (calculée plus haut). Ce type d’allocation ne permet pas de prendre en compte les spécificités des impacts liés au scope 1 & 3 des différents services. Ceci est problématique car la relation entre la consommation électrique et les impacts liés au scope 3 n’est pas linéaire et change en fonction des types et des usages des services. On pense en particulier aux services réservant une quantité importante de matériel (impact Scope 3 important) mais sous-utilisés (consommant peu d’électricité).

schéma GCP

La calculette carbone d’AWS

Source

Périmètre

Seuls les impacts liés au Scope 1 et au Scope 2 sont inclus dans le périmètre de la calculette.

Seul le market-based est présenté, et le périmètre précis des activités prises en compte n’est pas documenté.

Allocation

Non documentée

On peut regretter de la part d’AWS un manque de maturité de leur calculette ajouté à un manque de transparence. Il est cependant à noter qu’AWS met davantage en avant son Well-Architected Sustainability Pillar (bonnes pratiques GreenOps) plutôt que cette calculette bien moins avancée que celle de ses concurrents.

Conclusion

Cette revue des méthodes mises en œuvre par les CSP permet de prendre conscience de la pluralité des approches qui coexistent dans un secteur en manque de normalisation.

Des outils comme cloud-scanner (en développement par Boavizta) ou Cloud-carbon footprint offrent des alternatives transparentes, granulaires et normalisées[^1]. Elles sont cependant limitées aux données architecturales rendues disponibles par les CSP. Une des conséquence et une tendance à sous-estimer de manière importante les impacts en ignorant une partie des ressources et de l’énergie consommée par des services internes. Des travaux comme ceux conduits par l’ADEME à travers leur RCP Datacenter et cloud ou encore ceux portés par la SDIA sur l’ouverture des données environnementales des datacenters sont des pistes à soutenir pour apporter plus de normalisation et de transparence au secteur.

Au-delà des impacts liés aux émissions de gaz à effet de serre, le public s’intéresse de plus en plus aux autres impacts induits par les hyperscalers à l’image de la récente polémique sur l’utilisation d’eau d’un DC de Microsoft en période de sécheresse aux pays bas, sur l’occupation des sols ou encore les enjeux lié aux déchets (bâtiments, D3E,..). Il est important d’avoir une approche multicritères pour comprendre l’ensemble des impacts environnementaux des services numériques et pour éviter les transferts de pollution. Pour avancer dans ce sens, Cloud-scanner implémente les méthodes multicritères proposées par Boavizta.

Enfin, pour que ces indicateurs aient une utilité, il est nécessaire qu’ils soient intégrés dans les démarches des DSI. Pour discuter de ce dernier point, nous sommes à la recherche de retours d’expériences pour un prochain article sur l’usage fait par les organisations de ces calculettes.

Périmètres : Synthèse

Item SCOPE \ (relative to provider) AZURE GCP AWS
Phase du cycle de vie
Extraction 3 OUI OUI NON
Fabrication 3 OUI OUI NON
Usage 1 & 2 OUI OUI OUI
Fin de vie 3 OUI NON NON
Item
Bâtiment 3 NON OUI NON
Équipements IT 2 & 3 OUI OUI OUI
Overhead 2 & 3 OUI OUI ?
Déplacement domicile travail des salariés 3 NON OUI NON
Fuites de liquide de refroidissement 1 ? NON ?
Impacts du trafic IP Dépendant du type d’infra OUI NON ?
Source d’énergie fossile combustible sur site 1 ? OUI OUI
Impacts des ressources IDLE 2 & 3 OUI OUI ?
Impacts de services tiers 2 & 3 OUI OUI ?
Méthodologie de l’intensité carbone de l’éléctricité
Perte en ligne 2 ? NON ?
Fabrication des infrastructures énergétiques 2 ? OUI ?
Location Based 2 Indirectement OUI NON
Market Based 2 OUI OUI OUI

Allocations : Synthèse

Item AZURE GCP AWS
Spécifiques aux utilisateurs NON NON ?
Spécifiques aux services Partiellement SCOPE 2 ?
Spécifiques aux régions OUI SCOPE 2 ?

Tagged

Vous devriez aussi aimer

    © Boavizta