Types d'instance avec un profil de puissance embarqué

Tous les instance_type acceptés par [green.cloud.services], [green.database_static] et [green.broker_static], avec les puissances au repos et maximale entre lesquelles le modèle SPECpower interpole. 548 entrées, millésime de la table 2026-04-24 (CCF aligned). Les noms de classes managées de base de données, de cache, de broker et de recherche sont acceptés aussi : chacun se résout sur la ligne de la famille de VM qui l'héberge, voir Classes de services managés.

Un type absent n'est pas une erreur dans [green.cloud.services]. Perf Sentinel avertit une seule fois au démarrage en nommant le type, et la raison quand il s'agit d'une classe managée que le modèle laisse de côté, puis se rabat sur une moyenne du fournisseur, ce qui rend la valeur plus grossière. Cet avertissement est aussi la façon de vérifier votre propre type sans lire cette page. Dans [green.database_static] et [green.broker_static], le même type est une erreur qui arrête le chargement, puisque des hôtes déclarés n'ont aucune autre source sur laquelle se rabattre. Quand votre matériel est absent et que vous connaissez sa consommation, déclarez-la directement, ce qui donne une valeur exacte plutôt qu'approchée :

[green.cloud.services]
"my-service" = { idle_watts = 45.0, max_watts = 120.0 }

Les lignes Scaleway sont dérivées, pas publiées. Cloud Carbon Footprint ne publie des coefficients que pour AWS, GCP et Azure. Scaleway ne publie pas non plus de puissance, mais son API Product Catalog nomme le CPU exact de chaque offre sans authentification (AMD EPYC 7543, et non une famille générique). Chaque offre est valorisée par le coefficient CCF de l'architecture de ce CPU, selon la même arithmétique vCPU fois coefficient que les trois autres. Cela ajoute une seule hypothèse, celle que CCF pose déjà entre AWS et GCP : qu'un coefficient calculé sur des flottes d'hyperscalers se transpose à du silicium comparable ailleurs. Trois groupes d'offres sont exclus plutôt qu'approchés :

• Les gammes à vCPU partagés (DEV1, PLAY2, BASIC2, BASIC3), où attribuer un vCPU entier à un locataire surestime ce qu'il tire.
• Les offres GPU (H100, L4, L40S, RENDER), parce que la table ne modélise aucun accélérateur chez aucun fournisseur, et qu'une H100 pèse à elle seule plus que tout le budget CPU.
• Les gammes AmpereOne et Granite Rapids (STANDARD2, B300), absentes des CSV de CCF.

OVHcloud et OUTSCALE restent absents. Sources consultées en août 2026 :

• Boavizta (BoaviztAPI) est la seule base tierce à descendre au type d'instance, avec 50 tailles OVHcloud. Ses fichiers ne portent aucune colonne de puissance, et le CPU dont une puissance serait dérivée est une hypothèse de Boavizta lui-même, marquée CPU not verified sur les 12 lignes d'archétype OVHcloud. L'une crédite un serveur rack d'un Intel Core i7-4940MX, une puce mobile, sur deux sockets. OVHcloud lui-même ne documente aucun CPU par gamme.
• OUTSCALE s'arrête au couple (Région, catégorie de service) : deux régions, trois catégories, aucun type d'instance, aucun watt, aucun kWh, et zéro occurrence chez Boavizta.

Sur ce matériel, mesurez plutôt : Alumet ou Scaphandre lisent RAPL directement et priment sur toute valeur modélisée.

D'où viennent ces chiffres, et pourquoi une famille correspond à un coefficient plutôt qu'à une machine mesurée : Méthodologie et 05 · GreenOps & carbon. Configurer le scraper : Configuration.

Cette page est générée depuis la table embarquée par scripts/generate-instance-types-doc.py, et un test casse le build si les deux divergent. Ne la modifiez pas à la main.

Classes de services managés

Une classe managée de base de données, de cache, de broker ou de recherche tourne sur une famille de VM que la table valorise, donc son nom se résout sur la ligne de cette famille. Les règles s'appliquent dans l'ordre et s'arrêtent à la première ligne trouvée. Une ligne exacte n'est jamais réécrite, et seule la règle vCore Azure SQL calcule une puissance, en mettant une ligne à l'échelle par vCore.

Les lettres AWS d (stockage d'instance local), n (réseau) et b (stockage bloc), et le d Azure (disque temporaire local), ne changent pas le processeur. Les lettres de processeur a, g, i et les modificateurs AWS z et e ne sont jamais retirés, donc m5zn et x2iedn restent inconnus. Le retrait est approximatif quand un modificateur change la génération de CPU : c5n est une puce Skylake alors que les lignes c5 sont Cascade Lake, un écart qui reste dans la fourchette 2x. Une classe dont la famille de base n'a pas de ligne reste inconnue.

Graviton 2 (m6g, c6g, r6g, t4g) et les Graviton optimisés mémoire (r6g, r7g, r8g) ont des lignes, donc db.r6g.large, cache.t4g.micro ou db.m6gd.large se résolvent. Les classes Burstable des serveurs flexibles Azure sont les lignes Standard_B* elles-mêmes, valorisées à leurs vCPU complets puisque le crédit de rafale n'est pas modélisé.

Enterprise Plus tourne sur la série N2 à 8 Go par vCPU, la forme de n2-highmem. La série standard (Gen5) d'Azure SQL tourne sur plusieurs processeurs (Broadwell, Skylake, Cascade Lake, Ice Lake, Milan, Genoa, Emerald Rapids). Parmi ceux que le CSV Azure publie, Skylake a le plus haut max W/vCPU, donc la référence est la plus grande ligne Skylake, Standard_D64s_v3 : GP_Gen5_64 lui est égal et un objectif plus petit la met à l'échelle par vCore, sans arrondi. Gen5 porte 5,1 Go par vCore, sous le seuil de la prime DRAM. Un objectif serverless est valorisé à son maximum de vCores, un plafond. Les réplicas sont des nœuds : les standbys Multi-AZ, les lecteurs Aurora et les réplicas Business Critical comptent dans nodes.

Non modélisées. L'avertissement de démarrage, ou l'erreur de chargement dans [green.database_static] et [green.broker_static], donne la raison pour les cinq premières lignes, les autres sont signalées comme types inconnus :

Sources des règles : les conventions de nommage des types d'instance AWS, les conventions de nommage des VM Azure, la définition de la capacité Aurora Serverless v2, les séries de machine Cloud SQL, les configurations matérielles vCore Azure SQL, et l'exclusion des vCPU partagés de scripts/refresh-instance-power.py.

AWS (276 entrées)

GCP (98 entrées)

Azure (108 entrées)

Scaleway (65 entrées)

Bare metal (1 entrée)