Instance types with an embedded power profile

Every instance_type accepted by [green.cloud.services], [green.database_static] and [green.broker_static], with the idle and maximum wattage the SPECpower model interpolates between. 548 entries, table vintage 2026-04-24 (CCF aligned). Managed database, cache, broker and search class names are accepted too: each resolves to the row of the VM family it runs on, see Managed service classes.

An unlisted type is not an error in [green.cloud.services]. Perf Sentinel warns once at startup, naming the type, and the reason when it is a managed class the model leaves out, then falls back to a provider-level average, so the figure gets coarser. That warning is also how you check your own type without reading this page. In [green.database_static] and [green.broker_static] the same type is an error that stops the load, since declared hosts have no other source to fall back on. When your hardware is absent and you know its draw, declare it directly instead, which is exact rather than approximated:

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

Scaleway rows are derived, not published. Cloud Carbon Footprint publishes coefficients for AWS, GCP and Azure only. Scaleway publishes no wattage either, but its Product Catalog API names the exact CPU of every offer without authentication (AMD EPYC 7543, not a generic family). Each offer is priced by the CCF coefficient for that CPU's architecture, with the same vCPU-times-coefficient arithmetic as the three above. This adds a single assumption, the one CCF already makes between AWS and GCP: that a coefficient computed on hyperscaler fleets transfers to comparable silicon elsewhere. Three groups of offers are excluded rather than approximated:

• Shared-vCPU ranges (DEV1, PLAY2, BASIC2, BASIC3), where attributing a whole vCPU to one tenant overstates what it draws.
• GPU offers (H100, L4, L40S, RENDER), because the table models no accelerator for any provider, and an H100 alone outweighs the entire CPU budget.
• AmpereOne and Granite Rapids ranges (STANDARD2, B300), absent from the CCF CSVs.

OVHcloud and OUTSCALE are still absent. Sources checked as of August 2026:

• Boavizta (BoaviztAPI) is the only third-party base that reaches instance granularity, with 50 OVHcloud sizes. Its files carry no power column, and the CPU a wattage would be derived from is Boavizta's own assumption, flagged CPU not verified on all 12 OVHcloud archetype rows. One credits a rack server with an Intel Core i7-4940MX, a mobile part, across two sockets. OVHcloud itself documents no CPU per range.
• OUTSCALE stops at (Region, service category): two regions, three categories, no instance type, no watt, no kWh, and zero occurrences in Boavizta.

On that hardware, measure instead: Alumet or Scaphandre read RAPL directly and outrank every modeled figure.

Where the numbers come from, and why a family maps to a coefficient rather than to a measured machine: Methodology and 05 · GreenOps & carbon. Configuring the scraper: Configuration.

This page is generated from the embedded table by scripts/generate-instance-types-doc.py, and a test fails the build if the two disagree. Do not edit it by hand.

Managed service classes

A managed database, cache, broker or search class runs on a VM family the table prices, so its name resolves to that family's row. The rules apply in order and stop at the first row. An exact row is never rewritten, and only the Azure SQL vCore rule derives a wattage, by scaling a row per vCore.

The AWS letters d (local instance store), n (network) and b (block storage), and the Azure d (local temp disk), leave the processor unchanged. The processor letters a, g, i and the AWS z and e modifiers are never dropped, so m5zn and x2iedn stay unknown. The strip is approximate where a modifier changes the CPU generation: c5n is a Skylake part while the c5 rows are Cascade Lake, a gap inside the 2x bracket. A class whose base family has no row stays unknown.

Graviton 2 (m6g, c6g, r6g, t4g) and memory-optimized Graviton (r6g, r7g, r8g) have rows, so db.r6g.large, cache.t4g.micro or db.m6gd.large resolve. The Azure flexible-server Burstable classes are the Standard_B* rows themselves, priced at their full vCPU since burst credit is not modeled.

Enterprise Plus runs on the N2 series at 8 GB per vCPU, the shape of n2-highmem. Azure SQL standard-series (Gen5) runs on several processors (Broadwell, Skylake, Cascade Lake, Ice Lake, Milan, Genoa, Emerald Rapids). Among those the Azure CSV publishes, Skylake has the highest max W/vCPU, so the reference is the largest Skylake row, Standard_D64s_v3: GP_Gen5_64 equals it and a smaller objective scales it per vCore, unrounded. Gen5 carries 5.1 GB per vCore, below the DRAM premium threshold. A serverless objective is priced at its max vCores, a ceiling. Replicas are nodes: Multi-AZ standbys, Aurora readers and the Business Critical replicas count in nodes.

Not modeled. The startup warning, or the load error in [green.database_static] and [green.broker_static], names the reason for the first five rows, the others are reported as unknown types:

Rule sources: the AWS instance type naming conventions, the Azure VM naming conventions, the Aurora Serverless v2 capacity definition, the Cloud SQL machine series, the Azure SQL vCore hardware configurations, and the shared-vCPU exclusion of scripts/refresh-instance-power.py.

AWS (276 entries)

GCP (98 entries)

Azure (108 entries)

Scaleway (65 entries)

Bare metal (1 entry)