Carbon Footprint Estimate
The carbon footprint estimate gives an energy consumption estimation as well as an estimation for the combined CO2 emissions of the products in the proposal. The estimates are calculated as follows:
Calculation of the carbon footprint
The footprint estimation is using the core logic of the cloudcarbonfootprint project and calculates the estimated CO2e emissions and kilowatt hours per month for the proposal or a selected instance.
Methodology
The footprint estimate uses the methodology of the cloudcarbonfootprint project and includes both runtime and embodied emissions calculations. The total footprint estimate is a combined estimate from three partial estimates:
- Compute footprint, depends on the CPU amount and type
- Memory footprint, depends on the RAM amount
- Storage footprint, depends on the used storage amount
Embodied Emissions
In addition to runtime emissions, the footprint estimate now includes embodied emissions (also known as Scope 3 emissions) which represent the carbon footprint from manufacturing the underlying hardware infrastructure.
Direct Embodied Carbon Emissions
The local Embodied Carbon Emissions of an asset are captured in its Direct Embodied Emissions property, measured in Tons per Month.
This property is primarily used for physical infrastructure assets (e.g. server racks, hard drives, etc.) and is usually zero for all logical assets (e.g. applications, databases, business capabilities etc.).
Total Embodied Carbon Emissions
The Total Embodied Carbon Emissions of an asset are measured in Tons per Month and are computed by summing up the Direct Embodied Carbon Emissions, plus the associated Total Embodied Carbon Emissions of all child assets.
The calculation works exactly the same way as for Total Runtime Carbon Emissions, except that it uses the Embodied category of properties.
Supported Products
The following overview presents our current embodied emission calculation capabilities across the three major cloud providers. Coverage focuses on the most critical product categories: compute, storage, and database services.
- Compute Services
- Database Services
- Storage Services
| AWS | Google Cloud | Azure |
|---|---|---|
| Amazon EC2 | Google Compute Engine | Azure Virtual Machines |
| Amazon EKS on EC2 | Google Kubernetes Engine | Azure Kubernetes Service |
| Amazon Elastic Container Service on EC2 | - | - |
| Amazon EC2 for SQL Server | - | Azure SQL Server on Virtual Machines |
| Amazon EC2 Dedicated Hosts | Google Sole Tenant Nodes | Azure Dedicated Host |
| Amazon EC2 Bare Metal Instance | Google Bare Metal | - |
| AWS | Google Cloud | Azure |
|---|---|---|
| Amazon RDS | Cloud SQL for MySQL | - |
| Amazon DocumentDB | Cloud SQL for PostgreSQL | - |
| AWS | Google Cloud | Azure |
|---|---|---|
| Amazon FSx Lustre & Windows | Google Persistent Disk | Azure Disk Storage |
| Amazon Elastic Block Store (EBS) | Cloud Filestore | - |
| Amazon Elastic File System (EFS) | Local SSD | - |
| Amazon S3 | Cloud Storage | - |
| Amazon Elastic Container Registry | Google Artifact Registry | - |
The following products currently have incomplete embodied emissions data, primarily due to varying metadata availability and service-specific implementation requirements.
Implementation Considerations: Certain cloud services present unique challenges for embodied emissions calculation due to diverse architectural patterns and metadata structures. While compute services typically provide comprehensive instance specifications, specialized services may require additional mapping and data enhancement strategies.
- Compute & Container Services
- Database Services
- Specialized Services
| AWS | Google Cloud | Azure |
|---|---|---|
| AWS Outposts | Cloud Run | Azure Functions |
| - | Cloud Run Functions | Azure Container Apps |
| - | Google Container Registry | Azure Container Instances |
| AWS | Google Cloud | Azure |
|---|---|---|
| Amazon SimpleDB | Cloud SQL for SQL Server | Azure Database for MariaDB |
| Amazon DynamoDB | Google AlloyDB for PostgreSQL | Azure SQL Managed Instance |
| Amazon Quantum Ledger Database | - | Azure Database for MySQL |
| AWS ElastiCache¹ | - | Azure Database for PostgreSQL |
| - | - | Azure SQL Database |
| - | - | Azure Cosmos DB |
| - | - | Azure Managed Instance for Apache Cassandra |
¹ Limited processor metadata availability
| Service Category | Representative Services |
|---|---|
| Container Orchestration | Red Hat OpenShift on Azure |
| Object Storage | Azure Table Storage |
| Hybrid Infrastructure | VMware on Azure |
Methodology
Our embodied emissions calculation methodology is based on the established Cloud Carbon Footprint project, with implementation scripts available on GitHub.
The calculation utilizes the same manufacturing emission constants as the reference implementation. While the original methodology focuses exclusively on virtual server infrastructure, our implementation extends support to physical servers, database services, and storage products through additional assumptions and platform-specific calculations.
Required Data Elements
Accurate embodied emission calculations require the following platform characteristics:
-
Processor Socket Count (
MaxSocketCount)
Represents the maximum number of physical processors supported on a single motherboard configuration. This metric determines the processor manufacturing footprint. ARM-based processors typically support single-socket configurations only. -
Platform Memory Specifications
The maximum memory capacity supported by the underlying physical platform, derived from the largest available instance configuration. -
Platform CPU Specifications
The total CPU cores available on the physical platform, calculated from the most resource-intensive instance offering. -
Platform Storage Drive Quantity
The default number of storage drives attached to instance types across all size configurations.
Additional calculation constants are sourced directly from the Cloud Carbon Footprint project's reference implementation.
Calculation Methodology
The embodied emissions calculation follows a systematic approach to determine the manufacturing footprint of cloud infrastructure components.
Step 1: Total Platform Emissions
The total embodied emissions for a physical platform are calculated by aggregating the manufacturing emissions across all hardware components:
| Component | Formula | Description |
|---|---|---|
| CPU | (MaxCpuSockets - 1) × CPU_MANUFACTURING_EMISSIONS | Additional processor manufacturing cost beyond base |
| Memory | (PlatformMemory - DRAM_THRESHOLD) × DRAM_MANUFACTURING_EMISSIONS | Memory manufacturing above threshold capacity |
| Storage | StorageType_MANUFACTURING_EMISSIONS × PlatformDriveQuantity | Storage device manufacturing emissions |
| Base Platform | BASE_MANUFACTURING_EMISSIONS | Baseline server chassis and components |
Total Platform Calculation:
Total Platform Emissions = Base + CPU + Memory + Storage
Step 2: Instance Allocation
Cloud instances consume only a portion of the underlying physical platform. The allocation formula distributes platform emissions proportionally:
Instance Embodied Emissions = Platform Emissions × Resource Fraction × Time Fraction
Where:
- Resource Fraction =
Instance CPUs ÷ Platform CPUs - Time Fraction =
Actual Runtime ÷ Estimated Server Lifetime
Service-Specific Implementation
Compute Services For virtual machines and containerized services, embodied emissions are calculated based on the underlying physical platform specifications. The system determines platform characteristics through instance type classification and applies proportional allocation based on actual resource consumption.
Dedicated Infrastructure Physical servers and dedicated hosts utilize the full platform allocation model, where the instance embodied emissions equal the total platform emissions, reflecting complete hardware dedication.
Database Services Database services follow compute service methodology, with instance types derived from service naming conventions. This approach leverages the consistent instance type patterns used across cloud providers.
Cloud services maintain consistent instance type nomenclature across service categories:
- Database Service:
db.t3.large→ Platform Type:t3 - Compute Service:
t3.large→ Platform Type:t3 - Container Service:
t3.large→ Platform Type:t3
This consistency enables unified platform specification mapping across diverse service offerings.
Storage Services Storage embodied emissions extend the server-focused methodology through standardized physical storage assumptions:
| Storage Type | Capacity per Physical Unit |
|---|---|
| SSD | 4,096 GiB (4 TiB) |
| HDD | 24,576 GiB (24 TiB) |
Storage emissions are distributed across capacity and operational lifetime:
Storage Embodied Emissions = (Manufacturing Emissions ÷ (Lifetime × Capacity)) × Usage × Duration
Where manufacturing emissions, lifetime constants, and capacity assumptions align with industry-standard hardware specifications.
Limitations
The calculated CO2 emissions and kilowatt hours are only a rough estimate based on the methodology of the cloudcarbonfootprint project. The estimates should not be considered as absolute values, but rather as a comparison of which product or instance is better regarding the emissions. Currently we can only create estimations for AWS, Azure and Google products, that have either CPUs, RAM or storage modeled. Embodied emissions calculations are available for supported compute, database, and storage services across these cloud providers. Also, the solution footprint estimate will display the estimated footprint only for the applicable instances within the solution. This means if you have a solution with one instance from AWS and one from Oracle (which is not considered in the estimate), the total solution footprint would be equivalent to the footprint of the AWS instance.